Firejail 0.9.42 Release Announcement

We are happy to announce the release of Firejail version 0.9.42 (download). Firejail is a generic Linux namespaces security sandbox, capable of running graphic interface programs as well as server programs. We provide software security for Average Joe and Jane’s Humble Distro. If you are a corporate player in the security field, please be aware you are competing with a weekend project. Now let’s cut to the chase and see what’s new:

AppArmor

Firejail works by default on top of AppArmor, for example on Ubuntu and Debian where AppArmor profiles are available for several applications. In this release we bring in support for our own AppArmor profiles. If you run Firejail with –apparmor flag, the sandbox will use a generic AppArmor profile provided by Firejail, instead of the profile provided by your distro.

The feature is disabled by default at compile time. Use –enable-apparmor to enable it, and compile the software:

$ ./configure --prefix=/usr --enable-apparmor
$ make
$ sudo make install

During software install, a generic AppArmor profile file, firejail-default, is placed in /etc/apparmor.d directory. The profile needs to be loaded into the kernel by running the following command:

$ sudo aa-enforce firejail-default

The profile tries to replicate some advanced security features inspired by kernel-based Grsecurity:

• Prevent information leakage in /proc and /sys directories. The resulting filesystem is barely enough for running commands such as “top” and “ps aux”.
• Allow running programs only from well-known system paths, such as /bin, /sbin, /usr/bin etc. Running programs and scripts from user home or other directories writable by the user is not allowed.
• Disable D-Bus. D-Bus has long been a huge security hole, and most programs don’t use it anyway. You should have no problems running Chromium or Firefox.

Example:

$ firejail --apparmor firefox

You can also include apparmor command in a Firejail profile file.

AppImage

AppImage is what you use when you are planning a fundraising campaign for your open-source project. You would start from an older base, such as Debian Jessie or Ubuntu 14.04, and as you find you need newer libraries, you bring them into your package one by one. The result is an ISO autorun image that will work on most distros. Starting with your base, it will cover a few years worth of Ubuntu, Debian and Mint releases, all the way up to the latest Arch and Gentoo.

In this Firejail release we bring in native support for AppImage executables. This is an example:

I download Firefox Developer Edition ISO maintained by Simon Peter, AppImage packaging system author and developer, then I start the sandbox:

$ firejail --appimage --private --net=eth0 --x11 ~/Downloads/Firefox-Dev-48.0a2.en.glibc2.3.3-x86_64.AppImage

I have an empty home directory (–private), a network namespace isolating the ssh server running on my workstation (–net=eth0), and I place everything in a different X11 server (–x11). Seccomp, namespaces and the rest are enabled by default.

Firefox AppImage running in Firejail

You can find more information on our AppImage Support page.

Sandbox auditing

Firejail’s audit feature allows the user to point out gaps in security profiles. The implementation replaces the program to be sandboxed with a test program. By default, we use /usr/lib/firejail/faudit distributed with Firejail. A custom test program can also be supplied by the user. Examples:

$ firejail --audit transmission-gtk
$ firejail --audit=~/sandbox-test transmission-gtk

In the examples above, the sandbox configures transmission-gtk profile and starts the test program. The real program, transmission-gtk, will not be started.

$ firejail --audit transmission-gtk
Reading profile /etc/firejail/transmission-gtk.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Parent pid 23146, child pid 23147
Blacklist violations are logged to syslog


---------------- Firejail Audit: the GOOD, the BAD and the UGLY ----------------
INFO: starting /usr/lib/firejail/faudit.
GOOD: process 5 is running in a PID namespace.
INFO: container/sandbox firejail.

GOOD: seccomp BPF enabled.
checking syscalls: mount... umount2... ptrace... swapon... swapoff... init_module... delete_module... chroot... pivot_root... iopl... ioperm... 

GOOD: all capabilities are disabled.

GOOD: I cannot access files in /home/netblue/.ssh directory.
GOOD: I cannot access files in /home/netblue/.gnupg directory.
GOOD: I cannot access files in /home/netblue/.mozilla directory.
GOOD: I cannot access files in /home/netblue/.config/chromium directory.
GOOD: I cannot access files in /home/netblue/.icedove directory.
GOOD: I cannot access files in /home/netblue/.thunderbird directory.

MAYBE: an SSH server is accessible on localhost. It could be a good idea to create a new network namespace using "--net=none" or "--net=eth0".
GOOD: HTTP server not available on localhost.
GOOD: I cannot connect to netlink socket. Network utilities such as iproute2 will not work in the sandbox.

MAYBE: I can connect to session bus. It could be a good idea to disable it by creating a new network namespace using "--net=none" or "--net=eth0".

INFO: files visible in /dev directory: ptmx, pts, tty, urandom, random, full, null, zero, shm, dri, snd, log, 
GOOD: Access to /dev directory is restricted.

--------------------------------------------------------------------------------

Parent is shutting down, bye...

As test program you can use anything you want, even a simple bash script:

#!/bin/bash
cat ~/.ssh/known_hosts

Snaps and flatpaks

With my shiny new auditing toy all fired up and ready to go, it was time to insert it in snap and flatpak packages and run them. There were some surprises:

• Snap uses seccomp. It is not marketed as such, but later I’ve found a description buried deep in documentation. It has a good generic whitelist filter – actually I like the way they implemented it.
• AppArmor plays a major role in snap strategy. I would say you really need it if you are running snaps on a different Linux distribution.
• The home directory exposes user’s files, but not dot files. All this is done in the AppArmor profile. Your .ssh and .gnupg files are not available inside the sandbox.

For sandboxing snaps we use the same strategy we used for Chromium: we let them fully configure what they have, and we insert Firejail in the security pipeline.

We use a simple snap.profile to whitelist the home directory – only Downloads is visible inside user home. We also add a proper PID namespace and some other miscellaneous items. Example:

$ firejail --profile=/etc/firejail/snap.profile /snap/bin/ubuntu-clock-app.clock

This is how Firetools is reporting the home directory:

User home directory for a snap package.

The story with flatpak is a little bit different.

• Flatpak is more a container engine than a sandbox, and has the same problems as any other container system out there: heavy downloads from untrusted sources. At least under Docker you can build your own container, but here you really have to download it.
• The software has a number of dependencies such as Gnome libraries, systemd, but the most surprising one is PulseAudio – at least for me ALSA refused to work with flatpak.
• On the security side, Flatpak exposes the home directory. You can read and write anything you want in there, including your .ssh and .gnupg files:

Editing files in ~/.ssh directory using the latest LibreOffice flatpak package

Flatpack is still under heavy development, we don’t plan to add flatpak support in Firejail at this time.

New security profiles

Gitter, gThumb, mpv, Franz messenger, LibreOffice, pix, audacity, xz, xzdec, gzip, cpio, less, Atom Beta, Atom, jitsi, eom, uudeview, tar (gtar), unzip, unrar, file, skypeforlinux, strings, inox, Slack, gnome-chess. Gajim IM client, DOSBox

About

For more information please visit the project page.