4 ms·
I don’t hear good comments on the quality of firejail sandbox, compared to flatpak or snap.
by aborsy 3y ago
I don’t hear good comments on the quality of firejail sandbox, compared to flatpak or snap.
- nateb2022 3y agoFirejail, Flatpak (which uses Bubblewrap under the hood), and Snap (which uses AppArmor) all use the same underlying technology: Linux namespaces. For those wondering about their differences, Firejail provides a helpful overview here: https://github.com/netblue30/firejail/wiki/Frequently-Asked-Questions#how-does-it-compare-with-docker-lxc-nspawn-bubblewrap https://github.com/netblue30/firejail/wiki/Frequently-Asked-... TL;DR: Firejail has much more comprehensive features than Flatpak (Bubblewrap). Firejail also has more comprehensive network support, support for AppArmor and SELinux, and easier seccomp filtering. Compared to Snap (which uses AppArmor), Firejail is not only compatible with AppArmor but again goes above and beyond with a lot of additional features.
- kd913 3y agoIt isn't just linux namespaces, you have mounted namespaces, cgroups, seccomp filters etc... From what I remember it certainly isn't as simple as you present it and additional features tends to involve additional surface area. Other aspects in the past was that Firejail's approach to capabilities and namespaces enabled it to act as a setuid binary to gaining root privileges on the host. Snaps I seem to recall had defined mounted namespaces that didn't need this privilege escalation. Their apparmor profiles are well defined and tunable via the connections mechanism. Although I seem to recall that too having some CVEs present. In terms of trust though, I rather do trust snaps a lot more than firejail even if the latter is more tunable. I see that latter aspect as a downside, relative to snaps which already come confined and tuned. There is also systemd itself which can be used in a similar way, and also has quite a nice tool for checking the exposure of a given sandbox.
- totallywrong 3y agoThe snap daemon runs as root, is a resources hog, and really only works well in Ubuntu. Oh and snaps in general suck sooo much, but that's of course just an opinion.
- ranger_danger 3y ago> I rather do trust snaps a lot starting with the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. You’ve as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it installs itself without asking you.
- kd913 3y agoI have pinned them, I have patched them, I have written versions of them including Thunderbird and Firefox along with my own theming ones. I know the reasons why canonical only keeps one store and it seems rather sane to me. Especially after hearing about the mess with PPAs. I can run within their environment and unpack their squashfs. The snap runtime is very plain in GitHub. Please stop sharing FUD.
- weinzierl 3y agoIf namespaces are not enough isolation for you then there is always Firecracker.
- XorNot 3y agoUrgh...that list of security features gives me a headache though. That's the problem with all these systems: Linux keeps growing more. Some of them overlap, some don't. "Best practice" tends to be "use all of them" but what's "all"? We've got a real problem that the scope of things which have to be controlled keeps growing, and the ways to do that keep increasing as well. And perhaps worse: there's precious little documentation of the implications of turning some of these features off. But that's far and away the most common thing you need to do because usually you have something that's broken, unless you disable a "security" feature.
- deleted 3y ago[deleted]