5 ms·

Firejail: Light, featureful and zero-dependency security sandbox for Linux

159 points by nateb2022 3y ago

nateb2022 3y ago
The Arch wiki also contains some helpful information regarding basic setup and usage: https://wiki.archlinux.org/title/firejail https://wiki.archlinux.org/title/firejail
aborsy 3y ago
I don’t hear good comments on the quality of firejail sandbox, compared to flatpak or snap.
- nateb2022 3y ago
  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-Questions#how-does-it-compare-with-docker-lxc-nspawn-bubblewrap 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 3y ago
    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.
    - totallywrong 3y ago
      The snap daemon runs as root, is a resources hog, and really only works well in Ubuntu. Oh and snaps in general suck sooo much, but that's of course just an opinion.
    - ranger_danger 3y ago
      > I rather do trust snaps a lot starting with the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. You’ve as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it installs itself without asking you.
      - kd913 3y ago
        I have pinned them, I have patched them, I have written versions of them including Thunderbird and Firefox along with my own theming ones. I know the reasons why canonical only keeps one store and it seems rather sane to me. Especially after hearing about the mess with PPAs. I can run within their environment and unpack their squashfs. The snap runtime is very plain in GitHub. Please stop sharing FUD.
  - weinzierl 3y ago
    If namespaces are not enough isolation for you then there is always Firecracker.
  - XorNot 3y ago
    Urgh...that list of security features gives me a headache though. That's the problem with all these systems: Linux keeps growing more. Some of them overlap, some don't. "Best practice" tends to be "use all of them" but what's "all"? We've got a real problem that the scope of things which have to be controlled keeps growing, and the ways to do that keep increasing as well. And perhaps worse: there's precious little documentation of the implications of turning some of these features off. But that's far and away the most common thing you need to do because usually you have something that's broken, unless you disable a "security" feature.
- deleted 3y ago
  [deleted]
lgas 3y ago
Aren't "light" and "featureful" opposites?
- anotherhue 3y ago
  I guess they don't weigh invoked kernel features. Reasonable tbh.
- nateb2022 3y ago
  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 3y ago
  The notion that features must be heavy is the scourge of modern software.
- znpy 3y ago
  No. Vim is light, but very featureful, for example.
anotherhue 3y ago
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 3y ago
  https://chromeenterprise.google/os/chromeosflex/#form-section 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[@]}"
  - frankjr 3y ago
    Oh, this is a neat technique - no need for those pesky \ at the end of each line. Thanks!
mrl5 3y ago
There is also https://github.com/google/nsjail https://github.com/google/nsjail
- jpeeler 3y ago
  While trying to find out more comparison information, found this light on details issue: https://github.com/containers/bubblewrap/issues/81 https://github.com/containers/bubblewrap/issues/81 It mentions nsjail and minijail.
smallerfish 3y ago
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/97d8a03cad19501f017587cc4e47d8418273834b https://github.com/netblue30/firejail/commit/97d8a03cad19501...
- bombolo 3y ago
  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 3y ago
    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.
jchw 3y ago
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 https://github.com/containers/bubblewrap
- 5e92cb50239222b 3y ago
  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 3y ago
    I'm confused, how would this prevent supply chain attacks? Wouldn't you need to sandbox node itself, instead of npm?
apitman 3y ago
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.
- IshKebab 3y ago
  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 3y ago
  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 3y ago
    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 3y ago
      Isn't it a general warning about the kernel's isolation features?
  - apitman 3y ago
    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.
k3vinw 3y ago
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__ 3y ago
  Not sure if this was their motivation, but hardware acceleration also enables increased opportunity for fingerprinting, to my knowledge.
_cenw 3y ago
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 https://cve.circl.lu/cve/CVE-2016-10122
duped 3y ago
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 3y ago
  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 3y ago
  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 https://rkeene.org/viewer/tmp/fakeroot.sh.htm [1] https://rkeene.org/viewer/tmp/fakeroot.Makefile.htm https://rkeene.org/viewer/tmp/fakeroot.Makefile.htm
- yjftsjthsd-h 3y ago
  Yes, buuut the way to do it without root is user namespaces, which have a history of causing their own security problems because the kernel historically assumed that the root user wasn't a threat and only root could access certain interfaces that just got exposed to any user who wanted them. It's getting better with time, thankfully.
schmichael 3y ago
A setuid program written in C? Sure enough a full root exploit in 2022. We’ve got to make it easier to drop privileges on Linux without raising them first.
exabrial 3y ago
See also: systemd, because it's already installed https://www.redhat.com/sysadmin/mastering-systemd https://www.redhat.com/sysadmin/mastering-systemd https://gist.github.com/ageis/f5595e59b1cddb1513d1b425a323db04 https://gist.github.com/ageis/f5595e59b1cddb1513d1b425a323db... Force a chroot, mount directories and devices as ro/rw, private tmp, set limits, many other things We dropped docker and life is much better/faster
29athrowaway 3y ago
You may be already using something like AppArmor provided by your distro without being aware of it.
mock-possum 3y ago
There is something very cute about the name ‘firejail’

