-
Notifications
You must be signed in to change notification settings - Fork 573
Frequently Asked Questions
- Why on earth should I use Firejail?
- How does it compare with AppArmor?
- How does it compare with Docker, LXC, nspawn, bubblewrap ?
- What is the overhead of the sandbox?
- Can I sandbox a full OS?
- Firefox doesn’t open in a new sandbox.
- How do I run two instances of Firefox?
- How do I run Tor browser?
- How do I run VLC in a sandbox without network access?
- Can you sandbox Steam games and Skype?
- How do I enable plasma browser integration in firefox?
- How do I integrate firecfg into my package manager?
- How can I enable fcitx?
- How do I sandbox applications started via systemd or D-Bus services?
- OverlayFS features disabled for Linux kernel 4.19 and newer
- A program isn't firejailed
- RTNETLINK error using "--net" option
- PulseAudio 7.0/8.0 issue
- Browser mailto and mail programs attachments do not work
- Cannot open hyperlink with web browser using another application
- Firefox 60 problems
- LibreOffice on Ubuntu 18.04
- Cannot install new software while Firejail is running
- Cannot connect to ibus-daemon in a new network namespace
- Cannot kill firejailed program
- Firefox crashing on Netflix, AMDGPU PRO, Nvidia closed source drivers
- I’ve noticed the title bar in Firefox shows “(as superuser)”, is this normal?
- Media issues with firejail 0.9.62 under Arch
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.
Firejail uses private mount namespaces to achieve similar access controls compared to AppArmor and capability restrictions are also similar. In addition to those, Firejail can set up system call filtering with seccomp and restrict networking. Unlike Firejail, AppArmor can restrict mapping of files to memory. AppArmor's available features can vary widely across kernel versions and distros. Firejail also is executing SUID, elevating user's privileges temporarily, e.g. for setting up mounts, which can be an attack vector.
It is recommended to only use AppArmor OR Firejail but not both at the same time for the same app. If you set a tight AppArmor profile already then you may want to stick with that.
In general to use both for a particular app, you will need to modify the pre-packaged app profiles for both AppArmor and Firejail to get them to work together. You need to add more privileges in AppArmor than is needed without Firejail, and you need to use less Firejail features otherwise it would be broken with AppArmor. Many times they will cancel eachother out rather than be complementary. We have multiple reports about broken apps when AppArmor and Firejail are used at the same time.
Keep in mind that AppArmor is mandatory when enabled while Firejail can be easily circumvented (intentionally or not). It should be possible to use Firejail just for seccomp and network control, those can not conflict with prepackaged AppArmor. See #2248 for a discussion on this.
Docker, LXC and nspawn are container managers. A container is a separate root filesystem. The software runs in this new filesystem. Firejail and bubblewrap are security sandboxes. Firejail 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.
(2018-05-28) Docker and Firejail use similar features like namespaces, seccomp, capabilities. This means Firejail is unable to create its own sandbox when run inside docker. See #1956.
The closest alternative to Firejail is bubblewrap. The technologies and capabilities used are roughly the same (Linux namespaces, bind mounts, capabilities, seccomp filters) but the design philosophies are different: simplicity over features. Bubblewrap chooses to provide only a set of basic tools to construct the sandbox, while Firejail has dedicated support for many applications with its application profiles and tailored exceptions in Firejail itself. One example is that bubblewrap always enforces NO_NEW_PRIVS prctl(2). This ensures that child processes cannot acquire new privileges using execve(2) and in particular, this means that calling a set-uid binary (or one with file capabilities) does not result in an increase of privileges. With Firejail this can be chosen, so it's actually possible to weaken security when set-uid functionality is preferred, though this also means that set-uid programs can be sandboxed.
Comparison of Firejail features vs. bubblewrap:
- very detailed and easy to use profiles for hundreds of applications, especially highly important browsers, messaging apps and media players
- automatic profile generation with
firejail --build - automatic desktop integration with
firecfg - more extensive network support including firewalling, protocol filtering, tunneling, DNS
- AppArmor and SELinux support
- D-bus filtering
- AppImage support
- resource limits (
rlimit-*=) - X11 sandboxing
- construct new file systems easily with
private-bin,private-etc,private-libetc. - easy to use flags like
novideo,no3d,nodvd,notv,nogroups,noroot,nou2f,noexecmount flag - easier seccomp filtering (compared to loading cBPF programs) with deny-listing and allow-listing, 32-bit support,
memory-deny-write-execute,protocol
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.
The idea so far was to target specific applications, such as Firefox and Chromium, or closed source apps like Steam and Skype. We are moving in the direction of sandboxing a full OS, but it will take some time to get there.
Run sudo firecfg --clean.
firecfg works by simply creating symlinks in '/usr/local/bin' to the /usr/bin/firejail binary, which will then search for the app's binary (usually in /usr/bin). Because /usr/local/bin/ comes before /usr/bin in $PATH, running <app> (e.g. vlc) will run firejail, so the app will start jailed by default. If you want to start it without a jail, run /usr/bin/vlc.
For programs you never want jailed, create a file ending in .conf under /etc/firejail/firecfg.d containing !foo on separate lines for each program you want excluded, e.g. !vlc.
Note: As of version 0.9.72, This feature has not yet been released.
See also:
- https://github.com/netblue30/firejail/issues/2097
- https://github.com/netblue30/firejail/issues/3665#issuecomment-707689049
- https://github.com/netblue30/firejail/pull/5876
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.
Open about:profiles and create the new profile NAME.
Start the first Firefox instance as usual:
$ firejail firefox
Then, start the second sandbox:
$ firejail firefox -P "NAME" --no-remote
--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 .local file in ~/.config/firejail. Create a vlc.local text file in this directory, with the following content:
$ cat ~/.config/firejail/vlc.local
net none
See also: https://github.com/netblue30/firejail/wiki/Creating-overrides
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. Applications that do not have a profile will use the default profile (/etc/firejail/default.profile).
Create a new file ~/.config/firejail/firefox.local and add ignore nodbus.
If you have private-bin enabled, you must also add private-bin plasma-browser-integration-host.
Arch Linux: https://wiki.archlinux.org/index.php/Firejail#Using_Firejail_by_default
Debian: https://github.com/netblue30/firejail/issues/2226#issuecomment-434249669
Fedora: Install python3-dnf-plugin-post-transaction-actions and create /etc/dnf/plugins/post-transaction-actions.d/firecfg.action with this content:
/usr/bin/*:any:firecfg
/usr/sbin/*:any:firecfg
/usr/share/applications/*:any:firecfg
Depending on the dbus-policy of the profile you need to add different command to its local.
If the dbus-policy is set to filter, it is enough to add dbus-user.talk org.freedesktop.portal.Fcitx.
If it is set to none, you need to add
dbus-user filter
dbus-user.talk org.freedesktop.portal.Fcitx
ignore dbus-user none
By default distributions ship service files to start applications with a full path. This effectively runs those applications non-sandboxed. If you use Firejail it's assumed you'd prefer to run applications sandboxed. Firecfg does its best to help achieve that by creating symlinks that have path-priority, changing .desktop files to point at those, etcetera. But it doesn't support changing these service files. If you want to "fix" this, you'll need to create overrides that force apps to run firejailed. How to proceed depends on the specifics, we'll show you here. Although systemd depends on D-Bus and makes heavy usage of it, both have distinct configurations.
D-Bus
/usr/share/dbus-1/services/*.service and ~/.local/share/dbus-1/services/*.service are used by D-Bus (dbus-daemon or dbus-broker, whichever implementation is installed by your distribution). To "fix" them, you copy from the system directory to the user directory, adjust the Exec line and restart your dbus-daemon/dbus-broker (e.g. systemctl --user restart dbus.service, the dbus.service alias should work for both implementations). This can all be done in the absence of systemd like on runit systems.
systemd --user
/usr/lib/systemd/user/*.service and ~/.config/systemd/user/*.service are used by systemd --user. To "fix" them, you copy from the system directory to the user directory, adjust the Exec line and systemctl --user daemon-reload. The path in /usr/share/dbus-1/services/foo.service does not matter unless it is a Type=DBus service.
Currently the firecfg command doesn't do any of this automatically. For an alternative implementation that supports these features, see firecfg.py.
Something changed in the kernel code, and we are not able to mount / filesystem in overlay. We are working on a fix.
firejail --list does not show the running program to be inside a Firejail sandbox.
First make sure you have run firecfg with sudo. If you run this as root without sudo, it will not fix your .desktop files. If this did not work, create a symlink manually (ln -s /usr/bin/firejail /usr/local/bin/PROGRAM). Additionally, adding an alias in your shell or modifying the Exec line in your .desktop file will work, too. Only edit the .desktop file if you know what you are doing.
If your program is installed under /opt you need to use firejail /opt/foo/bar in the terminal/.desktop file for example.
firejail --net=eth1 firefox yields in RTNETLINK answers: Operation not supported. Missing modules, kernel update without reboot are cause. Look at issue #2046 or #2387.
The srbchannel IPC mechanism, introduced in PulseAudio 6.0, was enabled by default in release 7.0. Many Linux users are reporting sound problems when running applications in Firejail sandbox. It affects among others Ubuntu 16.04 and Mint users. This problem was fixed PulseAudio version 9.0. Run firecfg --fix in a terminal or apply the following configuration to mask the problem:
$ mkdir -p ~/.config/pulse
$ cd ~/.config/pulse
$ cp /etc/pulse/client.conf .
$ echo "enable-shm = no" >> client.conf
A logout/login is required for the changes to take effect.
If you have problems with PulseAudio 9.x use the previous fix, or configure enable-memfd = yes in /etc/pulse/daemon.conf.
Mailto usually uses dbus and is thus disabled by default. Create a local override and add ignore nodbus to the Firefox or Chromium override file as in #2795 and #1718.
Mail programs do not need to interact with the entirety of the filesystem. You may want to allow access to a single directory for attachments and other downloads.
It is recommended to copy-paste links from with application with the hyperlink into an already running web browser. This will always be the safest bet, albeit not very user-friendly. See #2228 and #2047
Firefox 60 doesn’t work with Firejail version 0.9.52 or older. Patched security profiles for are available for Firejail versions 0.9.38.x (LST) and 0.9.52. You can find them in our profile fixes section. Another option is to install a newer version of Firejail.
LibreOffice crashes when sandboxed with Firejail version 0.9.52 in Ubuntu 18.04. A patched security profile for Firejail 0.9.52 is available in our profile fixes section. Another option is to install a newer version of Firejail.
Files blacklisted in a running jail cannot be removed from outside of jail. This causes a serious inconvenience when using Firejail with long time running processes. For example, preventing user from updating system normally, as files like /bin/su, /bin/mount, /usr/bin/sudo are blacklisted by default. Also, admin commands for adding users and groups will fail.
Firejail implements blacklisting by mounting an empty, read-only file or directory on top of the original file. The kernel, at least the older kernels, will refuse to delete the file because it is a mount point in some other place in the system.
The problem is fixed in Linux kernels 3.18 or newer.
ibus-daemon is used to change the system language, for example to switch between English (US) input and Japanese inputs. In a sandbox using a new network namespace ibus-daemon socket is disabled and keyboard switching capability is lost.
Check namespace support like for killall (command option --ns) and adapt the command for firejail --tree output.
You should first set browser-allow-drm to yes in /etc/firejail/firejail.config or add ignore noexec ${HOME} to your firefox.local.
If you are using a firejail version older than 0.9.68 and NVIDIA proprietary drivers, you must also set ignore noroot in your firefox.local.
If this didn't work, try the old solution.
old solution
We are still working on these problems. From what we’ve seen so far, these programs make liberal use of system calls such as chroot and ptrace. These syscalls have no place in regular, well behaved programs, and seccomp kills the application immediately. Workarounds involve disabling seccomp and allowing ptrace utility. Example:
$ firejail --allow-debuggers --ignore=seccomp --ignore=protocol --ignore=noroot --ignore=nogroups --ignore=nonewprivs firefox --no-remote
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
Fix: Add ld.so.conf,ld.so.conf.d,ld.so.preload to the private-etc line of the profile,
you can do this by creating a .local file in ~/.config/firejail/PROFILE_NAME.local with the following content:
private-etc ld.so.conf,ld.so.conf.d,ld.so.preload