From: Ralf Jung Date: Sat, 9 Mar 2019 21:44:33 +0000 (+0100) Subject: add firejail post X-Git-Url: https://git.ralfj.de/web.git/commitdiff_plain/8450dcc0578ee8f2187d05645d93066866d41310 add firejail post --- diff --git a/personal/_posts/2019-03-09-firejail.md b/personal/_posts/2019-03-09-firejail.md new file mode 100644 index 0000000..6f16557 --- /dev/null +++ b/personal/_posts/2019-03-09-firejail.md @@ -0,0 +1,91 @@ +--- +title: "Sandboxing All The Things with Firejail" +categories: sysadmin +--- + +Sometimes, I run software that I trust less. +All software I use on a daily basis is open-source, but there is still closed-source software I run occasionally, like video games. +Unfortunately, the usual Unix security model does not protect against such software misbehaving, as illustrated by [this XKCD](https://www.xkcd.com/1200/). +There is no good reason that these applications should have access to all my personal information and secret keys that I have stored on my system, but without proper application isolation (like we are used to on mobile devices nowadays) nothing stops them from leaking all this data. +I didn't want to wait until such technology becomes the default on Linux desktops, so I did some research for ways to sandbox existing applications and ended up with [Firejail](https://github.com/netblue30/firejail). + + + +Firejail is packaged for Debian and other distributions, so you should be able to install it with your distribution's package manager. +It runs an application in a sandbox, the details of which are configured in a *profile*. +Firejail comes with profiles for many applications. +For example, `firejail firefox` will start Firefox inside the sandbox. +This adds an extra layer of security around Firefox' security mechanisms. + +However, I have found that my setup is sufficiently non-standard that I often have to customize the profiles. +The most complex piece of the profile is to configure which parts of the file system the application will be able to access. +Unfortunately, the configuration language can be quite hard to use---it is often difficult to find out why access to a particular file does not work. +Also, the whitelisting mechanism is fairly inflexible: you cannot control which directory gets whitelisted; instead, when you whitelist something in `/home/user/foo`, whitelisting gets turned on for all of `/home` (and similar for a bunch of other hard-coded "whitelisting roots"). +But with some experimentation, you'll get things to work eventually. + +For example, if there are extra directories that no sandboxed application should be able to access, you can add them in `/etc/firejail/disable-common.local`. +I am blacklisting all my personal files: +``` +# Personal files +blacklist ${HOME}/Documents +``` +This will affect all sandboxes, because `disable-common.inc` is included pretty much everywhere, and that includes `disable-common.local`. + +## Custom Profiles + +Firejail cannot come with profiles for all applications, so sometimes you have to write your own. +For example, I use one profile for all video games as well as TeamSpeak, which is based on the profile for Steam and looks like this (I store it in `/etc/firejail/gaming.profile`): +``` +# Steam profile (applies to games/apps launched from Steam as well) +noblacklist ${HOME}/.steam +noblacklist ${HOME}/.steampath +noblacklist ${HOME}/.steampid +noblacklist ${HOME}/.local/share/steam +noblacklist ${HOME}/.wine +noblacklist ${HOME}/.ts3client +include /etc/firejail/disable-common.inc +include /etc/firejail/disable-programs.inc +include /etc/firejail/disable-passwdmgr.inc + +caps.drop all +netfilter +nonewprivs +noroot +protocol unix,inet,inet6,netlink +# wine/games don't work properly with seccomp +#seccomp + +# give access to some directories +read-write ${HOME}/.cache/winetricks +read-write ${HOME}/.ts3client +read-write ${HOME}/.steam +read-write ${HOME}/bin/teamspeak3 +whitelist /mnt/store/r/games +# -> implicitly, the rest of /mnt is blocked +``` +Obviously, you will have to adjust the paths. +If one particular application needs something that got globally blacklisted, you can use `noblacklist`. +However, you might also have to `whitelist` it if something else sets up a whitelist for this directory. +Also, there seems to be no way to have something on the `blacklist` globally but then make it `read-only` for a particular sandbox only. +(This is what I mean by the configuration language being hard to use.) + +Next, it is a good idea to test the profile. +You can start a shell inside the sandbox with: +``` +firejail --profile=/etc/firejail/gaming.profile bash +``` +Now you can do things like `ls ~/.ssh` to make sure your secret keys are not accessible in the sandbox. +Also test accessing the directories where the games are stored. +Use `exit` to leave the sandbox. + +I have created a file `~/bin/gamejail` to conveniently start an application inside the sandbox: +``` +#!/bin/bash +exec firejail --profile=/etc/firejail/gaming.profile "$@" +``` +Now you just have to wrap the call to run the application inside `gamejail`, for example `gamejail steam`. + +That's all I got. +I hope this little tutorial helps you to make your system a bit more secure by restricting application privileges. +Firejail is far from perfect, but it works quite well and it is extremely customizable. +In case you have trouble configuring the sandbox properly, I have found it very helpful to look at all the examples that are shipped in `/etc/firejail`.