[HN Gopher] Firejail: Linux namespaces and seccomp-bpf sandbox
___________________________________________________________________
Firejail: Linux namespaces and seccomp-bpf sandbox
Author : varbhat
Score : 123 points
Date : 2022-03-27 14:11 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| throwaway82652 wrote:
| 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.
| goodpoint wrote:
| > 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
| Hello71 wrote:
| 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.
| tome wrote:
| 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.
| tedunangst wrote:
| 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.)
| goodpoint wrote:
| This is the case for most desktop users. All the valuable
| data is in the user account.
|
| If the user account is compromised all valuable data
| (password, keys) is gone.
|
| Gaining root is hardly useful to an attacker.
| johnisgood wrote:
| Firejail offers private home (i.e. not your actual), and
| disallows running executables within, etc.
| tome wrote:
| 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!
| folmar wrote:
| 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).
| traverseda wrote:
| bwrap 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=
| chlorion wrote:
| 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.
| throwaway82652 wrote:
| I don't know why it says that, it's explicitly not: https://g
| ithub.com/containers/bubblewrap/blob/34a8c8bc870783...
|
| Distros without user namespaces will probably still ship the
| SUID version though.
| loo wrote:
| An SUID binary written in C, no less.
| the8472 wrote:
| 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.
| throwaway82652 wrote:
| I was under the impression the X11 and dbus sandboxing was
| done with Xpra and xdg-dbus-proxy, which are not part of
| firejail.
| the8472 wrote:
| Yes, but firejail integrates them, docker does not.
| throwaway82652 wrote:
| Good point, that's very helpful to know.
| gnoack wrote:
| +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:
| $ 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 wrote:
| > escalating privileges in order to drop privileges is
| counterintuitive
|
| A lot of valid solutions are counterintuitive.
| neatze wrote:
| 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.
| danShumway wrote:
| Also 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-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/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.
| ByThyGrace wrote:
| > 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.
| makeworld wrote:
| Happily using this for Zoom, I don't trust their security.
| staticassertion wrote:
| Why not just use the web app?
| smallerfish wrote:
| The desktop app does better image processing on your camera
| feed. That's about the only reason.
| Shared404 wrote:
| I'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.
| asicsp wrote:
| Previous discussion:
| https://news.ycombinator.com/item?id=25052341 _(214 points | Nov
| 10, 2020 | 48 comments)_
| jchw wrote:
| 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.
| mwcampbell wrote:
| 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?
| egberts1 wrote:
| Better off using ipfilter or nftable namespace filtering.
| bigyellow wrote:
| staticassertion wrote:
| 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.
| gnoack wrote:
| 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.
| staticassertion wrote:
| Honestly, user namespaces might be scarier to me than setuid
| lol hopefully one day that will change.
| the8472 wrote:
| 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.
| staticassertion wrote:
| Not sure what you mean. Why would you not want inheritance to
| be mandatory?
| [deleted]
___________________________________________________________________
(page generated 2022-03-27 23:00 UTC)