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.
opened 05:46PM - 25 Aug 24 UTC
enhancement
needs triage
### 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.
opened 10:04PM - 15 Nov 23 UTC
The Chromium team is probably in a better shape than it was when <https://github… .com/flathub/org.chromium.Chromium/issues/43#issuecomment-748543603> 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.
opened 10:04PM - 15 Nov 23 UTC
The Chromium team is probably in a better shape than it was when <https://github… .com/flathub/org.chromium.Chromium/issues/43#issuecomment-748543603> 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.
opened 03:29PM - 01 May 24 UTC
need triage
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?
opened 02:53PM - 01 Jun 22 UTC
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
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.
As a result, secureblue has been investigating sandboxing chromium directly with bubblewrap
opened 11:21AM - 31 Oct 24 UTC
documentation
enhancement
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
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’…
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 ). 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…
6 Likes