Why on earth should I use Firejail?
Some existing Linux security solutions are easily defeated from internal and/or external threats. Other solutions are just too difficult to put in place. Firejail’s approach is radically different.
For us, the user always comes first. We manage to keep the learning curve down. Actually, most of the time you don’t need to learn anything, just prefix your application with “firejail” and run it. This makes Firejail ideal for the regular, not-so-skilled home user.
We use the latest Linux kernel security features, such as namespaces and seccomp-bpf. In our view these features are mature, and have been extensively tested in the market place by products such as Google Chrome or Docker.
How does it compare with Docker, LXC, nspawn?
Docker, LXC and nspawn are container managers. A container is a separate root filesystem. The software runs in this new filesystem. Firejail is a security sandbox. It works on your existing filesystem. It is modeled after the security sandbox distributed with Google Chrome.
Containers and sandboxes use the same Linux kernel technology, Linux namespaces. The developer focus is different. Containers target the virtualization market, while sandboxes focus on application security.
What is the overhead of the sandbox?
The sandbox itself is a very small process. The setup is fast, typically several milliseconds. After the application is started, the sandbox process goes to sleep and doesn’t consume any resources. All the security features are implemented inside the kernel, and run at kernel speed.
Firefox doesn’t open in a new sandbox. Instead, it opens a new tab in an existing Firefox instance
By default, Firefox browser uses a single process to handle multiple windows. When you start the browser, if another Firefox process is already running, the existing process opens a new tab or a new window. Make sure Firefox is not already running when you start it in Firejail sandbox.
How do I run two instances of Firefox?
Start the first Firefox instance as usual:
$ firejail firefox
Then, start the second sandbox:
$ firejail --private firefox -no-remote
How do I run VLC in a sandbox without network access?
–net=none command line switch installs a new TCP/IP stack in your sandbox. The stack is not connected to any external interface. For the programs running inside, the sandbox looks like a computer without any Ethernet interface.
$ firejail --net=none vlc
The best way to handle the command line switch is to place it in a custom profile in ~/.config/firejail file in your home directory. Create a vlc.profile text file in this directory, with the following content:
$ cat ~/.config/firejail/vlc.profile include /etc/firejail/vlc.profile net none
I’ve noticed the title bar in Firefox shows “(as superuser)”, is this normal?
The sandbox process itself runs as root. The application inside the sandbox runs as a regular user. “ps aux | grep firefox” reports Firefox process running as a regular user.
The same problem was seen on other programs as well (VLC, Audacious, Transmission), and it is believed to be a bug in the window manager. You can find a very long discussion on the development site: https://github.com/netblue30/firejail/issues/258
Can you sandbox Steam games and Skype?
Support for Steam, Wine and Skype has been around since version 0.9.34. Quite a number of other closed-source programs are supported.
Running ls /etc/firejail/*.profile will list all the security profiles distributed with Firejail. Programs not listed there, are handled by a very restrictive /etc/firejail/default.profile.
How do I simulate the installation of a program using Firejail?
This is an example of installing OpenShot video editor in a Firejail sandbox:
In a terminal I start a overlayfs sandbox (a kernel 3.18 kernel or better is needed):
$ firejail --name=test --overlay --private --noblacklist=/sbin --noblacklist=/usr/sbin
In a different terminal, I join the sandbox as root and install the program – I am using apt-get on Debian:
$ sudo firejail --join=test Switching to pid 2464, the first child process inside the sandbox changing root to /proc/2464/root Child process initialized in 6.05 ms # apt-get install openshot # exit
Back in the first terminal I run the new program:
Once the sandbox is closed, overlayfs is unmounted and openshot disappears.
What are the implications of missing user namespace feature in Arch Linux kernel?
Q: There is a debate going on in the Arch Linux community as to start enabling CONFIG_USER_NS for default kernels. Currently this setting is explicitly not applied to arch repo’s kernels (https://bugs.archlinux.org/task/36969). What are the implications when running firejail on a kernel that doesn’t have user namespaces, if any?
A: There are two different technologies you can use today to setup a sandbox: SUID and user namespaces. Quite funny, both of them are terribly insecure. User namespace has the advantage when things go wrong you can blame it on kernel people. For Firejail we use SUID, at least this one we can fix ourselves.
However, we do use user namespace for a different purpose: to prevent the user from becoming root. But for this purpose we also have seccomp and capabilities. These three technologies overlap quite well, in a real world scenario it is difficult to tell which one will trigger first. You need at least one to do the job.
If Arch developers keep user namespace disabled, the impact on Firejail user will be negligible.