[HN Gopher] Firejail: Light, featureful and zero-dependency secu...
___________________________________________________________________
Firejail: Light, featureful and zero-dependency security sandbox
for Linux
Author : nateb2022
Score : 118 points
Date : 2023-07-11 14:55 UTC (8 hours ago)
(HTM) web link (firejail.wordpress.com)
(TXT) w3m dump (firejail.wordpress.com)
| mrl5 wrote:
| There is also https://github.com/google/nsjail
| jpeeler wrote:
| While trying to find out more comparison information, found
| this light on details issue:
|
| https://github.com/containers/bubblewrap/issues/81
|
| It mentions nsjail and minijail.
| aborsy wrote:
| I don't hear good comments on the quality of firejail sandbox,
| compared to flatpak or snap.
| [deleted]
| nateb2022 wrote:
| Firejail, Flatpak (which uses Bubblewrap under the hood), and
| Snap (which uses AppArmor) all use the same underlying
| technology: Linux namespaces.
|
| For those wondering about their differences, Firejail provides
| a helpful overview here:
| https://github.com/netblue30/firejail/wiki/Frequently-Asked-...
|
| TL;DR: Firejail has much more comprehensive features than
| Flatpak (Bubblewrap). Firejail also has more comprehensive
| network support, support for AppArmor and SELinux, and easier
| seccomp filtering.
|
| Compared to Snap (which uses AppArmor), Firejail is not only
| compatible with AppArmor but again goes above and beyond with a
| lot of additional features.
| kd913 wrote:
| It isn't just linux namespaces, you have mounted namespaces,
| cgroups, seccomp filters etc...
|
| From what I remember it certainly isn't as simple as you
| present it and additional features tends to involve
| additional surface area.
|
| Other aspects in the past was that Firejail's approach to
| capabilities and namespaces enabled it to act as a setuid
| binary to gaining root privileges on the host.
|
| Snaps I seem to recall had defined mounted namespaces that
| didn't need this privilege escalation. Their apparmor
| profiles are well defined and tunable via the connections
| mechanism. Although I seem to recall that too having some
| CVEs present.
|
| In terms of trust though, I rather do trust snaps a lot more
| than firejail even if the latter is more tunable. I see that
| latter aspect as a downside, relative to snaps which already
| come confined and tuned.
|
| There is also systemd itself which can be used in a similar
| way, and also has quite a nice tool for checking the exposure
| of a given sandbox.
| weinzierl wrote:
| If namespaces are not enough isolation for you then there is
| always Firecracker.
| duped wrote:
| I'm immediately skeeved out by any SUID root executable claiming
| to be secure. Surely there's a way to do this without root perms?
| 5e92cb50239222b wrote:
| bubblewrap does this and has been used by flatpak for years.
| firejail has a lot more features though (which is questionable
| for a security-critical application, sure), like setting up
| separate iptables rules, which you would have to do manually
| with bubblewrap.
| rkeene2 wrote:
| If you want something different, but aren't as concerned about
| performance you can use User-Mode Linux to do this, which I
| used to use to isolate package building as well as working
| around bugs in BtrFS. I have a simple script here [0] (though
| it relies on some setup here [1]). Although I haven't looked
| back at it for a bit (2016).
|
| [0] https://rkeene.org/viewer/tmp/fakeroot.sh.htm
|
| [1] https://rkeene.org/viewer/tmp/fakeroot.Makefile.htm
| smallerfish wrote:
| Last time I tried this, the overlayfs was disabled in response to
| a CVE. Once that's re-enabled, I do think this could be a useful
| tool with some better wrappers; running every application in its
| own firejail (assuming easy to set up) would be pretty sweet.
|
| https://github.com/netblue30/firejail/commit/97d8a03cad19501...
| bombolo wrote:
| It's quite easy to set up, they have pre-made configurations
| you can start from, and sandbox an application is just to
| create a symlink.
| smallerfish wrote:
| Agree, though I think it can be far simpler. The UI that they
| recommend is kind of janky, and 50% of users won't want to
| wade through configuration files. For example, I could
| imagine a UI that shows you all of your .Desktop files, and
| lets you drag anything you like into a "jailed" zone in the
| UI, then gives you basic options. Right click on any of the
| jailed icons for further configuration.
| lgas wrote:
| Aren't "light" and "featureful" opposites?
| znpy wrote:
| No. Vim is light, but very featureful, for example.
| anotherhue wrote:
| I guess they don't weigh invoked kernel features.
|
| Reasonable tbh.
| nateb2022 wrote:
| The sandbox itself is a very small process. The setup is fast,
| typically several milliseconds. After an application is
| started, the sandbox process goes to sleep and doesn't consume
| any resources. All of the security features invoked are
| implemented inside the kernel, and run at kernel speed with
| minimal overhead.
| tedunangst wrote:
| The notion that features must be heavy is the scourge of modern
| software.
| asmor wrote:
| Isn't this the SUID binary that trusted the USER env variable for
| instant privilege escalation? As the kind of person who likes
| replacing sudo with doas, this is not something I'd install.
|
| https://cve.circl.lu/cve/CVE-2016-10122
| anderspitman wrote:
| Sandboxing capabilities of operating systems is surprisingly bad.
| It's very strange to me that there isn't an idiot-proof user-
| space function call for "start a subprocess, limited to these
| files/directories, this port, this much drive space, this much
| CPU, and this much memory".
|
| Of course you can do all these things (on Linux at least), but it
| involves a dizzying array of technologies.
| jchw wrote:
| This is what happens when you bolt new security models onto a
| massive heap of millions of lines of code.
|
| When I started using Linux, the security model had features
| like root being allowed to pwn the kernel and just about
| anything else. Now /dev/mem is gone, lockdown exists,
| namespaces exist, there are many more capabilities than there
| used to be, seccomp and seccomp-bpf exist, etc.
|
| A lot of security ideas on Linux also rely on trusting the
| software, a model that may very well make sense in the context
| of Linux distributions with repositories of open source
| software. In this case, software itself opts into sandboxing to
| harden itself. This is pretty much what goes on with stuff like
| Flatpak. This also sounds like the idea with Pledge.
|
| Can we do better? Maybe. I think adding true, practical
| sandboxing onto existing kernels not designed with this in mind
| is possible with tradeoffs. gVisor is an interesting approach:
| it's not a panacea but certainly a step in the right direction,
| using a usermode kernel that is itself separated into modules
| that are heavily locked down using ordinary Linux security
| mechanisms. This adds an additional layer to the moat that in
| theory is quite strong.
|
| Another approach is virtual machines. And yes, this approach
| has some reasonable critique: typical VMMs and virtual machine
| software are very complex and involve needing to trust that the
| hardware was implemented correctly that the design isn't
| flawed, something that some people never trusted and others
| have lost some faith in with many hardware flaws and Qemu bugs
| coming to light. However, I still think lightweight virtual
| machines ought not be ignored entirely. Improvements have been
| made over time that make the idea of using virtual machines for
| this purpose a bit more within reason. For example, Firecracker
| and Ignite are pretty interesting tools for running software in
| a more sandboxed manner. And, even with virtual machines
| potentially having flaws, a lot of the time it may at least
| require root privileges or more to actually exploit some flaws,
| which makes this not entirely useless from a defense-in-depth
| standpoint.
|
| But you just want an idiot proof way to call some binary and
| provide some limits, and have it be guaranteed to actually
| enforce those limits as a proper security boundary. Do we have
| it?... No. Will it be simple, something that can be done with
| some simple syscalls? Probably not. Could it be done with an
| unfortunately necessarily complicated piece of code? Probably
| yeah. I'd love to see a tool that can give you basically
| seamless sandboxing with simple options and backends for
| different sandboxing approaches like using VMMs or gVisor.
| Provide easy ways to run X11 or Wayland apps and automatically
| give you a sandboxed Xephyr instance or something to provide
| some sandboxing for Xorg apps. Will it happen? Dunno.
|
| As for me, I'd really like a way to create a namespace where
| only some hosts on the network are accessible. It's possible to
| do today using various technologies, but it'd be a lot easier
| using something like the gVisor model with a usermode
| networking stack, I think. Maybe some day.
| duped wrote:
| That's because it tends to break every program that wasn't
| built to run in a sandbox. There are (bad, ultimately) reasons
| why sandboxing is _hard_ unless the ecosystem and toolchains
| have been built from the ground up to run a program in a
| sandbox.
|
| For example, any dynamically linked program that needs to spawn
| a subprocess using a command that it doesn't ship alongside
| itself is going to cause problems in your sandbox. That turns
| out to be the vast majority of programs that have been shipped
| in the FHS universe for the last few decades. It's only
| recently that sandboxing has come into vogue.
|
| And the OS's that do a good job (like MacOS) get a bad rap from
| both developers and users who are mad their programs can't do
| what they want them to do because they don't have unfettered
| access to the filesystem any more.
| efdee wrote:
| But we can just not sandbox the programs that break inside a
| sandbox. We don't lose anything we currently have. Meanwhile,
| more and more programs will start supporting running in a
| sandbox.
| 5e92cb50239222b wrote:
| I think OpenBSD comes the closest to what you want with its two
| easy to use syscalls that provide syscall filtering and
| restricting access to paths:
|
| https://man.openbsd.org/pledge.2
|
| https://man.openbsd.org/unveil.2
|
| A few random examples:
|
| https://github.com/tmux/tmux/blob/c8494dff7b6b9a996866edaf8c...
|
| https://github.com/openbsd/ports/blob/master/www/mozilla-fir...
|
| https://github.com/openbsd/ports/blob/master/www/mozilla-fir...
|
| To get the best isolation you need to patch the source -- the
| application needs to go through initial setup and then drop
| privileges to the absolute possible minimum. But it's easy to
| make custom wrappers for third-party applications -- the above
| profiles taken from the OpenBSD ports tree are the proof.
| polyrand wrote:
| You can now use those on Linux too:
|
| https://justine.lol/pledge/
| IshKebab wrote:
| Capability based OS like Fuchsia do that by default. Actually
| I'm not sure about memory or CPUs but for other stuff you can't
| access it unless the parent process explicitly grants you
| access.
| progval wrote:
| You can do all these but the disk quota with systemd. If you
| don't want to define a unit file, you can use the CLI:
| sudo systemd-nspawn \ --directory=/ \
| --volatile=yes \ --bind=/home/tmp:/home/tmp \
| --private-network \ --port=tcp:80:8000 \
| --property=CPUQuota=5% \ --property=MemoryMax=1G \
| -- \ bash -c 'yes > /dev/null'
| boring_twenties wrote:
| From systemd-nspawn man page:
|
| Like all other systemd-nspawn features, this is not a
| security feature and provides protection against accidental
| destructive operations only.
| progval wrote:
| Isn't it a general warning about the kernel's isolation
| features?
| anderspitman wrote:
| Yes but sudo. You shouldn't have to escalate privileges to
| decrease privileges. Docker has the same problem. This has
| improved somewhat with user namespaces but it's still
| comicated and requires root to set up.
| jchw wrote:
| See also Bubblewrap[1]. I use Bubblewrap all the time, because
| it's just useful, and a bit easier than doing things with unshare
| directly.
|
| To compare and contrast: bubblewrap is lower level, and is great
| for embedding or using in one-off invocations, whereas firejail
| is more oriented towards adding a bit of hardening to everyday
| applications like Firefox via built-in and custom profiles.
|
| For example, you could temporarily override a path doing
| something like this: bwrap --bind / / --bind
| /tmp/myoverride /usr/lib/qt5.15.2/plugins/kf5 -- ...
|
| to, say, override the KDE plugins while testing. This is useful
| for me since it's rather challenging during development to
| actually get KDE apps to reliably load my plugins on NixOS: I
| think kio slaves are probably wrapped and getting other
| environments injected into them. Rather than bother with any
| tricky hacks, Linux namespaces make it relatively easy to test
| regardless.
|
| Bubblewrap is used internally by Flatpak and others.
|
| https://github.com/containers/bubblewrap
| 5e92cb50239222b wrote:
| I've been using it to wrap nodejs package managers in response
| to all malware shipped through them over the past few years. A
| simple wrapper script like this works fine (symlinked to
| `npm`/`yarn`/`pnpm` into whatever directory is the first in
| $PATH): bin=$(basename "$0") exec
| bwrap \ --bind "$PWD" "$PWD" \ --dev /dev \
| --die-with-parent \ --dir /tmp \ --dir /var \
| --disable-userns \ --new-session \ --proc /proc
| \ --ro-bind /etc/ca-certificates /etc/ca-certificates \
| --ro-bind /etc/resolv.conf /etc/resolv.conf \ --ro-bind
| /etc/ssl /etc/ssl \ --ro-bind /usr /usr \
| --setenv PATH /usr/bin \ --share-net \
| --symlink /tmp /var/tmp \ --symlink /usr/bin /bin \
| --symlink /usr/lib /lib \ --symlink /usr/lib64 /lib64 \
| --unshare-all \ --unshare-user \
| "/usr/bin/$bin" "$@"
|
| It gets read-write access to the current path, and to its own
| copy of ~/.cache and ~/.local/share. It doesn't see anything
| else from your home directory, including any adjacent projects.
| It can easily be locked down further by allowing read-only
| access to the project, and read-write access to node_modules
| and nothing else.
| agucova wrote:
| I'm confused, how would this prevent supply chain attacks?
| Wouldn't you need to sandbox node itself, instead of npm?
| lapinot wrote:
| It does not, supply chain attack is not that afaik. This is
| to defend against npm executing arbitrary nefarious code as
| your user on install of a compromised package.
|
| Also sandoxing npm really means sandboxing node running npm
| (which is js).
| jchw wrote:
| My understanding: It's sandboxing to protect against
| exploits delivered _via_ supply chain attacks, which often
| use low hanging fruit like hooks on install to steal tokens
| /etc. It's definitely not perfect, but it does not hurt
| either.
| nateb2022 wrote:
| The Arch wiki also contains some helpful information regarding
| basic setup and usage: https://wiki.archlinux.org/title/firejail
| k3vinw wrote:
| I've been using this regularly on arch linux and found out the
| hard way that the profile included for Firefox disabled hardware
| acceleration. To get it re-enabled I ended up creating a custom
| profile that extended from the main Firefox profile. Overall I'm
| impressed with the level of granularity. I haven't bothered to
| look more into why that profile had hardware acceleration
| disabled. I guess as a way to protect from crypto mining exploits
| using your gpu.
| __ryan__ wrote:
| Not sure if this was their motivation, but hardware
| acceleration also enables increased opportunity for
| fingerprinting, to my knowledge.
| anotherhue wrote:
| I played with this for an evening and in the end decided that if
| I needed this level of security (assuming browser as the target)
| I was better off running a ChromeOS Flex VM in qemu.
|
| It works very well, boots quickly and is definitely well
| isolated. (Probably maybe)
| anotherhue wrote:
| https://chromeenterprise.google/os/chromeosflex/#form-sectio...
| #!/usr/bin/env bash set -euo pipefail
| args=( -snapshot -name cros
| -nodefaults -machine q35,vmport=off,dump-guest-
| core=off -cpu host -smp 4
| -accel kvm -m 4G -display
| sdl,gl=on,show-cursor=on -device virtio-gpu-gl
| -nic user,model=virtio-net-pci -drive
| format=qcow2,file=/data/cros/cros.qcow2
| -usb -device usb-tablet
| -device intel-hda -device hda-output
| -device intel-iommu -rtc base=utc
| -monitor stdio ) qemu-kvm "${args[@]}"
| jiripospisil wrote:
| Oh, this is a neat technique - no need for those pesky \ at
| the end of each line. Thanks!
___________________________________________________________________
(page generated 2023-07-11 23:01 UTC)