Firejail: Linux namespaces and seccomp-bpf sandbox
github.com
github.com
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.
> 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.
Doesn't this just require CAP_NET_ADMIN?
If the user account is compromised all valuable data (password, keys) is gone.
Gaining root is hardly useful to an attacker.
The devs patched it up super quickly, but I'm still a bit skeptical. It's probably still better than nothing...
>Bubblewrap could be viewed as *setuid* implementation of a subset of user namespaces. Emphasis on subset [...]
Distros without user namespaces will probably still ship the SUID version though.
systemd: yes, but firejail comes with friendly profiles for most applications
docker: not at all, it has a much higher attack surface
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:
$ go install github.com/landlock-lsm/go-landlock/cmd/landlock-restrict@latest
$ mkdir /tmp/lolcat
$ HOME=/tmp/lolcat landlock-restrict -ro /usr /lib /etc -rw /tmp/lolcat -- /bin/bash
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.)
A lot of valid solutions are counterintuitive.
Currently I use the flatpak w/ settings tweaked on flatseal.
It's not perfect, but better than nothing.
Connection with things like notification daemon would also be tricky -- each service would need some form of proxy (though we also do that with containerised applications right now).
By restricting which syscalls can be used during the current process to a narrow, non-inheritable Set A while, restricting which child executables can be called to Set F and those child executables have their own permission Sets B, C, etc. Additionally you can also put an inheritable Supersets B' and C' on the children if you don't trust them entirely to self-sandbox properly, but those will be less narrow because the executables may need a few more syscalls during program init, before self-isolating.
That's one of the ideas behind pledge. You do some setup in the beginning, then lock yourself down. Similar to dropping root privs in network services, just more fine-grained. This works best if each process can limit itself tightly even when it spawns some helpers later which may transiently need some less tight restrictions.
A union of permissions for multiple executables is going to looser than necessary.
pledge on the other hand allows a process to gradually drop privileges as it goes down different code paths. E.g. it could initially retain permissions to open files and enumerate directories because it has an option to do things recursively. But after checking arguments and no recursive option was requested it just opens a fixed list of files and then drops those caps. But it's a fancy tool (like ripgrep) that might spawn helper programs to parse the content and those may still have to open files on their own. So just because it locally dropped its own capability to open files (but retained the cap to spawn processes) doesn't mean its child processes should inherit that restriction, they can lock themselves down. It can still choose to impose separate restrictions on child processes externally, but that's orthogonal to the self-restrictions.
This makes things more composable and allows for tighter sandboxing after program init.
(In fact, I'm sending this from a landlocked web browser. :))
This also ties into the discussion thread about firejail being suid-root - Other than namespaces, Landlock is an unprivileged sandboxing mechanism and doesn't need to escalate privileges in order to drop privileges.
For many kinds of software, I'd rather see the distribution or package maintainer work on the sand-boxing itself. I'm thinking stuff like Zoom or Skype where you actually wouldn't trust the app developer.
Personally, I like that Bubblewrap doesn't require the same level of privileging, and I like the consistency with Flatpak. It feels like an unnecessary increase in attack surface to be running completely separate sandboxing tools. But, there are also advantages to Firejail, I'm not saying you shouldn't use it.
Reminder that unless you're doing complicated things with X sessions, Wayland is an important part of sandboxing and you should probably assume that any graphical malware will be able to break out of a sandbox on an X system (not because it's impossible to sandbox X, just that if you're dabbling in this stuff you're probably not sandboxing it correctly). Honestly, you should probably use something more robust than either of these programs if you're worried about malware. I just think it's easier and safer to use a VM and importantly I think you're less likely to shoot yourself in the foot using a VM (although it is still possible for malware to escape VMs depending on how they're configured). I'm not a security expert, take that advice with many grains of salt.
----
A lot of these programs (in my opinion) lack really good documentation about how to work with them. You kind of need to know the basics of how they work before you start. I think if anyone ever wanted to create a really detailed guide about what the different options are, what the considerations are, stuff like that, there's a lot of opportunity there to single-handedly drastically improve the accessibility of these tools. Most guides I have seen assume you know already know how the underlying permissions, process isolation, network stuff all works -- even some of the better guides on Arch (https://wiki.archlinux.org/title/Firejail, https://wiki.archlinux.org/title/bubblewrap) are just not accessible unless you're willing to go down those rabbit holes and figure out all of the terminology being used.
It's not that the documentation doesn't exist, and once you understand how the command line options work they're kind of nice, but all of the documentation is kind of spread around and hard to find and there's a lot of pulling up manpages and looking up words that get dropped with no context -- if you happen to know Linux security even just reasonably well and you're ever looking around for an unmet need or niche that's possible for one person to solve on their own, then this is the kind of problem that could be fixed with like one in-depth blogpost series.
There's just a real need for more tutorials about this stuff that can be shared with people who want to do manual configuration or command line usage, but that don't necessarily have the background required to just jump into the Arch docs. I've thought about trying to make one, but I am very nervous about giving people bad advice since I'm mostly self-taught on a lot of the security stuff.
I haven't checked back though since I started using Bubblewrap, so also maybe I'm out of date and there's more documentation today.
> then this is the kind of problem that could be fixed with like one in-depth blogpost series
In the case of firejail the documentation is officially a selection of blog posts and videos in their wordpress website. While they cover a number of popular and general use cases, the software is complex enough that a good number of corner cases are missing.
But in-depth, ideally, is something as well written and well presented such as the docker docs. Blog posts get buried in SEO spam and are unfindable.
It’s not a silver bullet, and I get the feeling that the jails for Firefox/Chromium are not terribly constraining.
I also don’t think there’s a good way to poke holes for things like libnotify or links in browsers that go to native applications. This is a shame; I’d love the ability to have a link from Firefox under Firejail to poke out and run in Zoom or Slack under their respective sandboxes, or just to get native notification boxes.
Still, I think practically it does a lot to limit the blast radius of potential attacks, especially if you don’t expect to be explicitly targeted.