Browser security in flatpak

General
1

Dear all,

By no means I want to revive a sensitive topic, but I really feel that the question has not been addressed well enough yet.

Even if the outcome for most users might be that “Flatpak is secure enough for me”, I think everybody should have a clear view on these security peculiarities and consider applying the best solution for their usecase based on that.

Disclaimer: I’m not a security expert on sandboxing at all, so please correct me where I’m wrong.

Concern description:
Currently the ublue distros ship by default with the Flatpak version of Firefox. While this might provide a good enough isolation from the host system, unfortunately, as described here, Flatpak completely disables one layer of security in Firefox’s sandboxing solution. If I understand correctly, this makes the isolation between browser tabs much less secure.

Firefox Flatpak simply doesn’t use namespace sandboxes (but runs anyways!) and relies purely on seccomp filters. Dont use this! This is a weaker sandbox!

Using Flatpak Firefox is simply less secure, as one layer of Sandboxing is entirely removed. Especially if you use your browser more as a platform than a program, where the protection between browser and OS may be less important than between processes within the browser.

I also honestly think that nowadays, when many users use their browser as a platform (remote work, remote desktop, document editing, online banking, shopping, music, chat, social media, etc. all in the browser), the removal of this sandboxing layer significantly compromises the security.

Other browsers (e.g. Chromium-based) are less affected by Flatpak, because they use a different sandboxing technology, but the workaround applied for them is less conventional and less tested than their original implementations.

I really hope that Flatpak can provide a proper sandboxing API for such usecases (i.e. browsers) in the future, if I understand it right they already started the discussions on this topic.

Suggestions/questions:

  • Based on this information, in my opinion, maybe Flatpak Firefox should not be the default browser shipped with the ublue distros, but maybe a properly de-googled Chromium-based Flatpak browser would be a better approach.
  • Or maybe even an ostree Firefox is better?
  • Or at least the users should be clearly notified somehow of these security consequences, so that they can make their choices.
  • (I think installing and using a browser from inside distrobox might be too complicated for non-technical users, so I’m not listing it as a suggestion for the default browser.)

What are your thoughts on this?

Thanks,
etvt

1 Like
2

Can you provide a single example of a flatpak browser being exploited where the native RPM version of the same browser was not affected?

Has Mozilla made a single public statement about this given that the flatpak is listed as an option on their website?

3

That is the correct place to have this discussion and it doesn’t have anything to do with us.

4

I think this is in interesting discussion. Thanks for the links you provided.

Just to be clear, security isn’t a binary thing, hell it’s not even a sliding scale, it’s completely multi dimensional dependent on your particular threat model. For sake of argument, sandboxing may be weaker, but if a Flatpak means you get faster updates, it becomes a pro and cons consideration.

UBlue is not alone in making the decision to ship Firefox as a Flatpak, MicroOS is also doing the same. If you are worried about it being a bad call for your threat model it’s actually pretty easy to layer Firefox back into Bazzite and use the Fedora packaging, free of the Flatpak sandbox issues.

I’d love to see an actual open security vulnerability around exploiting the weaker sandbox. I don’t know if it’s just theory at this point or if security researchers have a working proof of concept.

5

From what I’ve heard Firefox in general has a worse security than Chromium (saying this, I still use Firefox).

No, Chromium flatpak sandbox with zypak is often considered worse. I think that’s why secureblue uses a hardended Chromium RPM instead.

About informing users, I think this is a hard choice, users may panic and freak out or they may have a realistic understanding, that’s pretty tough ig. I’d say put it in the docs for those who wants to learn more, but like not a huge red warning when opening the app.

Overall, I think it is a concern, but I don’t think it is a big one for the average user. I think this is more of an upstream Firefox issue (seeing as Flatpak is official) and I don’t think the Universal Blue team can just make Flatpak Firefox better. I’d say you should just use secureblue anyways if this is a concern for you.

6

i believe that even tho it doesnt use the namespaces it still uses the flatpak sandbox, if you make it strict enough it should be fine for regular usage. anyways that probably doesnt affect like anyone