Firejail 是一个易于使用的 SUID 沙盒程序,它通过使用 Linux 命名空间、seccomp-bpf 和 Linux 功能来限制不受信任的应用程序的运行环境以降低安全漏洞被利用的风险。
安装
安装 firejail包 或者 firejail-gitAUR 包. 还有可以与 Firejail 一起使用的 GUI 应用程序, firetools包.
/etc/firejail/firefox.profile
),但大多数提供的配置文件仍然严重依赖黑名单。这意味着,任何没有被配置文件明确禁止的东西都会被应用程序访问。例如,如果你在/mnt/btrfs
中有 btrfs 快照,沙盒里的程序可能被禁止访问$HOME/.ssh
,但仍能访问/mnt/btrfs/@some-snapshot/$HOME/.ssh
。请确保检查您的配置文件。见#测试配置文件。配置
大多数用户不需要任何自定义配置,并且可以继续 #使用方法.
Firejail 使用配置文件为其中执行的每个应用程序设置安全保护 - 您可以在 /etc/firejail/application.profile
中找到默认配置文件. 如果您需要为未包含的应用程序自定义配置文件,或者希望修改默认值, 您可以在 ~/.config/firejail/
目录中放置新规则或默认值副本. 一个应用程序可能有多个自定义配置文件,并且您可以在多个应用程序之间共享同一个配置文件.
如果 firejail 没有特定应用程序的配置文件,它会使用其限制性的系统范围默认配置文件。如果没有事先创建自定义且限制较少的配置文件,这可能会导致应用程序无法按预期运行。
使用方法
要使用 firejail 对该应用程序的默认保护(默认配置文件)执行应用程序,请执行以下命令 :
$ firejail <应用程序名称>
一次性添加到默认配置文件可以作为命令行选项添加(参见 firejail(1))。 例如,要执行带有 seccomp 保护的 okular,请执行以下命令 :
$ firejail --seccomp okular
您可以为单个程序定义多个非默认配置文件。 创建配置文件后,您可以通过执行来使用它 :
$ firejail --profile=/absolute/path/to/profile <program name>
默认配置使用 Firejail
默认情况下将 Firejail 用于具有配置文件的所有应用程序 , 使用 sudo 运行 firecfg 工具:
$ sudo firecfg
这将在/usr/local/bin
中创建指向/usr/bin/firejail
,用于 Firejail 有默认或自定配置文件的程序的符号链接。请注意,firecfg(1) 只与/etc/firejail/firecfg.config
中列出的程序建立符号链接。某些命令行界面的程序是不存在的,例如 tar、curl 和 git。这些程序需要手动建立符号链接。请参阅 Profiles not in firecfg #2507 了解为什么不包括这些程序。firecfg 还将当前用户加入 Firejail 用户访问数据库,并检查/usr/share/applications/*.desktop
文件是否包含相应可执行文件的完整路径,然后删除完整路径并将其复制到~/.local/share/applications/
。这确保了/usr/local/bin
中的符号链接将被使用,从而防止 Firejail 被绕过。如果您的系统中没有安装 sudo,请以 root 身份执行:
# firecfg
以及以一般用户执行:
$ firecfg --fix
以修复 .desktop 文件
在某些情况下,您可能需要手动修改~/.local/share/applications/
中 ".desktop " 文件的Exec=
行,以直接调用 Firejail。
/etc/pacman.d/hooks/firejail.hook
[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'
要手动链接各个应用程序,请执行以下操作:
# ln -s /usr/bin/firejail /usr/local/bin/application
-
/usr/local/bin
must be set before/usr/bin
and/bin
in thePATH
environment variable. - To run a symbolic program with custom Firejail setting, simple prefix firejail as seen in #使用方法.
- For a daemon, you will need to overwrite the systemd unit file for that daemon to call firejail, see systemd#Editing provided units.
- Symbolic links to gzip and xz interfere with makepkg's ability to preload
libfakeroot.so
. See BBS#230913.
Use with hardened_malloc
hardened_mallocAUR 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
Alternatively, add the following to a custom profile:
env LD_PRELOAD='/usr/lib/libhardened_malloc.so'
The various environment variables and settings that can be used to tune hardened_malloc can be found on its github page.
Enable AppArmor support
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 /etc/apparmor.d/local/firejail-local
AppArmor is already enabled for a large number of Firejail profiles. There are several ways to enable AppArmor confinement on top of a Firejail security profile:
- Pass the
--apparmor
flag to Firejail in the command line, e.g.$ firejail --apparmor firefox
- Use a custom profile and add the
apparmor
command. - Enable Apparmor globally in
/etc/firejail/globals.local
and disable as needed through the use ofignore apparmor
in/etc/firejail/<ProgramName>.local
.
Note that enabling AppArmor by above methods always means that /etc/apparmor.d/firejail-default
is used. If you rather want to use a specific AppArmor profile for an application, you have to use the above mentioned ignore apparmor
command. However, that is not recommended, as using both Firejail and AppArmor for the same applications often creates problems.
Verifying Firejail is being used
$ firejail --list
A more comprehensive output is produced by
$ firejail --tree
Creating custom profiles
Whitelists and blacklists
Blacklists are heavily used in various /etc/firejail/*.inc
files which are included in most profiles. Blacklists are permissive:
- Deny access to a directory or file and permit everything else:
blacklist <directory/file>
- Disable/undo/ignore blacklisting a directory or file already blacklisted, e.g., in an *.inc file:
noblacklist <directory/file>
The order in which they appear in a profile is important: noblacklist directives must be added above blacklist directives.
Whitelists block everything what is not explicitly whitelisted. They should not be used in profiles for applications that need access to random locations (e.g., text editors, image viewers/editors).
- Allow access to a directory or file and forbid everything else:
whitelist <directory/file>
- Disable/undo/ignore whitelisting a directory or file already whitelisted, e.g., in an *.inc file:
nowhitelist <directory/file>
The order in which they appear in a profile is important: nowhitelist directives must be added above whitelist directives.
Whitelisting is always done before blacklisting. As mentioned, a whitelist directive blacklists everything else. A blacklist directive is therefore a fallback if there are no whitelist directives or if a whitelist directive is too permissive.
(no)blacklist and (no)whitelist directives are often used in combination. Example: /etc/firejail/disable-programs.inc
(which is included in all profiles) contains the directive:
blacklist ${HOME}/.mozilla
in order to block access to that directory for all applications sandboxed by Firejail. /etc/firejail/firefox.profile
must disable this directive and must add a whitelist directive to allow access to that directory (as the Firefox profile is a whitelisted profile):
noblacklist ${HOME}/.mozilla whitelist ${HOME}/.mozilla
Profile writing
The basic process is:
- Copy
/usr/share/doc/firejail/profile.template
to/etc/firejail/
or~/.config/firejail/
and rename it toProfileName.profile
where ProfileName should match the name of the executable to be sandboxed - Change the line
include PROFILE.local
toinclude ProfileName.local
- Gradually comment/uncomment the various options while checking at each stage that the application runs inside the new sandbox. Do not change the order of the sections in that template.
- Detailed explanations of the possible options for a Firejail profile can be found in the firejail-profile(5) man page
- Test the profile for security holes, see #Testing profiles
If you want to create a whitelisted profile (i.e. a profile which contains whitelist directives) you can build a whitelist of permitted locations by executing
$ firejail --build application
Keep in mind that a whitelisted profile is problematic for applications that need to access random locations (like text editors or file managers).
- 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
/usr/share/doc/firejail/syscalls.txt
). It is possible to useseccomp.keep
to build a custom whitelist of filters for an application. [1]. A convenient way to automate these steps is to execute/usr/lib/firejail/syscalls.sh
. If the application is still broken because of missing syscalls, you should follow the instructions at the bottom of/usr/share/doc/firejail/syscalls.txt
.
Persistent local customisation
The standard profile layout includes the capability to make persistent local customisations through the inclusion of .local
files[2]. Basically, each officially supported profile contains the lines include ProgramName.local
and include globals.local
. These *.local files might be located in /etc/firejail
or in ~/.config/firejail
. 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
Since curl.local
is read before globals.local
, ignore net
overrides net none
, and, as a bonus, the above changes would be persistent across future updates.
Testing profiles
In order to test and audit a Firejail profile you may find the following to be useful:
-
firejail --debug $Program > $PathToOutputFile
Gives a detailed breakdown of the sandbox -
firejail --debug-blacklists $Program
andfirejail --debug-whitelists $Program
show the blacklisted and whitelisted directories and files for the current profile. -
firejail --debug-caps
gives a list of caps supported by the current Firejail software build. This is useful when building a caps whitelist. -
firejail --help
for a full list of--debug
options -
firemon PID
monitors the running process. Seefiremon --help
for details - Executing
sudo jailcheck
tests running sandboxes. See the jailcheck(1) man page for details. - checksec包 may also be useful in testing which standard security features are being used
Firejail with Xorg
On Xorg any program can listen to all keyboard input and 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.
Xephyr and Xpra allow you to sandbox Xorg. Although Xpra provides full clipboard support, it is recommended to use Xephyr due to the very notable and permanent lag with nested X11 sessions.
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.
Alternatively, if clipboard support is not needed but windows need to be managed, install a standalone window manager such as Openbox.
xephyr-screen WidthxHeight
can be set in /etc/firejail/firejail.config
where Width
and 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=device
out 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/X0
is 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 /etc/firejail
, and --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
Hardening Firejail
The security risk of Firejail being a SUID executable can be mitigated by adding the line
force-nonewprivs yes
to /etc/firejail/firejail.config
. However, this can break specific applications. On Arch Linux, VirtualBox doesn't start anymore. With the linux-hardened包 kernel Wireshark and Chromium-based browsers are also affected.
Further hardening measures include creating a special firejail group with adding the user to that group and changing the file mode for the firejail executable. For details see here.
Paths containing spaces
If you need to reference, whitelist, or blacklist a directory within a custom profile, such as with palemoonAUR, you must do so using the absolute path, without encapsulation or escapes:
/home/user/.moonchild productions
Private mode
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
firecfg
. - 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 可能很难调试。配置错误或其他不合适设置的症状包括随机分段故障、应用程序挂起和简单的错误信息。
有些应用程序比其他应用程序更难沙箱化。例如,网络浏览器和 Electron 应用程序往往比其他应用程序需要更多的故障排除,因为可能出错的地方很多。首先查看 FAQ 与 open issues 是至关重要的,因为调试可能需要相当长的时间。
移除 Firejail 的符号链接
要移除 Firejail 创建的符号链接(例如重置为默认值):
# firecfg --clean
如果您不想在特定应用程序中使用 Firejail(例如,因为您更喜欢使用 AppArmor 对其进行限制),则必须手动删除相关的符号链接:
# rm /usr/local/bin/application
由于后续执行 firecfg 时会重新添加已删除的符号链接,因此应在 /etc/firejail/firecfg.config
中对相应应用程序进行注释。
验证 Firejail 是否仍然覆盖桌面项的任何残留内容。
PulseAudio
如果 Firejail 会导致沙盒应用程序出现 PulseAudio 有关问题[3],可以使用以下命令:
$ firecfg --fix-sound
此命令会为当前用户创建一个自定义 ~/.config/pulse/client.conf
文件,其中包含 enable-shm = no
和其他可能的变通方法。
hidepid
如果系统使用 hidepid 内核参数,Firemon 只能以 root 身份运行。这将导致 Firetools GUI 错误报告 "Capabilities"、"Protocols" 和 "Seccomp"[4] 的状态等问题。
Nvidia 专有驱动程序
一些用户报告(例如 [5]、[6] 或 [7])称,在使用 Firejail 和 NVIDIA 专有图形驱动程序时会出现问题。通常禁用应用程序的 noroot
选项即可解决这一问题。Firejail 选项。
--net 选项和 Linux 内核 >= 4.20.0
在使用 linux >= 4.20.0 时,firejail 0.5.96 存在一个错误,请参见 [8] 和 [9]。
错误信息示例:
$ 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
警告: 无法使用 AppArmor 限制应用程序
对于某些应用程序(如 Firefox [10])启动 Firejail 时可能会出现以下警告:
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.
运行建议的命令时,您可能会看到
ERROR: Cache read/write disabled: interface file missing. (Kernel needs AppArmor 2.4 compatibility patch.)
这意味着 AppArmor 未作为内核参数启用,因此必须根据 AppArmor#安装进行设置。
/usr/bin/patch: **** Can't open patch file
这意味着 PKGBUILD
会使用 patch
和 -i
参数,因此需要在 /etc/makepkg.conf
中为 $SRCDEST
列出白名单。
用 $SRCDEST
的值创建 覆盖 patch.local
:
whitelist /path/to/makepkg/sources
将 PKGBUILD
改为使用 stdin
也同样有效:
patch -p1 < ../file.patch
使用 AMDGPU 启动图形应用程序时挂起
当使用 AMDGPU 且 Mesa >= 19.3.4 时,某些图形应用程序(如 Firefox 和 mpv)会在启动时挂起。请参见 [11]。该问题已在上游 fixed 解决,因此 firejail-gitAUR 应可正常工作。或者,为所有受影响的应用程序在 etc/firejail
中的配置文件中添加 seccomp !kcmp
。如果它们已经有了 seccomp
语句,则可以将其连接为逗号分隔的列表,例如 seccomp !chroot,!kcmp
。
守护进程/后台进程挂起
有一个 已知问题 会阻止进程守护进程化。除了不使用 Firejail 对受影响的应用程序进行沙箱化之外,目前没有其他解决方案。因为这是 Firejail 内部的一个错误,任何配置都无法解决这个问题。幸运的是,问题中提到的应用程序通常没有很大的攻击面,因此在没有沙箱的情况下运行它们的风险相对较低。
参见
- Firejail GitHub 项目页面
- bubblewrap,一个 Firejail 的最小替代方案