159 points by nateb2022 3y ago

nateb2022 3y ago

The Arch wiki also contains some helpful information regarding basic setup and usage: https://wiki.archlinux.org/title/firejail https://wiki.archlinux.org/title/firejail

aborsy 3y ago

I don’t hear good comments on the quality of firejail sandbox, compared to flatpak or snap.

nateb2022 3y ago
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-Questions#how-does-it-compare-with-docker-lxc-nspawn-bubblewrap 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 3y ago
  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.
  - totallywrong 3y ago
    The snap daemon runs as root, is a resources hog, and really only works well in Ubuntu. Oh and snaps in general suck sooo much, but that's of course just an opinion.
  - ranger_danger 3y ago
    > I rather do trust snaps a lot starting with the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. You’ve as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it installs itself without asking you.
    - kd913 3y ago
      I have pinned them, I have patched them, I have written versions of them including Thunderbird and Firefox along with my own theming ones. I know the reasons why canonical only keeps one store and it seems rather sane to me. Especially after hearing about the mess with PPAs. I can run within their environment and unpack their squashfs. The snap runtime is very plain in GitHub. Please stop sharing FUD.
- weinzierl 3y ago
  If namespaces are not enough isolation for you then there is always Firecracker.
- XorNot 3y ago
  Urgh...that list of security features gives me a headache though. That's the problem with all these systems: Linux keeps growing more. Some of them overlap, some don't. "Best practice" tends to be "use all of them" but what's "all"? We've got a real problem that the scope of things which have to be controlled keeps growing, and the ways to do that keep increasing as well. And perhaps worse: there's precious little documentation of the implications of turning some of these features off. But that's far and away the most common thing you need to do because usually you have something that's broken, unless you disable a "security" feature.
deleted 3y ago
[deleted]

lgas 3y ago

Aren't "light" and "featureful" opposites?

anotherhue 3y ago
I guess they don't weigh invoked kernel features. Reasonable tbh.
nateb2022 3y ago
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 3y ago
The notion that features must be heavy is the scourge of modern software.
znpy 3y ago
No. Vim is light, but very featureful, for example.

anotherhue 3y ago

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 3y ago
https://chromeenterprise.google/os/chromeosflex/#form-section 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[@]}"
- frankjr 3y ago
  Oh, this is a neat technique - no need for those pesky \ at the end of each line. Thanks!

mrl5 3y ago

There is also https://github.com/google/nsjail https://github.com/google/nsjail

jpeeler 3y ago
While trying to find out more comparison information, found this light on details issue: https://github.com/containers/bubblewrap/issues/81 https://github.com/containers/bubblewrap/issues/81 It mentions nsjail and minijail.

smallerfish 3y ago

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/97d8a03cad19501f017587cc4e47d8418273834b https://github.com/netblue30/firejail/commit/97d8a03cad19501...

bombolo 3y ago
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 3y ago
  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.

jchw 3y ago

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 https://github.com/containers/bubblewrap

5e92cb50239222b 3y ago
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 3y ago
  I'm confused, how would this prevent supply chain attacks? Wouldn't you need to sandbox node itself, instead of npm?

apitman 3y ago

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.

IshKebab 3y ago
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 3y ago
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 3y ago
  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 3y ago
    Isn't it a general warning about the kernel's isolation features?
- apitman 3y ago
  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.

k3vinw 3y ago

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__ 3y ago
Not sure if this was their motivation, but hardware acceleration also enables increased opportunity for fingerprinting, to my knowledge.

_cenw 3y ago

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 https://cve.circl.lu/cve/CVE-2016-10122

duped 3y ago

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 3y ago
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 3y ago
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 https://rkeene.org/viewer/tmp/fakeroot.sh.htm [1] https://rkeene.org/viewer/tmp/fakeroot.Makefile.htm https://rkeene.org/viewer/tmp/fakeroot.Makefile.htm
yjftsjthsd-h 3y ago
Yes, buuut the way to do it without root is user namespaces, which have a history of causing their own security problems because the kernel historically assumed that the root user wasn't a threat and only root could access certain interfaces that just got exposed to any user who wanted them. It's getting better with time, thankfully.

schmichael 3y ago

A setuid program written in C? Sure enough a full root exploit in 2022. We’ve got to make it easier to drop privileges on Linux without raising them first.

exabrial 3y ago

See also: systemd, because it's already installed https://www.redhat.com/sysadmin/mastering-systemd https://www.redhat.com/sysadmin/mastering-systemd https://gist.github.com/ageis/f5595e59b1cddb1513d1b425a323db04 https://gist.github.com/ageis/f5595e59b1cddb1513d1b425a323db... Force a chroot, mount directories and devices as ro/rw, private tmp, set limits, many other things We dropped docker and life is much better/faster

29athrowaway 3y ago

You may be already using something like AppArmor provided by your distro without being aware of it.

mock-possum 3y ago

There is something very cute about the name ‘firejail’