Sorry for giving a rather useless advice. Of cause, you know about native packages, but since you are asking about flatpak, you, probably, have a reason to chose it. So, my original message was mostly intended as a joke, for which I am sorry.
libseccomp is a long established security “firewall for syscalls”, it allows to restrict what actions programs can perform on the system.
I dont know what exactly these are, often low level stuff I guess, but one of these actions is “create an unprivileged user namespace”.
Flatpak uses a single, “badness enumerating” seccomp filter, which means they block the syscalls “A”, “B” and “C” for all programs. All others are allowed, and (see the issue) programs cannot define a more restrictive one.
user namespaces
A namespace is a virtual filesystem on top of the “real” one, where certain real system files are mounted to. This means unprivileged programs can suddenly do “OS stuff”, needed to create this filesystem.
contra user namespaces
Many distros like Debian (and Arch) didnt enable this feature for a long time, because user namespaces mean that unprivileged userspace programs, like your browser, can suddenly access low level system components like the filesystem.
If there now is a bug in such a component, user namespaces allow the program to directly access a way more privileged area, escape here and thus have privilege escalation.
This would not be possible when not using user namespaces.
Flatpak has a seccomp filter that blocks the creation of user namespaces, to avoid this low level system access. Which is a very good thing, but the missing modularity doesnt allow anything else!
pro usernamespaces
Over time even slow pacing distros like Debian enabled user namespaces.
Today they are the core feature of bubblewrap, podman, docker, (and thus distrobox and toolbox)…
The concept is that a rootless binary, running in userspace, can access system components which would normally require root.
Firejail is the opposite example, it is a root binary and sandboxes apps also when user namespaces are disabled. Chromium has a fallback suid sandbox which also is a root, same with bubblewrap after the modification by 34N0 implemented in the “no userns” images of secureblue.
The problem is, a root binary has root access. If there is a flaw in it, which was the case with firejail, the “nice and secure isolated app” could now use the root binary to escalate its privileges to root level, more than what it could have done without it.
Browsers and Sandboxes
A browser is basically a platform to run “apps” on. Nearly all websites nowadays require executable code, which means browsers are the attack surface for malware. Scrap your verified Flathub or well maintained distro repository, a single website could use a weakness and break your system.
This was a thing back in the time… crazy huh?
Chromium (Chrome, Edge, Brave, Vivaldi, Opera, …) has the said rootful sandbox as a fallback, I guess implemented back when user namespace sandboxes were not adopted enough.
But is normally uses a user namespace sandbox for process isolation, every tab runs in a different process, on Android too.
Firefox also uses user namespace sandboxes for tabs, but additionally uses seccomp-bpf to restrict the syscalls that the isolated tabs/processes can execute.
Flatpak and Chromium
Chromium relies exclusively on the ability to create sandboxes, with a root binary (the strange not really used fallback method) or with user namespaces.
So much that it straight up doesnt run if it cannot do that. The same goes for Electron apps, which are a browser platform running a single or very few processes.
This is why zypak was created. It redirects the calls of Chromium to flatpak, so it uses the builtin Flatpak sandbox instead.
As I said, all Flatpak apps (and thus all processes) use the same seccomp filter, so I assume that zypak is less secure than the native sandbox, which is battle tested by Google, Microsoft and more companies.
But it uses a sandbox, it is rootless and uses user namespaces. It just needs a little testing, a security audit, a bit of pentesting.
At the current stage I would honestly not trust it, so Flatpak Chromium browsers are not recommended for “production”.
Right now we just fork(), so replacing that with flatpak-spawn would cause a massive increase in memory usage? You would no longer have CoW sharing of memory.
So Firefox would need big architectural changes to support a sandbox like Flatpak’s. It uses copy-on-write to save Memory and be more efficient.
For some reason Chromium works just fine with zypak.
it’s not clear to me the “Flatpak Sandbox” it’s creating is comparable to what we have now (even with just seccomp-bpf). We launch our subprocesses with specific, nailed down sandboxes.
They should absolutely compare their seccomp filters. But this indicates the same issue as the one at the beginning, always using the same seccomp filter is not suited for an entire platform like a browser.
Fair usage in Flatpak
To sum it up:
Electron apps are likely fine to be ran as Flatpaks. The zypak sandbox may not isolate the processes from another as well as the normal one does, but they are controlled and known code.
Electron uses Chromium because of laziness, not because it needs the security of the platform. Daniel Micay, the creator of GrapheneOS, would also list a few very technical things why Electron has crippled security features of Chromium.
Thunderbird is using Firefox similar to Electron, just as a platform for known code, so this will be fair too.
Flatpak Firefox… is probably okay secure. If you use UBlock Origin with some filterlists, and an opt-in NoScript setup (which I highly recommend for privacy and security), the risk is even lower.
But the risk is literally getting malware, losing all your data, getting breached or intruded. So why leave out this security measurement.
But, its true, Flatpak isolates the browsers from the system, which is really nice. If there is a weakness in the browser platform, a process could not just escalate and access everything Firefox can.
Bubblejail
So isolating the browser from the system using Bubblewrap, a modern and rootless sandboxing tool, sounds like a good idea.
The only issue is the always-the-same seccomp filter. The best solution would be a fix for the issue at the beginning, but for now we can use bubblejail.
It is a tool that makes the creation of bubblewrap and seccomp filters easy, and adds Desktop entries to launch existing apps through that sandbox.
For some reason it doesnt work at all anymore for me… but it did in the past. It is certainly not ready, but with some helping hands it can fix all the gaps, where system apps are needed for certain abilities.
May that me a VPN app, Nextcloud-client adding icons to your task manager, an IDE like VSCodium, Zed, Lapce, Kate… or isolating all your system apps!
So currently I use Fedora Firefox, which is very well maintained and checked for security build flags.
I will continue making bubblejail work, which will be a good solution for this problem.
Probably best that you do the same (installing packages in the FS overlay kind of starts to defeat the point of containerization). You could try installing it with a distrobox and then exporting the app—see if that fixes your loading issues.
I run Bazzite on a gaming laptop from 2015, and I haven’t noticed any particularly long load times. Do you have some browser extension(s) that are maybe causing issues?
My only extension is uBlock Origin but it isn’t the problem (I uninstalled it to test and nothing changed). Thanks for your suggestion, I’ll try to play with distrobox (I’m new to Bazzite and immutable distros).
Distrobox will introduce a startup lag of it’s own. I would rather recommend (seriously this time) something like nix (it is officially supported for your distro) or junest.
Nix might have been removed. I’ll have to check, but I feel like the ujust command forv setting up nix went away a version or two ago.
But I think you can set distroboxes to run at startup, so you’d never know the difference when it came time to actually launch the program. Right (correct me if I’m wrong)?
Maybe, I do not use bazzite and cannot check. But it used to be a feature. You can, of cause, start distrobox at startup, but literally running almost two operation systems might not be the best for performance and RAM usage.
Fortunately, it does not usually cause high load, but it still exists. The only thing I can recomend here is to always check if the dependencies of any package you install in container require to run in the background and avoid those which do.
Is it? I was looking a few months ago at Nix support in Fedora Atomic (which Bazzite is based on), and it required some minor hacks to get the /nix folder and Nix itself working properly with rpm-ostree distros, as root is otherwise immutable. Plus, Nix isn’t available by default in the Fedora repos it seems. I believe it required something along the lines of making a /var/nix folder and symlinking it, but I believe you’d also have to work around SELinux contexts on the folder and symlink. I’ve heard of people even having issues after that, so I wouldn’t consider it “official” support. Here’s an open issue thread about it
Well, I know it used to be available and officially supported through available installation script. I do not have bazzite installed right now and their website does not have a proper documentation, so I can not check if it is available now.
Oh thx for the info, I can maybe try with rpm-ostree in the case of lag. Nix is very good but I’m liking Bazzite very much for my needs, everything else seems working very good.
Sounds about in line with what I’d expect. If that works for you where the flatpak doesn’t, then it at least makes a viable solution for the short term (though I don’t know how much overhead would be introduced). A minute of delay is ridiculously long for startup, so I still don’t know why you were having that issue with the flatpak
You can try rpm-ostree to install in the lowest userspace layer, but Bazzite purposely switched to flatpak Firefox and discourages installing software using rpm-ostree, unless you absolutely have to.
IMHO I would avoid the ublue distros and just go for official fedora spins. The guys have good intentions, but they don’t have the means to maintain that many distros “properly”. I often end up enabling copr packages for bazzite in my fedora install, just to find out the program doesn’t work.
That being said, as the other comments told you, you can still install native apps on immutable distros, it’s just a bit more work.
I don’t expect distrobox or toolbox to be much faster than flatpak, as they are all just containers with a nice cli, except flatpak is easier to update. But trying costs nothing
but they don’t have the means to maintain that many distros “properly”
That’s why they’re not separate distros from Fedora (as in, they don’t even host their own RPM repos nor maintain their own set of Fedora packages like Manjaro vs Arch) and purposefully so. It’s just stock Fedora with a few configs, third party repos/packages, and some scripts preinstalled. The entire thing runs on GH actions.
Native packages? Sorry.
Sorry for what? I’m trying a fresh install of Bazzite so the distro prefers flatpaks.
Sorry for giving a rather useless advice. Of cause, you know about native packages, but since you are asking about flatpak, you, probably, have a reason to chose it. So, my original message was mostly intended as a joke, for which I am sorry.
Yeah that is a dumb decision of the uBlue folks. I really like their tooling but their Flatpak browser stuff (and a bit more) are annoying.
You also cant even layer Firefox, due to this rpm-ostree bug
https://github.com/coreos/rpm-ostree/issues/4554
Make some noise there if you want.
Just curious why you think it’s dumb. I think it’s a great idea, since it gives more protection by containerizing the app.
Like I told OP, I haven’t had any particularly long load times, but “long” is a subjective measure, after all.
It is a great idea but the concept is flawed
This issue helps to understand it
seccomp background
libseccompis a long established security “firewall for syscalls”, it allows to restrict what actions programs can perform on the system.I dont know what exactly these are, often low level stuff I guess, but one of these actions is “create an unprivileged user namespace”.
Flatpak uses a single, “badness enumerating” seccomp filter, which means they block the syscalls “A”, “B” and “C” for all programs. All others are allowed, and (see the issue) programs cannot define a more restrictive one.
user namespaces
A namespace is a virtual filesystem on top of the “real” one, where certain real system files are mounted to. This means unprivileged programs can suddenly do “OS stuff”, needed to create this filesystem.
contra user namespaces
Many distros like Debian (and Arch) didnt enable this feature for a long time, because user namespaces mean that unprivileged userspace programs, like your browser, can suddenly access low level system components like the filesystem.
If there now is a bug in such a component, user namespaces allow the program to directly access a way more privileged area, escape here and thus have privilege escalation.
This would not be possible when not using user namespaces.
Flatpak has a seccomp filter that blocks the creation of user namespaces, to avoid this low level system access. Which is a very good thing, but the missing modularity doesnt allow anything else!
pro usernamespaces
Over time even slow pacing distros like Debian enabled user namespaces.
Today they are the core feature of bubblewrap, podman, docker, (and thus distrobox and toolbox)…
The concept is that a rootless binary, running in userspace, can access system components which would normally require root.
Firejail is the opposite example, it is a root binary and sandboxes apps also when user namespaces are disabled. Chromium has a fallback
suidsandbox which also is a root, same withbubblewrapafter the modification by 34N0 implemented in the “no userns” images of secureblue.The problem is, a root binary has root access. If there is a flaw in it, which was the case with firejail, the “nice and secure isolated app” could now use the root binary to escalate its privileges to root level, more than what it could have done without it.
Browsers and Sandboxes
A browser is basically a platform to run “apps” on. Nearly all websites nowadays require executable code, which means browsers are the attack surface for malware. Scrap your verified Flathub or well maintained distro repository, a single website could use a weakness and break your system.
This was a thing back in the time… crazy huh?
Chromium (Chrome, Edge, Brave, Vivaldi, Opera, …) has the said rootful sandbox as a fallback, I guess implemented back when user namespace sandboxes were not adopted enough.
But is normally uses a user namespace sandbox for process isolation, every tab runs in a different process, on Android too.
Firefox also uses user namespace sandboxes for tabs, but additionally uses
seccomp-bpfto restrict the syscalls that the isolated tabs/processes can execute.Flatpak and Chromium
Chromium relies exclusively on the ability to create sandboxes, with a root binary (the strange not really used fallback method) or with user namespaces.
So much that it straight up doesnt run if it cannot do that. The same goes for Electron apps, which are a browser platform running a single or very few processes.
This is why zypak was created. It redirects the calls of Chromium to flatpak, so it uses the builtin Flatpak sandbox instead.
As I said, all Flatpak apps (and thus all processes) use the same seccomp filter, so I assume that zypak is less secure than the native sandbox, which is battle tested by Google, Microsoft and more companies.
But it uses a sandbox, it is rootless and uses user namespaces. It just needs a little testing, a security audit, a bit of pentesting.
At the current stage I would honestly not trust it, so Flatpak Chromium browsers are not recommended for “production”.
Flatpak and Firefox
The Firefox Flatpak is official.
Thats what I asked byself and created this issue but honestly, this issue thread is way more informative.
So Firefox would need big architectural changes to support a sandbox like Flatpak’s. It uses copy-on-write to save Memory and be more efficient.
For some reason Chromium works just fine with zypak.
They should absolutely compare their seccomp filters. But this indicates the same issue as the one at the beginning, always using the same seccomp filter is not suited for an entire platform like a browser.
Fair usage in Flatpak
To sum it up:
Electron apps are likely fine to be ran as Flatpaks. The zypak sandbox may not isolate the processes from another as well as the normal one does, but they are controlled and known code.
Electron uses Chromium because of laziness, not because it needs the security of the platform. Daniel Micay, the creator of GrapheneOS, would also list a few very technical things why Electron has crippled security features of Chromium.
Thunderbird is using Firefox similar to Electron, just as a platform for known code, so this will be fair too.
Flatpak Firefox… is probably okay secure. If you use UBlock Origin with some filterlists, and an opt-in NoScript setup (which I highly recommend for privacy and security), the risk is even lower.
But the risk is literally getting malware, losing all your data, getting breached or intruded. So why leave out this security measurement.
But, its true, Flatpak isolates the browsers from the system, which is really nice. If there is a weakness in the browser platform, a process could not just escalate and access everything Firefox can.
Bubblejail
So isolating the browser from the system using Bubblewrap, a modern and rootless sandboxing tool, sounds like a good idea.
The only issue is the always-the-same seccomp filter. The best solution would be a fix for the issue at the beginning, but for now we can use bubblejail.
It is a tool that makes the creation of bubblewrap and seccomp filters easy, and adds Desktop entries to launch existing apps through that sandbox.
For some reason it doesnt work at all anymore for me… but it did in the past. It is certainly not ready, but with some helping hands it can fix all the gaps, where system apps are needed for certain abilities.
May that me a VPN app, Nextcloud-client adding icons to your task manager, an IDE like VSCodium, Zed, Lapce, Kate… or isolating all your system apps!
So currently I use Fedora Firefox, which is very well maintained and checked for security build flags.
I will continue making bubblejail work, which will be a good solution for this problem.
Probably best that you do the same (installing packages in the FS overlay kind of starts to defeat the point of containerization). You could try installing it with a
distroboxand then exporting the app—see if that fixes your loading issues.I run Bazzite on a gaming laptop from 2015, and I haven’t noticed any particularly long load times. Do you have some browser extension(s) that are maybe causing issues?
My only extension is uBlock Origin but it isn’t the problem (I uninstalled it to test and nothing changed). Thanks for your suggestion, I’ll try to play with distrobox (I’m new to Bazzite and immutable distros).
Distrobox will introduce a startup lag of it’s own. I would rather recommend (seriously this time) something like nix (it is officially supported for your distro) or junest.
Nix might have been removed. I’ll have to check, but I feel like the
ujustcommand forv setting upnixwent away a version or two ago.But I think you can set distroboxes to run at startup, so you’d never know the difference when it came time to actually launch the program. Right (correct me if I’m wrong)?
Maybe, I do not use bazzite and cannot check. But it used to be a feature. You can, of cause, start distrobox at startup, but literally running almost two operation systems might not be the best for performance and RAM usage.
Could be a case for
toolbox, which I admittedly know even less about. Either way, people here have offered several options to try!Toolbox is effectively the same thing as distrobox. It is a linux distro inside docker-like container. They even use the same images.
Are there any processes in particular that I should keep an eye on? At the moment I don’t notice any new particularly high load.
Fortunately, it does not usually cause high load, but it still exists. The only thing I can recomend here is to always check if the dependencies of any package you install in container require to run in the background and avoid those which do.
Is it? I was looking a few months ago at Nix support in Fedora Atomic (which Bazzite is based on), and it required some minor hacks to get the
/nixfolder and Nix itself working properly withrpm-ostreedistros, as root is otherwise immutable. Plus, Nix isn’t available by default in the Fedora repos it seems. I believe it required something along the lines of making a /var/nix folder and symlinking it, but I believe you’d also have to work around SELinux contexts on the folder and symlink. I’ve heard of people even having issues after that, so I wouldn’t consider it “official” support. Here’s an open issue thread about itWell, I know it used to be available and officially supported through available installation script. I do not have bazzite installed right now and their website does not have a proper documentation, so I can not check if it is available now.
Oh thx for the info, I can maybe try with rpm-ostree in the case of lag. Nix is very good but I’m liking Bazzite very much for my needs, everything else seems working very good.
You don’t quite understand me, it seems. I do not mean nixos distro. Nix is already available inside Bazzite as an additional package manager.
In fact I hadn’t thought about it, I always tried Nix as a separate distribution.
Ok I’m writing this thru Firefox (distrobox) and it works pretty well, no lag noticed.
The lag would be noticeable when you launch Firefox with stopped container (for example after reboot or manual stop).
Ok, I’ve tested this, I’ve noticed a lag of a couple of seconds for the first time I launched a distroboxed app.
Sounds about in line with what I’d expect. If that works for you where the flatpak doesn’t, then it at least makes a viable solution for the short term (though I don’t know how much overhead would be introduced). A minute of delay is ridiculously long for startup, so I still don’t know why you were having that issue with the flatpak
You can try
rpm-ostreeto install in the lowest userspace layer, but Bazzite purposely switched to flatpak Firefox and discourages installing software usingrpm-ostree, unless you absolutely have to.Oh I forgot about rpm-ostree ty! In this case of flatpak not working it is suggested rpm-ostree or distrobox?
Recommended installation order is:
toolboxshould also be installed on your system, and it works similarly todistrobox, but I’m less familiar with it.Thank you!
IMHO I would avoid the ublue distros and just go for official fedora spins. The guys have good intentions, but they don’t have the means to maintain that many distros “properly”. I often end up enabling copr packages for bazzite in my fedora install, just to find out the program doesn’t work.
That being said, as the other comments told you, you can still install native apps on immutable distros, it’s just a bit more work. I don’t expect distrobox or toolbox to be much faster than flatpak, as they are all just containers with a nice cli, except flatpak is easier to update. But trying costs nothing
I’ve “solved” using distrobox, it work pretty well and I don’t see any lag. Bazzite is a very good distro imho, the problem is more on Firefox here.
While toolbox and distrobox seem very similar, distrobox comes with a slight warning :
That’s why they’re not separate distros from Fedora (as in, they don’t even host their own RPM repos nor maintain their own set of Fedora packages like Manjaro vs Arch) and purposefully so. It’s just stock Fedora with a few configs, third party repos/packages, and some scripts preinstalled. The entire thing runs on GH actions.