8 ms·
Firejail: Linux namespaces and seccomp-bpf sandbox
- throwaway82652 5y agoMy 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.
- loo 5y agoAn SUID binary written in C, no less.
- neatze 5y agoTo 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.
- the8472 5y agoYou 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.
- brobinson 5y ago>You can't spin up a veth network device without a suid executable. Doesn't this just require CAP_NET_ADMIN?
- the8472 5y agoYes, 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.
- throwaway82652 5y agoI hope it's possible to relax that capability in the kernel somehow, that may be a next step for someone working on sandboxing.
- throwaway82652 5y agoI was under the impression the X11 and dbus sandboxing was done with Xpra and xdg-dbus-proxy, which are not part of firejail.
- the8472 5y agoYes, but firejail integrates them, docker does not.
- throwaway82652 5y agoGood point, that's very helpful to know.
- Hello71 5y agofirejail is also super super insecure: https://www.cvedetails.com/vulnerability-list/vendor_id-16191/Firejail-Project.html 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.
- tome 5y agoMaybe 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.
- tedunangst 5y agoI 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.)
- tome 5y agoI 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!
- folmar 5y agoFor 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).
- traverseda 5y agobwrap is SUID. >Bubblewrap could be viewed as *setuid* implementation of a subset of user namespaces. Emphasis on subset [...] https://github.com/containers/bubblewrap#user-namespaces= https://github.com/containers/bubblewrap#user-namespaces=
- throwaway82652 5y agoI don't know why it says that, it's explicitly not: https://github.com/containers/bubblewrap/blob/34a8c8bc870783611bc1b10f504fcf00f9eaa08e/bubblewrap.c#L2633-L2640 https://github.com/containers/bubblewrap/blob/34a8c8bc870783... Distros without user namespaces will probably still ship the SUID version though.
- chlorion 5y agoYou 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.
- goodpoint 5y ago> If you have to use SUID I think it's no better than using the same functionality in Docker or systemd systemd: yes, but firejail comes with friendly profiles for most applications docker: not at all, it has a much higher attack surface
- gnoack 5y ago+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 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 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.)
- goodpoint 5y ago> escalating privileges in order to drop privileges is counterintuitive A lot of valid solutions are counterintuitive.
- makeworld 5y agoHappily using this for Zoom, I don't trust their security.
- staticassertion 5y agoWhy not just use the web app?
- smallerfish 5y agoThe desktop app does better image processing on your camera feed. That's about the only reason.
- Shared404 5y agoI've also found the UX much better on the desktop app. Currently I use the flatpak w/ settings tweaked on flatseal. It's not perfect, but better than nothing.
- staticassertion 5y agoI 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.
- the8472 5y agoLandlock 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.
- staticassertion 5y agoNot sure what you mean. Why would you not want inheritance to be mandatory?
- the8472 5y agoIf 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. [0] https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2
- staticassertion 5y agoBut 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.
- the8472 5y ago> 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.
- danShumway 5y agoAlso consider Bubblewrap, which is what Flatpak uses under the hood. There are a couple of meaningful differences which may or may not be important to you: https://github.com/containers/bubblewrap#related-project-comparison-firejail https://github.com/containers/bubblewrap#related-project-com... 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/Firejail, https://wiki.archlinux.org/title/bubblewrap 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.
- asicsp 5y agoPrevious discussion: https://news.ycombinator.com/item?id=25052341 https://news.ycombinator.com/item?id=25052341 (214 points | Nov 10, 2020 | 48 comments)
- bigyellow 5y ago[dead]
- jchw 5y agoI’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.
- deleted 5y ago[deleted]
- mwcampbell 5y agoI 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?
- WhyNotHugo 5y agoFor 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).
- egberts1 5y agoBetter off using ipfilter or nftable namespace filtering.