Continuing the discussion from Which Flatpaks and other resources should be included in the “Downloads” section? - #4:
I’ve heard this before, but couldn’t find anything about it online. Can you link some further reading on this subject?
There seems to be a need for a general information note on whether or not to install flatpak versions of Chromium and Electron-based applications.
IIRC Flatpak disables unprivileged user namespaces due to the increased attack surface they bring with them. Unfortunately, I’m fairly sure they’re utilized by Chromium/Firefox to tighten up the sandbox even more than what flatpak has.
Chromium Docs - Linux Sandboxing (googlesource.com)
Security/Sandbox/Specifics - MozillaWiki
You can see that they mention them as being part of the sandbox. This isn’t the only issue with using a flatpak browser, but it’s one of the big ones.
The Chromium Flatpak is patched to use Flatpak’s nested sandboxing API, because it doesn’t have access to sandboxing APIs provided by the kernel. So it’s incorrect to state that Chromium’s sandboxes are disabled just because it’s running inside a container.
Flatpaks aren’t exactly the most effective sandboxes by default. However, I haven’t seen any evidence that the sub-sandboxes created by Chromium within a Flatpak container are any less effective than Chromium’s normal sandboxes. If you or someone thinks that they are less effective in a Flatpak, I’d love to see actual evidence supporting that claim.
1 Like
In chrome://sandbox layer 1 sandbox is yellow (SUID) within flatpak but normally it is green (namespace)
For Chromium builds which natively support Flatpak’s sub-sandboxing:
For Chromium builds which don’t and use zypak instead (i.e. Brave Browser) you will see “SUID” displayed, yes, but it is not Chromium’s old SUID sandbox even though it says it is:
Zypak works by using LD_PRELOAD to trick Chromium into thinking its SUID sandbox is present and still setuid, but all calls to it get instead redirected to another binary: Zypak’s own sandbox.
Additionally, even if it was using the official SUID sandbox, that sandbox is still maintained.
The Chromium sandbox has three main components: seccomp-filters, namespaces and chroots.
Seccomp-filters are stackable and the syscall is not blocked by Flatpak’s seccomp-filter, thus the Seccomp-part of the Chromium sandboxes should stay intact.
The creation of namespaces and chroots gets blocked by Flatpak’s seccomp-filter. Then there is flatpak-spawn which can be used to further sandbox or even let processes run on the host.
Pls check the namespace structure of Flatpak’s Chromium vs the official native Chrome with lsns -T. You will see a noticable difference and weakened site isolation. The native Chrome namespace structure is more fine-grained. Thus leading to better horizontal isolation.
Browsers are very complicated and follow a clear security model, since they have to run (potentially malicious) untrusted code many times a day. No project just arbitrarily adds namespaces without a good security reason, because it adds quite some complexity.
So if you change the namespace structure, you should definitely have a very good reason and an exceptionally good understanding of the browsers security. If you change it, you need to proof that this makes things better, or at least not worse, and not the other way around.
You will find different statements regarding Chromium’s SUID sandbox. I found statements that it has been phased out, other statements like the one you linked say that it’s not actively developed and only in maintenance mode. It is still available to users, but the use of unprivileged user namespaces is clearly Chromium’s preferred way and the resulting sandboxes are not the same.
For FF and Tor browser launcher the situation is similar. But they don’t even try to replace the namespace sandbox with flatpak-spawn. So you lose namespaces and chroots. This leads to weakened site isolation, weakened protection of the browser’s files (history, cookies, …) and also to less protection of the host OS. In the issue tracker about this topic, FF employees stated that they are aware of the missing namespaces and chroots, but downplay their importance. Side-note: They also never implemented a SUID sandbox, so users with deactivated unprivileged user namespaces have the same problem with missing namespace+chroot sandbox even though the about:support page makes you believe otherwise.
MicroOS already includes Firefox’s flatpak package and something similar is planned for Silverblue. Traditional Linux distributions should install it with the package manager, as recommended on Firefox’s support page. But should immutable Linux distributions prefer the “local Firefox installation in user’s account” method?
I wouldn’t use the Flatpak variant if you can get the browser through other ways.
Just to be clear. For the vast majority of apps it’s good that Flatpak blocks syscalls for namespace and chroot creation because they increase attack surface quite a lot and can lead to sandbox escapes. Just for already properly sandboxed applications it’s not a good thing, because you can sandbox individual processes in a multi-process program way stricter than if you put the program as a whole in a container sandbox, so the Flatpak sandbox won’t outweigh this.
The solution for Flatpak could be to manually approve apps like chromium to allow these syscalls or allow advanced users to specify a different seccomp-filter per app, with a fallback to the default filter.
Like I also said though, Flatpaks don’t even use Chromium’s SUID sandbox even if Chromium claims to be using it on the sandbox info page.
As far as Firefox, yeah I’m not sure. It could very well be that Firefox is worsened in Flatpak, but again I haven’t seen anyone share evidence to suggest that is the case either.
That doesn’t make sense. It’s the other way around. With the native install, browser devs are free to use the sandboxing they think is appropriate. That’s the gold standard. If other implementations deviate from that they have to prove that this doesn’t lead to less security, not the other way around. You can check that the sandboxes are significantly different yourself, if you don’t believe me ;).
Well which is it, is Mozilla’s development the gold standard for their browsers, or do they not understand the importance of certain sandboxing techniques? My reading of the issue you’re referring to is that Firefox’s sandbox was developed without the need for this in the first place, because they didn’t want to take the same approach as Chromium here, so a comparison between how important namespaces/a setuid helper is to Chromium compared to how important they are to Firefox doesn’t seem relevant.
The Firefox Flatpak is official and developed by Mozilla, so the burden of proof is actually on anyone claiming one version of Firefox shipped by Mozilla is worse than another version of Firefox shipped by Mozilla.
The gold standard is the native installation, because it is free to do whatever is needed.
That’s your interpretation and I have to disagree. Namespaces and chroot have a clear purpose in browser sandboxing and are not some optional goodie. That’s not just my opinion, but can also be found in research papers. Which technology is used in the FF browser which can replace them?
It is relevant to browser security and also relevant to users who don’t use unprivileged user namespaces.
Not the first time that Mozilla sacrificed on security just to ship something. Not having shipped a proper SUID sandbox in the past when most distros didn’t use unprivileged user namespaces is a good example (today most kernels have them activated).
1 Like
I’m just saying that you’re welcome to your opinions when you’re evaluating a browser, but as far as deciding what we’re going to recommend on the site, that has to be based in reliable fact, so we have to defer to Mozilla’s browser expertise in this case unless their methods are provably deficient. Right? This is basically hearsay when it comes down to it.
I think we really need an interview with Mozilla developers, how the Flatpak is used, and explaining their strategy.
Firefox develops the tarball, which has its internal updating mechanism and can also use the user namespaces sandbox as intended. It is optimized to run on Linux, and I did quite some speed tests that all showed that the official Tarball is the best, even better than Arch or Fedora.
You can install that everywhere, as it does not install to a system directory. They should just do a real installer with Desktop entry and all, to make it actually usable, as it doesnt feel “normal” currently.
Really interesting points, that patched Chromium doesnt use zypak. But still I can imagine that it is less secure for now to sandbox Browsers and thus their abilities to isolate the processes on their own.
Flatpak is the new technology and everyone is packaging stuff, security is not first priority. I agree it would be strange for Mozilla to ship a less secure Browser, but @sha123 is right, Debian for example had no user namespaces, and Firefox simply had no alternative Sandboxing solution.
So we do need proof that Flatpak is as secure as claimed, not the other way around.
In most cases, Flatpak is not more secure than anyone’s normal packaging format, as:
-
Flatpak app permissions are set by app developers without any interaction from the users when using the apps, i.e. there’s no prompt for those permissions to the users, contrary to PWAs, for example, where app permissions are set but needed to be allowed by the users first.
-
Many Flatpak apps are packaged by community. If security is concerned, there’s no alternative to official packages.
Yes and no. First I completely agree with your words of caution re: unofficial sources, and share your strong preference for sourcing software from official sources (either the developer themselves, or the distros official repos).
But Flatpaks like AUR packages can be reviewed without extensive knowledge of coding. Its not exactly trivial but also not too daunting. Flatpak packages have manifest files similar to how AUR packages have pkgbuild files that show how (and from what source) a flatpak is built. So it is possible to establish trust in an unofficial flatpak by vetting it yourself in the same way that Arch users are expected to do when they install unofficial software from the AUR.
For example:
Here is the manifest for the unofficial Signal Desktop client
id: org.signal.Signal
base: org.electronjs.Electron2.BaseApp
base-version: '23.08'
runtime: org.freedesktop.Platform
runtime-version: '23.08'
sdk: org.freedesktop.Sdk
command: signal-desktop
separate-locales: false
rename-desktop-file: signal-desktop.desktop
rename-icon: signal-desktop
finish-args:
# X11 performance
- --share=ipc
# We need X11
- --socket=x11
# Access to wayland
- --socket=wayland
# Audio Access
- --socket=pulseaudio
# All devices (camera, video for calls)
- --device=all
# Network Access
- --share=network
# We need to be able to inhibit sleep
- --system-talk-name=org.freedesktop.login1
- --talk-name=org.gnome.SessionManager
- --talk-name=org.freedesktop.PowerManagement
- --talk-name=org.freedesktop.ScreenSaver
- --talk-name=org.gnome.Mutter.IdleMonitor
- --talk-name=org.kde.StatusNotifierWatcher
- --talk-name=com.canonical.AppMenu.Registrar
- --talk-name=com.canonical.indicator.application
- --talk-name=org.ayatana.indicator.application
# Allow advanced input methods
- --talk-name=org.freedesktop.portal.Fcitx
- --env=SIGNAL_USE_TRAY_ICON=0
- --env=SIGNAL_START_IN_TRAY=0
- --env=SIGNAL_USE_WAYLAND=0
- --env=SIGNAL_DISABLE_GPU=0
- --env=SIGNAL_DISABLE_GPU_SANDBOX=0
- --env=XCURSOR_PATH=/run/host/user-share/icons:/run/host/share/icons
modules:
- name: signal-desktop
buildsystem: simple
build-commands:
- install -Dm0755 signal-desktop.sh "${FLATPAK_DEST}/bin/signal-desktop"
- install -Dm0644 "${FLATPAK_ID}.metainfo.xml" "${FLATPAK_DEST}/share/metainfo/${FLATPAK_ID}.metainfo.xml"
- |
bsdtar -Oxf signal-desktop.deb 'data.tar.xz' |
bsdtar -xf - \
--exclude='./usr/share/doc'
- mv opt/* "${FLATPAK_DEST}"
- install -Dm0644 "usr/share/applications/signal-desktop.desktop" "${FLATPAK_DEST}/share/applications/signal-desktop.desktop"
- desktop-file-edit --set-key=Exec --set-value='signal-desktop %U' "${FLATPAK_DEST}/share/applications/signal-desktop.desktop"
- |
for size in 16 24 32 48 64 128 256 512; do
install -Dm0644 "usr/share/icons/hicolor/${size}x${size}/apps/signal-desktop.png" "${FLATPAK_DEST}/share/icons/hicolor/${size}x${size}/apps/signal-desktop.png"
done
- desktop-file-edit --set-key=Icon --set-value="signal-desktop" "${FLATPAK_DEST}/share/applications/signal-desktop.desktop"
sources:
- type: file
dest-filename: signal-desktop.deb
url: https://updates.signal.org/desktop/apt/pool/s/signal-desktop/signal-desktop_6.42.1_amd64.deb
sha256: e97dbe92faa28cdab62ac590f68e3ecb60020df01de9e78da95aa90cea2a660b
x-checker-data:
type: debian-repo
package-name: signal-desktop
root: https://updates.signal.org/desktop/apt
dist: xenial
component: main
only-arches:
- x86_64
- type: file
path: signal-desktop.sh
- type: file
path: org.signal.Signal.metainfo.xml
And here you can read the documentation on Flatpak manifest files, which explains the different sections.
I’m still learning and not yet confident in my ability to correctly read these files, but if we look at the example I gave above, you can see that sandbox permissions are defined in the finish-args section, and you can see the source that the flatpak is built from as well as a checksum in the modules --> sources section (in the case of Signal the source is the official Signal website). And of course sandbox permissions can be reviewed or modified at any time for flatpaks installed on your system using the terminal, or a GUI frontend like flatseal.
Anyone can do all that if they have time, knowledge, and patient. For example, is it practical to check the manifest file every time for every app before updating?
And if the source is malicious in the first place, Flatpak won’t help with anything.