Firejail is an easy to use SUID sandbox program that reduces the risk of security breaches by restricting the running environment of untrusted applications using Linux namespaces, seccomp-bpf and Linux capabilities.
Install either , or the AUR package. A GUI application for use with Firejail is also available, .
/etc/firejail/firefox.profile,) most of the supplied profiles still rely heavily on blacklists. This means that anything not explicitly forbidden by the profile will be accessible to the application. For example, if you have btrfs snapshots available in
/mnt/btrfs, a jailed program may be forbidden from accessing
$HOME/.ssh, but would still be able to access
/mnt/btrfs/@some-snapshot/$HOME/.ssh. Make sure to audit your profiles, see #Testing profiles
Since 0.9.60-1, Firejail, has supported more direct integration with Apparmor through a generic apparmor profile. During installation, the profile,
firejail-default, is placed in
/etc/apparmor.d directory, and needs to be loaded into the kernel by running the following command as root:
# apparmor_parser -r /etc/apparmor.d/firejail-default
Local customizations of the apparmor profile are supported by editing the file
Most users will not require any custom configuration and can proceed to #Usage.
Firejail uses profiles to set the security protections for each of the applications executed inside of it - you can find the default profiles in
/etc/firejail/application.profile. Should you require custom profiles for applications not included, or wish to modify the defaults, you may place new rules or copies of the defaults in the
~/.config/firejail/ directory. You may have multiple custom profile files for a single application, and you may share the same profile file among several applications.
If firejail does not have a profile for a particular application, it uses its restrictive system-wide default profile. This can result in the application not functioning as desired, without first creating a custom, and less restrictive profile.
To execute an application using firejail's default protections for that application (the default profile), execute the following:
$ firejail <program name>
One-time additions to the default profile can be added as command line options (see the man page). For example, to execute okular with seccomp protection, execute the following:
$ firejail --seccomp okular
You may define multiple non-default profiles for a single program. Once you create your profile file, you can use it by executing:
$ firejail --profile=/absolute/path/to/profile <program name>
Using Firejail by default
To use Firejail by default for all applications for which it has profiles, run the firecfg tool as root.
This creates symbolic links in
/usr/local/bin pointing to
/usr/bin/firejail, for all programs for which firejail has default profiles.
firecfgon pacman operations:
[Trigger] Type = Path Operation = Install Operation = Upgrade Operation = Remove Target = usr/bin/* Target = usr/local/bin/* Target = usr/share/applications/*.desktop [Action] Description = Configure symlinks in /usr/local/bin based on firecfg.config... When = PostTransaction Depends = firejail Exec = /bin/sh -c 'firecfg >/dev/null 2>&1'
To manually map individual applications execute:
# ln -s /usr/bin/firejail /usr/local/bin/<application>
/usr/local/binshould be set before
- To run a symbolic program with custom Firejail setting, simple prefix firejail as seen in #Usage.
- For a daemon, you will need to overwrite the systemd unit file for that daemon to call firejail, see systemd#Editing provided units.
firecfgonly symlinks the programs listed on
/usr/lib/firejail/firecfg.config. Certain cli programs are absent, such as:
git. These need to be symlinked manually. See Profiles not in firecfg #2507 for why they are not included.
- Symbolic links to
makepkg's ability to preload
libfakeroot.so. See BBS#230913.
Use with hardened_malloc
AUR is a hardened implementation of glibc's
malloc() allocator, originally written for Android but extended for use on the desktop. While not integrated into glibc yet, it can be used selectively with
LD_PRELOAD. The proper way to launch an application within firejail using hardened_malloc is demonstrated below. To make it permanent, you would need to create your own entry in /usr/local/bin for the desired application.
$ firejail --env=LD_PRELOAD='/usr/lib/libhardened_malloc.so' /usr/bin/firefox
The various environment variables and settings that can be used to tune hardened_malloc can be found on its github page.
Enable AppArmor support
There are a number of ways to enable AppArmor confinement on top of a Firejail security profile:
- Pass the
--apparmorflag to Firejail in the command line, e.g.
$ firejail --apparmor firefox
- Use a custom profile.
- Enable Apparmor globally in
/etc/firejail/globals.localand disable as needed through the use of
Verifying Firejail is being used
$ firejail --list
Creating custom profiles
Whitelists and blacklists
Blacklists are permissive:
- Permit everything not explicitly forbidden:
- Permit file or location in any later blacklist:
Whitelists are restrictive:
- Forbid everything not explicitly permitted:
- Forbid file or location in any later whitelist:
The basic process is:
- Copy the default profile (which uses blacklists) to your work folder and give it a unique name
- Change the line
- Gradually comment/uncomment the various options while checking at each stage that the application runs inside the new sandbox
- Desirable options not available in the copied default profile can be found by consulting the manual
- Build a whitelist of permitted locations. For portability, it may be advisable to place at least some of this list it in a
- Test the profile for security holes, see #Testing profiles
- Once satisfied, copy your new profile to either
You may find the following to be useful:
firejail --debug $OtherOptions $PathToProfile $Program > $PathToOutputFileGives a detailed breakdown of the sandbox
firejail --debug-capsgives a list of caps supported by the current Firejail software build. This is useful when building a caps whitelist.
firejail --helpfor a full list of
firemon PIDmonitors the running process. See
firemon --helpfor details
- may also be useful in testing which standard security features are being used
- The idea is to be as restrictive as possible, while still maintaining usability. This may involve sacrificing potentially dangerous functionality and a change in cavalier work habits.
- By default, seccomp filters work on a blacklist (which can be found in the manual). It is possible to use
seccomp.keepto build a custom whitelist of filters for an application. .
- The list of possible options for a firejail profile is extensive, and users should consult the man page.
Persistent local customisation
The standard profile layout includes the capability to make persistent local customisations through the inclusion of
.local files. Basically, each officially supported profile contains the lines
include /etc/firejail/ProgramName.local and
include /etc/firejail/globals.local. Since the order of precedence is determined by which is read first, this makes for a very powerful way of making local customisations.
For example, with reference this firejail question, to globally enable Apparmor and disable Internet connectivity, one could simply create/edit
/etc/firejail/globals.local to include the lines
# enable Apparmor and disable Internet globally net none apparmor
Then, to allow, for example, "curl" to connect to the internet, yet still maintain its apparmor confinement, one would create/edit
/etc/firejail/curl.local to include the lines.
# enable internet for curl ignore net
curl.local is read before
ignore net overrides
net none, and, as a bonus, the above changes would be persistent across future updates.
Firejail's built in audit feature allows the user to find gaps in a security profile by replacing the program to be sandboxed with a test program. By default, firejail uses the
faudit program distributed with Firejail. (Note: A custom test program supplied by the user can also be used.)
- Run the default audit program:
$ firejail --audit transmission-gtk
- Run a custom audit program:
$ firejail --audit=~/sandbox-test transmission-gtk
In the examples above, the sandbox configures the transmission-gtk profile and starts the test program. The real program, transmission-gtk, will not be started.
Firejail with Xorg
On Xorg any program can listen to all keyboard input and the record all screens. The purpose of sandboxing X11 is to restrict this behavior, which is especially problematic for complex programs working with potentially malicious input like browsers.
For a complete setup with (not ideal) clipboard support (clipboard is still always shared), see Sakaki's Gentoo guide, especially the section about the clipboard and automatic rescaling.
xephyr-screen WidthxHeight can be set in
Height are in pixels and based on your screen resolution.
To open the sandbox:
$ firejail --x11 --net=device openbox
device is your active network interface, which is needed to ensure that DNS works. Then right click and select your applications to run.
--net=deviceout of the command as DNS should work automatically.
See the Firejail Wordpress site for a simpler guide.
According to the guide:
- The sandbox replaces the regular X11 server with Xpra or Xephyr server. This prevents X11 keyboard loggers and screenshot utilities from accessing the main X11 server.
Note that the statement:
- The only way to disable the abstract socket
@/tmp/.X11-unix/X0is by using a network namespace. If for any reasons you cannot use a network namespace, the abstract socket will still be visible inside the sandbox. Hackers can attach keylogger and screenshot programs to this socket.
is incorrect, xserverrc can be edited to
-nolisten local which disables the abstract sockets of X11 and helps isolate it.
Sandboxing a browser
Openbox can be configured to start a certain browser at startup.
program.profile is the respective profile contained in
--startup "command" is the command line used to start the program. For example, to start Chromium in the sandbox:
$ firejail --x11 --profile=/etc/firejail/chromium.profile openbox --startup "chromium"
Tips and tricks
Paths containing spaces
If you need to reference, whitelist, or blacklist a directory within a custom profile, such as withAUR, you must do so using the absolute path, without encapsulation or escapes:
Firejail also includes a one time private mode, in which no mounts are made in the chroots to your home directory. In doing this, you can execute applications without performing any changes to disk. For example, to execute okular in private mode, do the following:
$ firejail --seccomp --private okular
Experimental improved tools
Some of the Firejail developers recognized issues with the tools it ships with and made their own, improved versions of them.
- firecfg.py, an improved version of
- fjp, a tool to interact with Firejail profiles.
- firejail-handler-http, which helps with opening HTTP(S) links properly when sandboxing applications.
- firejail-handler-extra, like above but handles other protocols.
Firejail can be hard to debug. The symptoms of a misconfigured or otherwise unfitting setup range from random segmentation faults and hangs in the applications to simple error messages.
Some applications are harder to sandbox than others. For example web browsers and Electron applications tend to need more troubleshooting than others since there is much that can go wrong. It is crucial to check the FAQ and open issues first since debugging can take quite some time.
To remove Firejail created symbolic links (e.g. reset to default):
# firecfg --clean
Verify if any leftovers of Desktop entries are still overruled by Firejail.
Some GUI application launchers (
.desktop files) are coded using absolute paths to an executable, which circumvents firejail's symlink method of ensuring that it is being used. The firecfg tool includes an option to over-ride this on a per-user basis by copying the
.desktop files from
~/.local/share/applications/ and replacing the absolute paths with simple file names.
$ firecfg --fix
There may be cases for which you need to manually modify the
Exec= line of the
.desktop file in
~/.local/share/applications/ to explicitly call Firejail.
$ firecfg --fix-sound
This commands creates a custom
~/.config/pulse/client.conf file for the current user with
enable-shm = no and possible other workarounds.
If the system uses the hidepid kernel parameter, Firemon can only be run as root. This, among other things, will cause problems with the Firetools GUI incorrectly reporting "Capabilities", "Protocols" and the status of "Seccomp".
Proprietary Nvidia drivers
Some users report problems when using Firejail and proprietary graphic drivers from NVIDIA (e.g. ,  or ). This can often be solved by disabling the
noroot Firejail option in the application's profile file.
--net options and Linux kernel >=4.20.0
Example error message:
$ firejail --noprofile --net=eth0 ls Parent pid 8521, child pid 8522 Error send: arp.c:182 arp_check: Invalid argument Error: proc 8521 cannot sync with peer: unexpected EOF Peer 8522 unexpectedly exited with status 1
Warning: Cannot confine the application using AppArmor
Warning: Cannot confine the application using AppArmor. Maybe firejail-default AppArmor profile is not loaded into the kernel. As root, run "aa-enforce firejail-default" to load it.
When running the suggested command you might see:
ERROR: Cache read/write disabled: interface file missing. (Kernel needs AppArmor 2.4 compatibility patch.)
/usr/bin/patch: **** Can't open patch file
This means the
patch with the
-i argument so a whitelist for
/etc/makepkg.conf is needed.
Create the override
patch.local with the value of your
PKGBUILD to use
stdin also works:
patch -p1 < ../file.patch
Graphical applications hang on start with AMDGPU
Some graphical applications, eg Firefox and mpv, will hang on start when using AMDGPU with Mesa >= 19.3.4. See . The issue is fixed upstream, so AUR should work. Alternatively, for all affected applications, add
seccomp !kcmp to their profiles in
etc/firejail. If they already have a
seccomp statement, you can concatenate them as a comma-separated list, eg
Daemonizing/backgrounded processes hang
There is a known issue which prevents processes from daemonizing. There is currently no solution to this except not using Firejail to sandbox the affected application. Because it is a bug within Firejail, no configuration can solve this issue. Fortunately the applications mentioned in the issue usually do not have a large attack surface, so the risks of running them without a sandbox are comparatively low.