# Does Flatpak weaken Chromium/Firefox's sandbox? **URL:** https://discuss.privacyguides.net/t/does-flatpak-weaken-chromium-firefoxs-sandbox/13373 **Category:** Questions **Created:** 2023-07-26T19:58:59Z **Posts:** 40 ## Post 1 by @qwq — 2023-07-26T19:58:59Z Continuing the discussion from [Which Flatpaks and other resources should be included in the “Downloads” section? - #4](https://discuss.privacyguides.net/t/which-flatpaks-and-other-resources-should-be-included-in-the-downloads-section/13349/4): > [@Which Flatpaks and other resources should be included in the "Downloads" section?](https://discuss.privacyguides.net/t/which-flatpaks-and-other-resources-should-be-included-in-the-downloads-section/13349/3): > > they weaken the sandbox (both on Firefox and Chromium). I’ve heard this before, but couldn’t find anything about it online. Can you link some further reading on this subject? --- ## Post 2 by @username0990 — 2023-07-27T05:06:01Z 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. > [@qwq](#): > > Can you link some further reading on this subject? > [@Brave on Wayland](https://discuss.privacyguides.net/t/brave-on-wayland/12127/10): > > [https://blogs.gnome.org/wjjt/2021/03/25/chromium-on-flathub/](https://blogs.gnome.org/wjjt/2021/03/25/chromium-on-flathub/)[https://github.com/flatpak/flatpak/issues/4032](https://github.com/flatpak/flatpak/issues/4032) These are 2 sources that I could find. --- ## Post 3 by @Jimmy — 2023-07-27T12:36:27Z 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)](https://chromium.googlesource.com/chromium/src/+/main/docs/linux/sandboxing.md) [Security/Sandbox/Specifics - MozillaWiki](https://wiki.mozilla.org/Security/Sandbox/Specifics) 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. --- ## Post 4 by @jonah — 2023-07-27T16:34:04Z The Chromium Flatpak [is patched](https://github.com/flatpak/flatpak/issues/4032#issuecomment-747263363) 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. --- ## Post 5 by @anonymous72 — 2023-07-27T17:10:15Z In chrome://sandbox layer 1 sandbox is yellow (SUID) within flatpak but normally it is green (namespace) --- ## Post 6 by @jonah — 2023-07-27T18:58:41Z For Chromium builds which natively support Flatpak’s sub-sandboxing: ![BQGKRnGOglTiqUC1](//forum-uploads.privacyguidesusercontent.com/original/2X/e/eade7f38c713c40d77b62fd1fc692fb1d439d777.png) 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](https://github.com/refi64/zypak#how-does-it-work) 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](https://chromium.googlesource.com/chromium/src/+/main/docs/linux/sandboxing.md). --- ## Post 7 by @sha123 — 2023-07-28T09:05:02Z 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. --- ## Post 8 by @sha123 — 2023-07-28T09:29:21Z 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. --- ## Post 9 by @sha123 — 2023-07-28T09:40:23Z 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. --- ## Post 10 by @username0990 — 2023-07-28T11:06:58Z MicroOS already includes Firefox’s flatpak package and something similar is planned for [Silverblue](https://github.com/fedora-silverblue/issue-tracker/issues/288). 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](https://support.mozilla.org/en-US/kb/install-firefox-linux#w_local-firefox-installation-in-users-account)” method? --- ## Post 11 by @sha123 — 2023-07-28T12:21:25Z 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. --- ## Post 12 by @jonah — 2023-07-28T13:51:13Z > [@sha123](#): > > You will find different statements regarding Chromium’s SUID sandbox. 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. --- ## Post 13 by @sha123 — 2023-07-28T14:03:00Z > [@jonah](#): > > 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 ;). --- ## Post 14 by @jonah — 2023-07-28T14:15:45Z 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. --- ## Post 15 by @sha123 — 2023-07-28T14:42:40Z > [@jonah](#): > > 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? The gold standard is the native installation, because it is free to do whatever is needed. > [@jonah](#): > > 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, 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? > [@jonah](#): > > 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. It is relevant to browser security and also relevant to users who don’t use unprivileged user namespaces. > [@jonah](#): > > 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. 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). --- ## Post 16 by @jonah — 2023-07-28T15:37:21Z 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. --- ## Post 18 by @Torsten — 2023-12-26T02:17:57Z 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. --- ## Post 19 by @anon21489307 — 2023-12-26T18:02:19Z > [@Torsten](#): > > we do need proof that Flatpak is as secure In most cases, Flatpak is not more secure than anyone’s normal packaging format, as: 1. 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. 2. Many Flatpak apps are packaged by community. If security is concerned, there’s no alternative to official packages. --- ## Post 20 by @xe3 — 2023-12-26T19:35:11Z > [@anon21489307](#): > > 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](https://docs.flatpak.org/en/latest/manifests.html) 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. --- ## Post 21 by @anon21489307 — 2023-12-26T20:36:16Z 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. --- ## Post 22 by @xe3 — 2023-12-26T21:54:53Z > Anyone can do all that if they have _time_, _knowledge_, and _patient_. Correct. Similar to Arch and the AUR, this is only an option for people that are knowledgeable enough and willing to do so. But the knowledge barrier isn’t _tha_ high (for doing basic due diligence/harm reduction). Where I disagree is that I don’t believe it is correct that _“If security is concerned, there’s **no** alternative to official packages”_. There are alternatives, they are not right for everyone, but they do exist. > [@anon21489307](#): > > And if the source is malicious in the first place, Flatpak won’t help with anything. This is exactly why it is important to _check the source_ (which in the the case of a flatpak can be checked in less than a minute. Take a peak at the example of the Signal Manifest I gave in my previous comment you’ll see that the flatpak is built from the .deb package directly from Signals website, and I believe this is cryptographically verifiable). Even if you have never ever viewed a manifest file before I think you’ll still be able to easily identify the source the package is built from. I think we probably agree that it is crucial to to either: 1. (Ideally) get the software from a trusted source (usually the developer themselves, or your distro who you are already putting trust in) 2. (and/OR) vet the software yourself if you source it from an unofficial source and you feel capable of doing so). Flatpak (nor any other Linux package format can protect you if the source of the software itself is malicious, if you install malware, from an untrustworthy malicious source, you’ve installed malware regardless of whether that is a .deb, .rpm, snap or flatpak (from what I’ve heard snap’s sandboxing is a bit better but still not on par with some other OS’s sandboxing). I do hope that eventually we get more robust, granular, and mandatory sandboxing in Linux, I do know that this is something Flatpak’s developers are conscious of and working towards. also as an aside, you can sidestep the issue of unofficial software with flatpaks completely by choosing a repo that doesnt’ include unofficial software. You can use flathub-verified instead of flathub to exclude all software that is not packaged by its developer, or if you use Fedora you can use Fedora’s flatpak repo to get software packaged only by the Fedora team (Gnome and KDE Plasma have their own flatpak repos as well). So one can absolutely use flatpak without ever exposing themselves to unofficial packages if they choose to do so. The issue of unofficial software isn’t related to flatpak, it is related to the flathub repo, it is also not limited to flatpak (if you use RPMfusion or COPR with Fedora/RHEL, PPAs or Snap with Ubuntu, OBS with OpenSUSE, or the AUR with Arch, (or appimage, snap, or flatpak with any distro), you’ve got to be conscious that some or all software in those repos is not vetted or vouched for by your distro and may or may not be packaged by the developer of the software. --- ## Post 23 by @qwq — 2024-06-28T07:21:09Z Just want to link to a discussion that [Cromite’s](https://github.com/uazo/cromite) main developer had on this: [Creating a Flatpak for Linux · Issue #1053 · uazo/cromite · GitHub](https://github.com/uazo/cromite/issues/1053) --- ## Post 24 by @KeepItSimple — 2024-06-28T10:31:54Z Thanks, it was interesting to read. Eventually Cromite dev do not recommends Flatpak for a browser. Also ungoogled chromium were concerned about it too and use some patch instead, which uazo called highly insecure. --- ## Post 25 by @exaCORE — 2024-08-27T14:16:30Z This question relates to a post I made: [Firefox and Unprivileged namespaces](https://discuss.privacyguides.net/t/firefox-and-unprivileged-namespaces/20158) As presumably the situation described there and the situation with Firefox flatpak are pretty similar. I wanted to follow up and see if anybody had additional information on the importance of unprivileged namespaces to Firefox security --- ## Post 26 by @asanyan — 2024-08-27T15:04:34Z > [@xe3](#): > > Correct. Similar to Arch and the AUR, this is only an option for people that are knowledgeable enough and willing to do so. But the knowledge barrier isn’t _tha_ high (for doing basic due diligence/harm reduction). With yay, pkgbuilds are cached and I can only read the diffs when there’s an update. The changes most of the time are just hashes and the pkgver. Is there a way to do this with the flatpak manifest? --- ## Post 27 by @gregandcin — 2024-08-27T15:33:01Z On Flathub, projects have a public manifest repo: ![image](//forum-uploads.privacyguidesusercontent.com/original/2X/f/f3cb869b1d6add27448939149132c2e8f7d3cc59.png) You can then look at the commit history of the repo to see changes over time ![image](//forum-uploads.privacyguidesusercontent.com/original/2X/d/d5a9316839844dbf3ebf3105b4894fe8891b4bd9.png) ![image](//forum-uploads.privacyguidesusercontent.com/original/2X/8/8320ff5d22d155a8f8d9015ba8cbd05e911e2e1a.png) ![image](//forum-uploads.privacyguidesusercontent.com/original/2X/e/e531170b03412ef7fc8932c2cce2bdf93ef73f17.png) Not as elegant of a solution, but still public and searchable --- ## Post 28 by @exaCORE — 2024-08-28T19:16:18Z Some links to support this approach: > **[1882881 - Flatpak: explain how it can be as secure as native browsers](https://bugzilla.mozilla.org/show_bug.cgi?id=1882881)** > > UNCONFIRMED (nobody) in Firefox Build System - Third Party Packaging. Last updated 2024-03-09. > **[1909616 - User namespaces warning is alarmist and not actionable with flatpak](https://bugzilla.mozilla.org/show_bug.cgi?id=1909616)** > > RESOLVED (lissyx+mozillians) in Core - Security: Process Sandboxing. Last updated 2024-07-25. --- ## Post 29 by @sha123 — 2024-08-28T20:14:44Z > [@exaCORE](#): > > Some links to support this approach: Where are the technical arguments supporting it? --- ## Post 30 by @Torsten — 2024-12-11T02:39:33Z This is unrelated --- ## Post 31 by @anonfox — 2025-04-04T10:47:20Z > **[Merge branch '10422-tor-browser-in-flatpak' into 'stable' (6283e276) · Commits...](https://gitlab.tails.boum.org/tails/tails/-/commit/6283e276c0d89dfe50e25faa473ed68091fcba5f#92f9038d303a1bdae02915f02a3e5f32b4b6218b_25_25)** > > Run Tor Browser in pseudo flatpak Closes #19266, #15678, #19408, #19572, #19328, and #19254 See merge request tails/tails!1025 Tails (an official tor project parter) runs tor browser in a fake flatpak that allows access to unprivileged namespaces because otherwise it would weaken its sandbox. Major QubesOS dev says chromium sandbox is weaker when ran in a flatpak. The whole issue is interesting and references this thread and Cromite’s dev’s take that flatpak does weaken the chromium sandbox. Rustysnake (a frequent Firejail, Bubblejail, and Flatpak contributor) agrees. > > > ### Checklist > > - [X] I agree to follow the [Code of Conduct](https://github.com/…flatpak/flatpak/blob/main/CODE_OF_CONDUCT.md) that this project adheres to. > - [X] I have searched the [issue tracker](https://www.github.com/flatpak/flatpak/issues) for a feature request that matches the one I want to file, without success. > > ### Suggestion > > The Flatpak sandbox can create an effective boundary between the running application and the rest of the system. However, it creates problems for Chromium, Firefox, and derived applications that use sophisticated internal sandboxes to isolate processes from each other. These internal partitions are critical as they prevent browser tabs from potentially snooping on each other. > > On Linux, Chromium's sandbox was initially implemented using a SetUID helper but nowadays prefers unprivileged [user namespaces and PID namespaces](https://chromium.googlesource.com/chromium/src/+/0e94f26e8/docs/linux_sandboxing.md). However, it is well-known that Chromium does not work out of the box with Flatpak since Flatpak disallows applications from creating user namespaces. Flatpaks of Chromium and its derivatives work around this by [patching the Chromium sandbox](https://github.com/flathub/org.chromium.Chromium/issues/337). This modification not only has not undergone any formal design process or upstream security review but also empirically [weakens](https://github.com/uazo/cromite/issues/1053#issuecomment-2194129916) Chromium's security compared to the [usual RPM/DEB distributions of Chromium](https://discuss.privacyguides.net/t/does-flatpak-weaken-chromium-firefoxs-sandbox/13373/7). Until this is resolved, users of RPM/DEB-based Linux distributions would be ill-served by being advised to adopt the Flatpak versions of Chrome and Firefox because web browsers have the largest attack surface of all user-facing applications. > > > As a short-term fix, would Flatpak consider adding a `--allow-userns` option to allow give trusted applications sufficient privileges to configure their own sandboxes? While the option to allow user namespaces is potentially a security risk, Flatpak already allows one to poke other holes in the sandbox, such as `--filesystem=host`, because we don't yet live in a world where all applications can run fully confined and use only the portal APIs to interact with the outside world. Ubuntu snap already runs Chromium and Firefox under a [custom security profile](https://snapcraft.io/docs/browser-support-interface) that whitelists user namespace creation to accommodate the browser's internal sandbox. > > While one might ideally want to convince Chromium developers to change their sandbox implementation to accommodate Flatpak, this would likely be a tough sell because Chromium's existing sandbox is already battle-tested and won't stop working anytime soon. > > > The Chromium team is probably in a better shape than it was when was written. Furthermore, this would allow Electron apps to work normally under flatpak without requiring Zypack. I suspect this is what would be needed for apps like Element to ship an official flatpak. > > > The Chromium team is probably in a better shape than it was when was written. Furthermore, this would allow Electron apps to work normally under flatpak without requiring Zypack. I suspect this is what would be needed for apps like Element to ship an official flatpak. > > > I'm building a Flatpak to make it easier to distribute and update Cromite across… all Linux distributions. > > Everything is about ready and seems to work fine. I just need a few things: > > - Could you add the chrome-sandbox target for the next release to allow Flatpak to take over the sandboxing? > - Do you have an SVG version of Cromite's logo that I could include? (for now, I made a dirty SVG conversion from the PNG logo) > - Is the package name "com.github.uazo.cromite" OK for you or would you prefer something else? > > > Flatpaks can not call syscalls like `unshare`, `mount`, `chroot`/`pivot_root` wh…ich are essential to setup a namespace based sandbox. This means flatpaks can not directly sub-sandbox it self and need to use `flatpak-spawn` instead. > > The most chrom* and electron flatpaks use [zypack](https://github.com/refi64/zypak) to redirect the chrome-sandbox to `flatpak-spawn`. AFAIUI this means that the ["good" chrome sandbox](https://madaidans-insecurities.github.io/firefox-chromium.html#sandboxing) is replaced by the ["weak" flatpak sandbox](https://madaidans-insecurities.github.io/linux.html#flatpak). > > Should there be an "If you install chromium via flatpak the sandbox ..." note or do I understand things wrong? Madaidan (former Whonix/Kicksecure security researcher) agrees > **[Chromium Browser for Kicksecure Discussions (not Whonix)](https://forums.whonix.org/t/chromium-browser-for-kicksecure-discussions-not-whonix/10388/85)** > > Everything in the article still applies to Chromium. Independent parties packaging it insecurely doesn’t affect the security of it upstream. Looking into Flatpak more, it appears they disable Chromium’s Layer-1 sandbox and replace it with the... Vivaldi dev voices similar concerns and says they will review the sandbox and make the package official if they don’t find it significantly weaker. The package is still unofficial. > **[Ruarí Ødegaard (@ruario@vivaldi.net)](https://social.vivaldi.net/@ruario/111416229781984173)** > > @omgubuntu@floss.social Just to expand on why it is not official. > > The Chromium sandbox is actually very good and it is fully interprocess. My understanding is that Flatpak's sandboxing is typically to separate an app from other apps and/or from... As a result, secureblue has been investigating sandboxing chromium directly with bubblewrap > > > 1. Are Electron apps still as bad as they were? From Electron's [documentation](…https://www.electronjs.org/docs/latest/tutorial/sandbox): > > Starting from Electron 20, the sandbox is enabled for renderer processes without any further configuration. > > … > > When renderer processes in Electron are sandboxed, they behave in the same way as a regular Chrome renderer would. A sandboxed renderer won't have a Node.js environment initialized. > > VS Code apparently runs with sandboxing enabled: https://code.visualstudio.com/blogs/2022/11/28/vscode-sandbox. An app can still disable the sandbox though, a outdated (2021) list can be found at https://github.com/sickcodes/no-sandbox. > 2. Qt apps can use QtWebEngine, which is also Chromium-based. [Calibre](https://flathub.org/apps/com.calibre_ebook.calibre) is an example of such an app. Are they properly sandboxed? Do QtWebEngine-apps suffer the same sandboxing degradation when run inside Flatpak as Chromium does? > 3. GTK apps can use [WebKitGTK](https://webkitgtk.org/), which is not Chromium-based. How does the security of WebKit on Linux compare to that of Chromium? Is it OK to run WebKitGTK apps in Flatpak? Related > [@How secure is the Mullvad Browser, because Privacy ≠ Security](https://discuss.privacyguides.net/t/how-secure-is-the-mullvad-browser-because-privacy-security/22620): > > Hi, I would like to know how secure the Mullvad Browser is. So for example how long does it take for security fixes? If it turns out that a security fix is applied a week later than on Firefox, that’s unacceptable for me. Also I’m using Ubuntu and Mullvad Browser using just one deb file (as far as my limited knowledge can tell) for both Debian and Ubuntu doesn’t seem right. Because Ubuntu has, as far as I know, different configurations than Debian…especially the Apparmor stuff. And since it’… > [@Firefox and Unprivileged namespaces](https://discuss.privacyguides.net/t/firefox-and-unprivileged-namespaces/20158): > > Hey all! I just booted up firefox 129 today after having been away for a while and received a message concerning the security due to Firefox not having the ability to utilize unprivileged namespaces (linked to this page: [Install Firefox on Linux | Firefox Help](https://support.mozilla.org/en-US/kb/install-firefox-linux?as=u)). For context I use Arch Linux with unprivileged namespaces disabled (linux-hardened) and apparmor with default profiles (I am waiting for the apparmor.d project to become stable). Unfortunately, the apparmor package has not been update… --- ## Post 32 by @bitosi — 2025-04-04T11:12:43Z Good research. To me, it doesn’t seem to worth the risk to use the flatpak versions. --- ## Post 33 by @anonfox — 2025-05-09T18:32:13Z Would also like to say that Brave now recommends against the Flatpak for security reasons. See [Don't link to Brave's Flatpak (Desktop Browsers)](https://discuss.privacyguides.net/t/dont-link-to-braves-flatpak-desktop-browsers/27064) [Installing Brave on Linux | Brave](https://brave.com/linux/#:~:text=it%20modifies%20Chromium%20sandboxing%20in%20ways%20which%20have%20not%20been%20vetted%20by%20the%20Brave%20or%20Chromium%20security%20teams) --- ## Post 34 by @anon6103674 — 2026-02-10T09:52:08Z Any progress on this issue? I searched everywhere and can’t seem to find any trace of someone trying to solve the problem. --- ## Post 35 by @any1 — 2026-02-10T12:15:27Z > Adrian and I have made plans for a service which allows querying running app instances (systemd-appd). This provides a new way of authenticating Flatpak instances and is a prerequisite for nested sandboxing, PipeWire support, and getting rid of the D-Bus proxy. > **[Flatpak Happenings](https://blog.sebastianwick.net/posts/flatpak-happenings/)** > > Yesterday I released Flatpak 1.17.0. It is the first version of the unstable 1.17 series and the first release in 6 months. There are a few things which didn’t make it for this release, which is why I’m planning to do another unstable release rather... --- ## Post 36 by @anon6103674 — 2026-02-10T13:18:54Z Sounds great. Thank you. Has the work on it already begun? Is there a link where we can check out the progress and maybe help? Also, I’m wondering do you use layered or flatpak browsers on your distro? --- ## Post 37 by @any1 — 2026-02-10T13:38:23Z > [@anon6103674](#): > > Has the work on it already begun? Is there a link where we can check out the progress and maybe help? Other than [this](https://github.com/flatpak/flatpak/pull/6386), I don’t know. > [@anon6103674](#): > > Also, I’m wondering do you use layered or flatpak browsers on your distro? I usually use layered or my local dev builds to test things. I have the flatpak installed to test things. --- ## Post 38 by @anon6103674 — 2026-02-10T14:25:45Z Looks like they are still arguing in who should do the work… Chrome/chromium or flatpak devs. Interesting. --- ## Post 39 by @Libre_Software_Enjoyer — 2026-02-12T00:02:24Z > [@anon21489307](#): > > 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. - You can see their permission before isntalling them on Flathub - Its very easy to modify the Flatpak permission with Flatseal before running them. --- ## Post 40 by @sha123 — 2026-02-12T08:58:18Z The situation is pretty clear: Flatpak has to modify their app identification mechanism, which is the first step towards creating a “unprivileged user namespace” permission, which does not trivially allow sandbox escapes.