跳至內容
出自 Arch Linux 中文维基

Firejail 是一個易於使用的 SUID 沙盒程序,它通過使用 Linux 命名空間、seccomp-bpf 和 Linux 功能來限制不受信任的應用程式的運行環境以降低安全漏洞被利用的風險。

警告:運行不受信任的代碼永遠不安全,沙盒並不能挽救這個局面。

安裝

安裝 firejail 或者 firejail-gitAUR 包. 還有可以與 Firejail 一起使用的 GUI 應用程式, firetools.

注意:有關 Arch Linux 內核中的 user_namespaces(7) 支持的信息,請參閱 Security#Sandboxing applications. Firejail即使被禁用也可以使用
警告:雖然上游正在逐步採用白名單(參見/etc/firejail/firefox.profile),但大多數提供的配置文件仍然嚴重依賴黑名單。這意味著,任何沒有被配置文件明確禁止的東西都會被應用程式訪問。例如,如果你在/mnt/btrfs中有 btrfs 快照,沙盒裡的程序可能被禁止訪問$HOME/.ssh,但仍能訪問/mnt/btrfs/@some-snapshot/$HOME/.ssh。請確保檢查您的配置文件。見#測試配置文件

配置

大多數用戶不需要任何自定義配置,並且可以繼續 #使用方法.

Firejail 使用配置文件為其中執行的每個應用程式設置安全保護 - 您可以在 /etc/firejail/application.profile 中找到默認配置文件. 如果您需要為未包含的應用程式自定義配置文件,或者希望修改默認值, 您可以在 ~/.config/firejail/ 目錄中放置新規則或默認值副本. 一個應用程式可能有多個自定義配置文件,並且您可以在多個應用程式之間共享同一個配置文件.

如果 firejail 沒有特定應用程式的配置文件,它會使用其限制性的系統範圍默認配置文件。如果沒有事先創建自定義且限制較少的配置文件,這可能會導致應用程式無法按預期運行。

參閱 firejail-profile(5)

使用方法

要使用 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中列出的程序建立符號連結。某些命令行界面的程序是不存在的,例如 tarcurlgit。這些程序需要手動建立符號連結。請參閱 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。

提示:可使用 pacman hook來在 pacman 操作中自動運行firecfg
/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 the PATH 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

See firejail(1) § APPARMOR.

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 of ignore 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:

  1. Copy /usr/share/doc/firejail/profile.template to /etc/firejail/ or ~/.config/firejail/ and rename it to ProfileName.profile where ProfileName should match the name of the executable to be sandboxed
  2. Change the line include PROFILE.local to include ProfileName.local
  3. 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.
  4. Detailed explanations of the possible options for a Firejail profile can be found in the firejail-profile(5) man page
  5. 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 use seccomp.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:

  1. firejail --debug $Program > $PathToOutputFile Gives a detailed breakdown of the sandbox
  2. firejail --debug-blacklists $Program and firejail --debug-whitelists $Program show the blacklisted and whitelisted directories and files for the current profile.
  3. firejail --debug-caps gives a list of caps supported by the current Firejail software build. This is useful when building a caps whitelist.
  4. firejail --help for a full list of --debug options
  5. firemon PID monitors the running process. See firemon --help for details
  6. Executing sudo jailcheck tests running sandboxes. See the jailcheck(1) man page for details.
  7. checksec may also be useful in testing which standard security features are being used

Firejail with Xorg

本文或本章節的事實準確性存在爭議。

原因: Why does sandboxing X11 require DNS?(在 Talk:Firejail 中討論)


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.

注意:If you use Unbound, dnsmasq, Pdnsd or any other local resolver on 127.0.0.1, you would leave --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.

警告:As stated in some of the projects descriptions, these tools might be experimental.

疑難解答

Firejail 可能很難調試。配置錯誤或其他不合適設置的症狀包括隨機分段故障、應用程式掛起和簡單的錯誤信息。

有些應用程式比其他應用程式更難沙箱化。例如,網絡瀏覽器Electron 應用程式往往比其他應用程式需要更多的故障排除,因為可能出錯的地方很多。首先查看 FAQopen issues 是至關重要的,因為調試可能需要相當長的時間。

提示:另請參閱上游維基,尤其是其中有關調試 Firejail 的頁面。

移除 Firejail 的符號連結

要移除 Firejail 創建的符號連結(例如重置為默認值):

# firecfg --clean

如果您不想在特定應用程式中使用 Firejail(例如,因為您更喜歡使用 AppArmor 對其進行限制),則必須手動刪除相關的符號連結:

# rm /usr/local/bin/application

由於後續執行 firecfg 時會重新添加已刪除的符號連結,因此應在 /etc/firejail/firecfg.config 中對相應應用程式進行注釋。

驗證 Firejail 是否仍然覆蓋桌面項的任何殘留內容。

PulseAudio

注意:使用 PulseAudio 9.0 或更高版本應該可以解決這個問題。

如果 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 限制應用程式

本文或本章節可能需要合併到#啟用 AppArmor 支持

附註: 應在前文中明確說明啟用 AppArmor 的要求。請注意,Manjaro 的引用是不相關的。(在 Talk:Firejail 中討論)

對於某些應用程式(如 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 內部的一個錯誤,任何配置都無法解決這個問題。幸運的是,問題中提到的應用程式通常沒有很大的攻擊面,因此在沒有沙箱的情況下運行它們的風險相對較低。

參見