Hacker News Reader

Comment by throwaway82652 | Hacker News Reader

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.

View on HN

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.

I was under the impression the X11 and dbus sandboxing was done with Xpra and xdg-dbus-proxy, which are not part of firejail.

Yes, but firejail integrates them, docker does not.

Good point, that's very helpful to know.

>You can't spin up a veth network device without a suid executable.

Doesn't this just require CAP_NET_ADMIN?

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.

I hope it's possible to relax that capability in the kernel somehow, that may be a next step for someone working on sandboxing.

+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.)

> escalating privileges in order to drop privileges is counterintuitive

A lot of valid solutions are counterintuitive.

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).

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.

Firejail offers private home (i.e. not your actual), and disallows running executables within, etc.

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.

I found a way out of the filesystem sandbox by accident after like 3 days.

The devs patched it up super quickly, but I'm still a bit skeptical. It's probably still better than nothing...

An SUID binary written in C, no less.

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.

> 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

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=

I don't know why it says that, it's explicitly not: https://github.com/containers/bubblewrap/blob/34a8c8bc870783...

Distros without user namespaces will probably still ship the SUID version though.

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.

Reply on news.ycombinator.com