5 ms·

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 SU

• loo 5y ago
  An SUID binary written in C, no less.
• neatze 5y ago
  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.
• the8472 5y ago
  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.
  • 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 ago
      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.
      • throwaway82652 5y ago
        I 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 ago
    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 5y ago
      Yes, but firejail integrates them, docker does not.
      • throwaway82652 5y ago
        Good point, that's very helpful to know.
• Hello71 5y ago
  firejail 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 ago
    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 5y ago
      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.)
      • tome 5y ago
        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 5y ago
          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 5y ago
  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= https://github.com/containers/bubblewrap#user-namespaces=
  • throwaway82652 5y ago
    I 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 ago
    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.
• 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.