My main issue with Firejail is that it still uses a SUID binary, compared to bwrap which has supported rootless operation for a while now. If you have to use SUID I think it's no better than using the same functionality in Docker or systemd, which are probably already on your system if you're a developer. Though I would love to hear if anyone has any other use cases where firejail really shines compared to the other similar tools to manage namespaces and seccomp.
It might eventually be possible to relax this restriction and get rid of the SUID but I expect they would have to really clean up the kernel API, and that takes priority over fixing the userspace sandbox.
You can't spin up a veth network device without a suid executable. A better approach would be to have most of the sandboxing code run unprivileged and only call a more specialized suid helper for the networking stuff.
> Though I would love to hear if anyone has any other use cases where firejail really shines compared to the other similar tools to manage namespaces and seccomp.
It also supports sandboxing X11 and dbus. So in that sense it's more like flatpak than docker.
Yes, I should have said "without elevated privileges". That capability is still a pretty big hammer you want extracted into a helper that only does one thing.
+1, escalating privileges in order to drop privileges is counterintuitive and risky.
This was the best possible solution for a while, but things are getting better with Landlock introducing unprivileged sandboxing for file accesses. There are helper libraries in Go and Rust at https://github.com/landlock-lsm, and it's easy to play around with it with the landlock-restrict example tool:
The web browser I'm writing this from is sandboxed using the same example tool, so this works for bigger software as well. :) (Full disclosure, I'm the author of the go-landlock library.)
I'm having high hopes that this'll get used by a lot of other sandboxing software as well. :) (If you run into issues, please file bug reports, I'm interested to hear about it.)
firejail is also super super insecure: https://www.cvedetails.com/vulnerability-list/vendor_id-1619.... the vast majority of these are trivial bypasses, like "what happens if i mount over /etc/shadow". everyone that can access firejail has a one-inch wall between them and full root access. by default, installing firejail gives everyone on the system access, so installing firejail is basically the closest thing to making everybody root unless you manually configure it to only allow certain users access.
Maybe this is a stupid question, but what's the point of an application that's intended to make your system more secure but actually makes it less secure? Do the firejail maintainers not realise? Or do they not agree that it's insecure? Or what? I can't reconcile these CVEs with anyone ever wanting to use firejail ever.
I think the assumption is that the user, outside the jail, is already trusted. (You're running this on your personal laptop, etc.) Therefore it "doesn't matter" if they can abuse firejail to get root, they already have that ability. (Not an endorsement.)
I see, so the system gains strength against untrusted code (Zoom client, Javascript in the browser, etc.) at the cost of losing strength against the local user. If so then the benefit is really balanced on a knife edge! If the sandboxing is not implemented, or fails, then the untrusted code can run with root privileges!
For typical single user with DE it's not that much tipped-once you can write to real $HOME you easily go to have root through replacing sudo password dialog or similar. Most desktop-targeted distributions drift towards the console user having a lot of privileges already (but not directly root access).
Pointing to CVE lists is misleading. Not all programs have enough eyes on them to even get CVEs, and many programs don't file CVEs for security fixes. Bubblewrap has shared more than one CVE in this list but it was never reported for that.
To me it seems there is contest right now between bwrap + selinux vs firejail + apparmor, no idea to what degree this is false observation, but I prefer to use firejail + apparmor, because configuration is less obfuscated (in sense) and way easier to tweak to my needs.
You can toggle between the SUID and unprivileged user namespaces implementation at compile time. I think most distros are shipping the unpriv'd userns configuration, and if they aren't they should be.
It might eventually be possible to relax this restriction and get rid of the SUID but I expect they would have to really clean up the kernel API, and that takes priority over fixing the userspace sandbox.