1882881 - Flatpak: explain how it can be as secure as native browsers

Status: UNCONFIRMED

(Firefox Build System :: Third Party Packaging, task, P5)

Description

[Amanita]

Steps to reproduce:

There is no verified Chromium Browser packaged as a Flatpak, due to the reason that they have to remove the sandbox. The sandbox either uses user namespaces or setuid namespaces, both are not possible with Flatpaks seccomp filter.

Instead, these browsers need to be modified to use flatpak-spawn instead, to create the process sandboxes. As these processes use the same seccomp filter as any other app, they may be less secure than the native Sandbox. It also may have different drawbacks.

Firefox on the other hand is verified on Flathub, and I could nowhere find any explanation how this affects process isolation and thus critical security.

Actual results:

I could find no explanation on that topic, which is really needed.

Expected results:

Firefox is widely assumed as less secure as Chromium. I personally prefer it a lot though, but the problems of security have to be seen, explained and taken care of for Firefox to regain its place.

I could not find any explanation, how the Flatpak version can be equally secure as the native versions, which have access to way more system calls.

Please create a post/wiki entry/ something, explaining the details of the Firefox Sandbox and how it can be compatible with Flatpaks, (while Chromiums is not).

Thanks!

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Martin Stránský [:stransky] (ni? me)]

See this article: https://docs.flatpak.org/en/latest/sandbox-permissions.html

Comment 3

[Martin Stránský [:stransky] (ni? me)]

Also you can check Firefox flatpak sources which resources are allowed to access by Firefox from flatpak:
https://searchfox.org/mozilla-central/source/taskcluster/docker/firefox-flatpak/runme.sh

Comment 4

[Amanita]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #2)

See this article: https://docs.flatpak.org/en/latest/sandbox-permissions.html

I could not find info about "more than one namespace" in there. The rest is for sure good but not relevant for this question :D

Comment 5

[Gian-Carlo Pascutto [:gcp]]

"The sandbox either uses user namespaces or setuid namespaces"

The sandbox consists of 2 layers, one of which is user namespaces, the other being seccomp-bpf filtering. There's a lot of relevant comments in bug 1756236 FWIW.

I'm not sure it makes much sense to try to quantify Flatpak as "equally/more/less secure" as the native browser. It's different because you end up with a sandboxed parent process as well (which can cause different problems sometimes, sigh), and some of the isolation that the namespace is used for is perhaps already present in the Flatpak sandbox.

I think it makes more sense to spend time on bug 1756236 after bug 1609882 ships rather than trying to quantify this, but that's just me.

Comment 6

[Gian-Carlo Pascutto [:gcp]]

As these processes use the same seccomp filter as any other app, they may be less secure than the native Sandbox

This shouldn't be an issue for us, seccomp filters nest and the most restrictive wins. (Maybe you weren't implying that, i.e. you're just explaining the issue with the non-official Chromium builds?)

The tl;dr is already in bug 1756236, in that our sandbox was designed to work even if the namespacing is blocked, whereas Chromium assumes it can always have a namespace (if necessary through the use of suid root binaries) and this assumption breaks in Flatpak. At least that's what used to be the issue there, I haven't looked at this code in Chromium for a while.

I could not find any explanation, how the Flatpak version can be equally secure as the native versions, which have access to way more system calls.

This is false for the aforementioned reason, if anything the Flatpak version will have access to less system calls. (This has historically broken crash reporting until we fixed it, etc). It doesn't have a user namespace, but it does have the isolation from Flatpak itself instead. I wouldn't want to make a statement whether that is better or worse (but having both would be better if feasible).

Firefox is widely assumed as less secure as Chromium. I personally prefer it a lot though, but the problems of security have to be seen, explained and taken care of for Firefox to regain its place.

Assumptions are always dangerous and can quickly lead to incorrect reasoning and conclusions 😉

Comment 7

[Amanita]

Hi, thanka for the answers. All that was completely unknown to me, which strengthens the idea that a post about the topic (not like "which one is better" but "what factors are relevant") could be helpful to share with users, link in the flathub page etc.

some of the isolation that the namespace is used for is perhaps already present in the Flatpak sandbox.

Afaik this means that the parent process is sandboxed, which may prevent subprocesses from being sandboxed too.

seccomp filters nest and the most restrictive wins.

This is good news, didnt know that. But the seccomp filters are just one element, right?

So the question is, are subprocesses also sandboxed on flatpak, as the parent process is already sandboxed? And the cause of the issue is that many users dont know any of that, I totally believe Firefox is secure but docs are really really needed. These assumptions may come from the lack of such comparison. I would also appreciate if the docs included a short explanation of the chromium sandbox and seccomp filters, to have a comparison.

I will read the other bug, but this one is about creating docs, not by personal relief :D