linux process sandboxing with linux ‘user namespaces’ and firejail

i’m quite a fan of security-by-isolation, i.e. VMs and/or sandboxing. of course there are still vulnerabilities in the form of security-by-correctness failures (sandbox escapes), but i think they are far less likely to be found and widely exploited

i was initially considering running my internet-facing/vulnerable clients (browser, various messaging clients, etc) in a VM, but this seemed quite heavyweight and inconvenient

qubes would allow comparatively lightweight vms (they share the same resources such as filesystem), but that OS was out of the question because it can’t run some stuff i need it to (e.g. virtualbox VMs on top)

i figured i might not need to isolate an application in its own OS or filesystem, but rather use a sandbox. i came across sandboxie and then went on a hunt for a linux equivalent. i found firejail

it’s been described as ‘chroot on speed’, but it allegedly more secure than chroot. using linux kernel ‘user namespaces’, a container can be set up for a process so that it has its own private view of the filesystem, the network, processes, and so on

so for a potentially dangerous program (like suspected malware), one could run it in firejail where it has no internet access and no changes are persisted to the filesystem. alternatively, changes can be isolated to a private working space on the filesystem for the process (or process group)

it’s fine-grained control, so you can selectively disable ipv4, ipv6 or named pipes, whitelist or blacklist network interfaces (including localhost) or IP addresses, create a copy of the tcp/ip stack, whitelist or blacklist dirs/files, narrow permissions on the filesystem, hide other accounts entirely (such as root), reconfigure dns, and so on. amazingly you can even whitelist (or blacklist) the system calls that a process can make! amazing! but there are yet more features, such as replacing the process’s X11 server with one that allegedly cannot be screenshotted or keylogged, and whitelisting/blacklisting of ‘capabilities’ (of which there are about 35 in today’s linux kernel), which can be used to constrain superuser activities

firejail is easy to use, you just run ‘firejail <command>’. if it finds or is explicitly pointed-at a pre-baked profile for the <command> then that is leveraged, otherwise it defaults to a boilerplate profile. the default profile is generic.profile file if firejail is run by a regular user, and server.profile if run by root. profiles matching the application’s basename are searched-for first in ~/.config/firejail, then in /etc/firejail.  if you supply any other options to firejail apart from the jailed process name, then they override the respective part(s) of any loaded profile

firejail also logs attempts by the process to access blacklisted resources! and it has this nifty feature that you can symlink any binary to firejail, and firejail will look at the name it was given and then hunt for the real thing on the remainder of the path (so you could make a symlink called ‘firefox’ which pointed at the ‘firejail’ binary, and firejail would see it was actually called with name ‘firefox’, and load the real firefox in a firejail). it’s packed with good features!

firejail is incredibly easy to use. that is great, but i think is also slightly dangerous. for instance typing ‘firejail skype’ will launch the bundled profile at /etc/firejail/skype.profile and it will work fine, but i find the ignorance of what is going on under the covers a bit scary 🙂 also, i can see that profiles often use blacklisting, which i’m wary of because blacklisting is fragile.  of course whitelisting is also fragile, but in a different way 😀

so while initially i will use those pre-build profiles (of which there are many!), my goal, *eventually*, is to learn all about firejail and build my own profiles based purely on whitelisting. in fact the recommended approach for whitelisting is ‘run and profile the process with no permissions, see what breaks, fix the profile and try again’. using this approach i should build up a library of custom profiles and confidence in what firejail is allowing/disallowing, plus a much better idea of what the processes i’m jailing are actually trying to do! when i get a bit more expert then another blog post will materialize

# install firejail
apt-get install firejail

# example invocations (these all have pre-built profiles)
firejail google-chrome-stable
firejail firefox
firejail skype
firejail /opt/Wire/wire <– requires downloading the wire profile and an .inc file from https://github.com/netblue30/firejail/tree/master/etc

# look at the firejailed process tree
firejail –tree

lastly, firejail is itself a setuid program, which is a security risk! so there is definitely a degree of ‘security by correctness’, but hopefully it is small and the program drops its privileges after running a relatively small surface-area of code. all in all, and without being an expert in this area, i’m well impressed with firejail!

INTERESTING NOTE! an exploit for firejail has arrived! it seems to have been possible because the setuid attack surface was too large… http://seclists.org/oss-sec/2017/q1/20 – hopefully this will be addressed soon

# links
https://lwn.net/Articles/531114/ (linux kernel ‘user namespaces’ feature overview)
https://github.com/netblue30/firejail
Documentation
Firejail Seccomp Guide
http://man7.org/linux/man-pages/man7/capabilities.7.html
Firejail Linux Capabilities Guide
https://github.com/chiraag-nataraj/firejail-profiles
man firejail-profile

One thought on “linux process sandboxing with linux ‘user namespaces’ and firejail

Leave a Reply

Your email address will not be published. Required fields are marked *