Security is personal, everybody seems to have a different opinion. It varies from person to person, and from country to country. In Firejail project we don’t use any particular definition, and we don’t follow the mainstream view on cybersecurity. Instead, we let the user go through the feature list and decide for himself if this will help him or not. Here is our feature list.
The core technology behind Firejail is Linux Namespaces, a lightweight form of virtualization. We use it as the first step in isolating the application. Basically, the app gets its own filesystem, network stack, and kernel interface. It is blazing fast, and consumes virtually no additional memory. We just configure it, and the kernel does all the heavy lifting.
On top of the regular file system, the sandbox deploys a very efficient Mandatory Access Control. It allows or restricts application access to the underlying file system on a file by file basis.
- blacklisting – deny access to files and directories. Access attempts are reported to syslog.
- whitelisting – allow only the files and directories specified by the user.
- read-only, read-write, noexec – set file and directory attributes.
- temporary filesystem – mount a temporary filesystem on top of a directory.
- bind – bind-mount a file or directory on top of another file or directory.
- private – bring in copies of files and directories and discard them when the sandbox is closed.
- restricted user home – only the current user home directory is available inside the sandbox. This is also reflected in the structure of /etc/passwd and /etc/group files.
- reduced system information leakage – restrict access to directories such as /boot, /proc, and /sys.
This is an advanced form of access control we deploy in all our sandboxes. It is built using whitelist access control operation.
Let’s say we want to restrict browser access to our home directories. We start by mounting an empty temporary file system on top of /home/user directory, and them bring in Downloads and various configuration directories the browser is using. Then we copy .bashrc and .Xauthority files to get bash shell and X11 working inside the sandbox. We end up with a pristine looking home directory, where all private user files have disappeared. For email clients we also add mail directory, for multimedia players we add Music, Videos and so on.
We deploy virtual directories all over the Linux file system, allowing in our sandbox only the files necessary for the application to function.
The following security filters are currently implemented:
- seccomp-bpf – a simple, yet effective sandboxing technology, seccomp-bpf allows the sandbox to attach a system call filter to a process and all its descendants, thus reducing the attack surface of the kernel.
- protocol – based on seccomp, it filters the first argument of socket system call. Most default profiles allow only UNIX, IPv4 and IPv6 communication protocols.
- noroot user namespace – install a user namespace with only one valid user, the current user.
- Linux capabilities – Linux Capabilities (POSIX 1003.1e) are designed to split up the root privilege into a set of distinct privileges which can be independently enabled or disabled. These are used to restrict what a process running as root can do in the system. Most default profiles disable all capabilities.
- X11 sandboxing support is built around two external X11 server software packages, Xpra and Xephyr.
- D-BUS filtering
- AppArmor and SELinux support
Firejail can attach a new TCP/IP networking stack to the sandbox. The new stack comes with its own routing table, firewall, and set of interfaces. Implemented as a Linux namespace inside the kernel, the stack is totally independent.
These are the networking operations supported by Firejail:
- create new interfaces – create Linux kernel macvlan and bridge devices and move them in the sandbox.
- move existing interfaces inside the sandbox. The interface configuration is preserved. We use this feature to connect sandboxes to specific VLANs.
- assign addresses – Firejail assigns IP addresses automatically using a simple ARP-scan mechanism. The user can also specify IP addresses. Both IPv4 and IPv6 are supported. Assigning addresses using DHCP is also supported.
- hostname support.
- DNS and encrypted DNS support.
- Linux netfilter support – a custom netfilter configuration can be installed in the sandbox. Several filter examples using the regular netfilter/iptables syntax are provided with the sandbox software.
- network locking support – builds and deploys a custom firewall allowing network traffic only to the addresses accessed in the first o one minute of sandbox operation. This feature comes in handy when sandboxing programs that talk only to a small number of IP addresses, such as mail clients, games, Tor browser.
- traffic tracing – a simple traffic monitor for TCP and UDP streams.
- traffic shaping – control the amount of data that flows into and out of sandboxes.
Located in /etc/firejail directory, profile files describe the filesystem container, the security filters and network configuration.
Most default security profiles use a restrictive dual 32-bit/64-bit seccomp-bpf filter, disable all capabilities, and enable a noroot user namespace inside the sandbox. The filesystem denies access to password and encryption keys. Some application classes such as games and web browsers use a virtual home directory, therefore hiding all private user files.
Allocate resources such as CPU time, system memory, and network bandwidth, using Linux Control Groups and Linux rlimits.
Universal packaging formats
Firejail supports AppImage packaging format natively. Simply add –appimage command line option and the package is mounted and run inside the sandbox.
We make available a simple tool, jailcheck, for auditing user sandboxes. Running as root, the program attaches itself to all running sandboxes, and it looks for major security problems with current user’s configuration.
Statistics and monitoring
Firejail provides a large number of options to track all the aspects of sandboxed applications. This includes monitoring CPU/memory/bandwidth usage, tracing system calls, monitoring exec and fork events, and logging accesses to blacklisted files and directories.
Graphical user interface
A GUI application, Firetools, is available as a separate software package.