Secure Firefox using native sandbox, Flatpak (Flathub/Fedora) | Discussion / Clarification

Ask Fedora
, , , , , , , , ,
1

I am a bit confused about this topic, would like some explanations and also to discuss some ideas.

Currently I use Flathub Firefox Flatpak due to:

  • official Kinoite image with no nonfree packages from rpmfusion, less attack surface
  • so: media codecs
  • official support by Mozilla
  • Containerization with portal integration, i.e. isolation from my system

Solving the Codec problem

Using ublue’s version of kinoite can help, for being not alone with possible issues. When I last checked though, rebase was not possible due to signing problems, which is probably something good.

Doing this manual override-replacement works too. There are two ways, the complete or the “just video codecs” variant, described in this post (link following)

Sandboxes

I heard that the native app sandbox of Firefox and Chromium would be better than bubblewrap, which is used by Flatpak.

I dont know how this would be, as the native version has rw access to my complete home folder. It may be less protected against system files, but I am curious if that is true.

SELinux

I only have a very rough understanding of SELinux. But I suppose, when configured very well, it gives great security.

Does every app need its own SELinux profile, or are there generic ones? I can’t imagine that every small Flatpak or even third party app has a SELinux profile.

Is Fedora Firefox better protected through SELinux than Flathub for example? Or mozillas binary in general, which the Flathub version executes inside the container?

Hardware access

A big reason not to use the Flatpak is hardware access, for Yubikey/Nitrokey etc. authenticators. But I think this should also be hardened, so that Firefox doesnt actually have all that access over all my drives?

Could someone elaborate what exactly Firefox can and can’t do, and if there are easy, non-breaking changes one could apply to give it less, but the needed permissions?

Filesystem Sandboxing

I tried using firejail but it was a buggy mess. Broke screenshots in several applications at once, not a great experience at all.

Also, can SELinux replace its functionality? I would prefer to use SELinux instead of using another community based software running in parallel.

Wayland, Pipewire, hardware access

Do you have any infos about differences here? I had pretty weird, and okay behavior with some apps.

Another idea / question: immutable Browser

Even if the browser itself is sandboxed, there may be a security hole that allows malware to change the browser itself. As its pretty much the core Part of every OS nowadays, that would be extremely critical.

Idea:

  • immutable Browser
  • two versions, a verified image / directory containing the browser files
  • the browser in use
  • users can apply overrides, for example settings, user.js, Addons etc
  • the rest gets overwritten by the up-to-date but unused browser image

This would only make sense if this “overwrite browser” would be secured somewhere no apps can write apart the core OS elements like rpm-ostree.

Question: is this viable, useful, overacting? Would this be something worth doing, at least in some scenarios?

Thanks in advance!

2

Direct access to user namespaces isn’t available inside the flatpak sandbox because that would enable sandbox bypass, but flatpak does provide a portal API to create a more restrictive sub-sandbox. Chromium-based flatpaks use that via zypak (Chromium itself uses a patch from the same author).

The Firefox flatpak doesn’t use that API because it would cause excessive memory usage without some architectural changes. This isn’t as bad as it sounds because Firefox apparently doesn’t rely on namespacing for its sandbox; it’s rather defense in depth.

To my knowledge, SELinux is not used for confining flatpak apps. Flatpak does ship a policy module, but it’s only for flatpak-system-helper. In general, Fedora’s SELinux policy mostly confines system services.

The Firefox flatpak currently has the devices=all permission. More portals are needed to cover the remaining use cases before that can be disabled by default. However, I don’t think any core functionality would break if you choose to override it.

5 Likes
3

Generally speaking, SELinux comes “configured very well” out of box with Fedora. One thing to understand is that AppArmor, which Ubuntu, SUSE, etc., use by default fundamentally defines policy around applications. SELinux fundamentally defines policy around files. SELinux is more complicated, but it’s also more powerful and far more granular. That said, the default policies that ship in Fedora are already written with desktop applications and such in mind. It’s very unlikely that you’ll encounter something that needs tweaking with SELinux policy and these browser methods.

If you’re looking for something that can specifically tweak flatpak access to system resources, then you can check out FlatSeal with the necessary caveat that it will let you lock it down to the point of breaking basic functionality.

For non-flatpak desktop applications, if you want to get into the weeds, there’s polkit, which already exists in Fedora by default. Again, with the caveat that it is possible to break functionality.

You very likely do not need to do anything more here (and probably shouldn’t if general desktop environment reliability is a primary concern), but there are tools available if you want to take a deeper dive into more granular controls for the sake of your own understanding.

I have good news for you about this one!

podman run --rm -it alpine/lynx https://duckduckgo.com

2 Likes
4

This conversation just inspired me to do this!

1 Like
5

Hi, thanks for the clarification about SELinux. Indeed, having file access control seems pretty nice as it should be easier for Devs to use it? I posted a discussion about SELinux on Lemmy and many people said SELinux was just very user-unfriendly, in the sense of “users creating Apps” and thus many projects require you to disable it, which sounds crazy.

Polkit sounds interesting, I use it already a bit, before mainly to grant wheel more rights like LUKS mount or KDE-Partitionmanager, but also looking into Atomic DE automatic updates… But its mostly for escalated sudo privileges for apps, right?

KDE has Flatpak permission control already integrated. I already created a “flatpak permission cleaner” tool once, replacing host access of all installed apps (when existing) with all the possible media folders. You may argue thats irrelevant, I dont see the problem here, but people didnt like the idea on Flathub. The underlying issue is huge Projects like Libreoffice, GIMP, Inkscape not being able to adopt Portals yet.

6

It does seem unfriendly to those who are creating their own apps and do not take into account the way selinux works. Since selinux uses policies and attributes to determine what access such programs are granted and what files are allowed to be accessed then users must take the extra selinux security into account when creating and packaging their apps.

Disabling selinux is only needed for those who deliberately fail to learn about it.

2 Likes