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.
I wonder how practical it is to use a VM per application instead. Of course, Qubes has already done this, but it uses Xen. What would be the minimum practical overhead per VM, when each VM needs to run a single-application GUI stack?
For graphical applications the overhead might be tricky. AFAIK, you'd need to do lots of copying video buffers.
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).
I hope eventually, with systems like landlock making sandboxing a bit more accessible, developers just start sandboxing their software by default. 3rd parties maintaining policies is less than ideal.
Landlock still falls short of pledge() in some ways, one of them is that inheritance is mandatory which disincentives its use in tools that spawn other processes. I hope that linux will adopt something pledge-like one day.
If an executable spawns child processes by design then inheritance means you need the union of all capabilities. Without inheritance each executable can apply a smaller set of privileges to itself.
Anyway, pledge[0] provides both options separately. You can restrict capabilities for just the current process and then for child processes.
But of course the parent needs the union of its child permissions. Otherwise how could it delegate them? A child process is still able to restrict itself further if it wants to, for example you could let it make the prctl syscall.
> But of course the parent needs the union of its child permissions. Otherwise how could it delegate them?
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.
Sorry, I'm not getting it. This all sounds like normal sandboxing. Also, if you don't trust your child processes to sandbox you can fix that with an intermediary process.
With sandboxing of the bubblewrap or firejail flavor you have one externally applied ruleset to a tree of processes. This ruleset must be lax because it is the union of all the permissions the processes may need at any time and on any execution path. This is bad because it makes your sandbox more permissive than necessary and specific points in time for specific processes
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.
Even with self-sandboxing filters that won't be inherited can be made more tight than the inherited ones. Maybe you could fork a spawn helper at program startup before installing the filters to emulate this behavior, but that makes IPC more complicated.
I hope so too :) There are libraries at https://github.com/landlock-lsm to simplify that, I'm using these productively for a few months.
(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.
eBPF was the initial proposal, but Landlock didn't go with it in the end. It's just using a set of regular system calls, the logic behind it is just implemented in C in the kernel as a LSM.
> developers just start sandboxing their software by default
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.
> 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
> 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.
I’m using Firejail as an additional layer of defense on some machines.
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.
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.