Firejail

関連記事

• セキュリティ

Firejail は使いやすい SUID サンドボックスプログラムであり、Linux の名前空間や seccomp-bpf、Linux ケイパビリティを使うことで、信頼のおけないアプリケーションの実行環境を制限することにより、セキュリティ侵害のリスクを軽減します。

インストール

firejail または firejail-git^AUR パッケージをインストールしてください。Firejail で使用するためのGUIアプリケーション、firetools も用意されています。

ノート: Arch Linux の諸カーネルにおける user_namespaces(7) のサポートに関する情報は セキュリティ#アプリケーションのサンドボックス化 を見てください。Firejail は user_namespaces を使用できます(たとえ無効化されていたとしても)。

警告: アップストリームでは徐々にホワイトリスト制が採用されつつありますが(/etc/firejail/firefox.profile を参照)、提供されているプロファイルの殆どがまだブラックリスト制に強く依存しています。これは、プロファイルによって明示的に禁止されていなければ、アプリケーションにアクセスを許してしまうことを意味します。例えば、btrfs のスナップショットを /mnt/btrfs に保存しているとします。隔離されたプログラムは $HOME/.ssh へのアクセスは禁じられているでしょうが、/mnt/btrfs/@some-snapshot/$HOME/.ssh へはアクセスできてしまいます。使用するプロファイルを検査するようにしてください。#プロファイルのテストを参照。

設定

ほとんどのユーザはカスタムの設定をする必要はないでしょう。その場合、#使用方法 に進むことができます。

Firejail は、サンドボックス内で実行されるアプリケーションのそれぞれに対してセキュリティ保護を設定するプロファイルを使用します。デフォルトのプロファイルは /etc/firejail/application.profile で見ることができます。含まれていないアプリケーションに対するカスタムのプロファイルが必要な場合や、デフォルトのプロファイルを変更したい場合、新しいルールや、デフォルトのプロファイルのコピーを ~/.config/firejail/ ディレクトリ内に置くことができます。1つのアプリケーションに対して複数のカスタムのプロファイルを設定することもでき、複数のアプリケーションの間で同一のプロファイルを共有させることもできます。

Firejail に特定のアプリケーションのプロファイルが存在しない場合、システム全体の制限付きデフォルトプロファイルを使用します。これにより、カスタムのプロファイルや制限を緩めたプロファイルを先に作成しないと、アプリケーションが期待通りに動作しない可能性があります。

firejail-profile(5) を参照してください。

使用方法

そのアプリケーションに対する firejail のデフォルトの保護(デフォルトのプロファイル)を使用してアプリケーションを実行するには、以下を実行します:

$ firejail <program name>

デフォルトプロファイルへの1回限りの追加は、コマンドラインオプションとして追加できます（マニュアルページを参照）。たとえば、seccomp 保護を使用して okular を実行するには、次のコマンドを実行します:

$ firejail --seccomp okular

1つのプログラムにデフォルト以外の複数のプロファイルを定義できます。プロファイルファイルを作成したら、次のコマンドを実行して使用できます:

$ firejail --profile=/absolute/path/to/profile <program name>

デフォルトで Firejail を使う

Firejail のプロファイルを持つすべてのアプリケーションに対して Firejail を使用するようにするには、firecfg ツールを sudo で実行してください:

$ sudo firecfg

このツールは、Firejail がデフォルトのプロファイルや自己作成したプロファイルを持つすべてのアプリケーションに対して、/usr/bin/firejail を指すシンボリックリンクを /usr/local/bin 内に作成します。firecfg(1) は /etc/firejail/firecfg.config にリストされているプログラムに対してしかシンボリックリンクを作成しないことに注意してください。特定の CLI プログラムはそのリストに存在しません:例えば 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 ファイルが修正されます。

場合によっては、Firejail を明示的に呼び出すようにするために ~/.local/share/applications/ にある .desktop ファイルの Exec= 行を手動で変更する必要があるでしょう。

ヒント: pacman の操作のたびに、firecfg を自動で実行するには pacman フック を使用することができます:

/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

ノート:

• PATH 環境変数では、/usr/local/bin を /usr/bin の前に設定する必要があります。
• カスタムの Firejail の設定を使用してシンボリックリンクのプログラムを実行するには、#使用方法で書かれてあるように、単純に firejail を前につけて実行してください。
• デーモンに対しては、systemd のユニットファイルを上書きして、デーモンが Firejail を呼び出すようにする必要があります。systemd#ユニットファイルの編集 を参照してください。
• gzip や xz へのシンボリックリンクは makepkg の libfakeroot.so をプリロードする機能と干渉します。BBS#230913 を参照してください。

hardened_malloc を使う

hardened_malloc^AUR は glibc の malloc() アロケータを堅牢化した実装です。もともとは Android 用に記述されましたが、デスクトップ用に拡張されました。glibc にはまだ統合されていませんが、LD_PRELOAD で選択して使用することができます。hardened_malloc を使用して Firejail 内でアプリケーションを実行する適切な方法は以下のとおりです。永続的に hardened_malloc を使用するには、お望みのアプリケーションに対するエントリを /usr/local/bin 内に作成する必要があります。

$ firejail --env=LD_PRELOAD='/usr/lib/libhardened_malloc.so' /usr/bin/firefox

または、以下をカスタムプロファイルに追加してください:

env LD_PRELOAD=/usr/lib/libhardened_malloc.so

hardened_malloc を調整するのに使える様々な環境変数や設定は github のページで見られます

AppArmor のサポートを有効化する

0.9.60-1 以降、 Firejail は一般的な AppArmor プロファイルを通じて AppArmor との直接的な統合をサポートしてきました。インストール中に、プロファイル firejail-default は、/etc/apparmor.d ディレクトリに配置され、root として次のコマンドを実行してカーネルにロードする必要があります:

# apparmor_parser -r /etc/apparmor.d/firejail-default

firejail(1) § APPARMOR を参照してください。

apparmor プロファイルのローカルカスタマイズは、/etc/apparmor.d/local/firejail-local ファイルを編集することでサポートされます。

AppArmor はすでに 多くの Firejail プロファイルで有効化されています。AppArmor による制限を Firejail のセキュリティプロファイル上で有効化する方法はいくつかあります:

• --apparmor フラグをコマンドラインを通じて Firejail に渡す。例: $ firejail --apparmor firefox
• カスタムプロファイルを使用し、apparmor コマンドを追加する。
• /etc/firejail/globals.local で AppArmor をグローバルに有効化し、必要に応じて /etc/firejail/<ProgramName>.local 内で ignore apparmor を使用して無効化する。

上記の方法で AppArmor を有効化すると必ず /etc/apparmor.d/firejail-default が使用されることに注意してください。あるアプリケーションに対しては特定の AppArmor プロファイルを使いたい場合は、上記の ignore apparmor コマンドを使用する必要があります。しかし、Firejail と AppArmor を同一のアプリケーションに対して使用するとしばしば問題が引き起こされるので、これは推奨されません。

Firejail が使用中かを確認する

$ firejail --list

A more comprehensive output is produced by

$ firejail --tree

カスタムのプロファイルを作成する

ホワイトリストとブラックリスト

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

プロファイルの記述法

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.

ローカルのカスタムプロファイルを永続化する

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.

プロファイルのテスト

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

Xorg と合わせて 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"

ヒントとテクニック

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.

スペースを含むパス

If you need to reference, whitelist, or blacklist a directory within a custom profile, such as with palemoon^AUR, you must do so using the absolute path, without encapsulation or escapes:

/home/user/.moonchild productions

プライベートモード

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

実験的な改良されたツール

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.

• 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 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.

ヒント: Also see the upstream wiki, especially its page on debugging Firejail.

Remove Firejail symbolic links

To remove Firejail created symbolic links (e.g. reset to default):

# firecfg --clean

If you do not want to use Firejail for a specific application (e.g., because you prefer to rather confine it with AppArmor), you have to manually remove the related symbolic link:

# rm /usr/local/bin/application

As a subsequent execution of firecfg would re-add the removed symlinks, the respective applications should be commented in /etc/firejail/firecfg.config.

Verify if any leftovers of Desktop entries are still overruled by Firejail.

PulseAudio

ノート: Using PulseAudio version 9.0 or later should fix this issue.

If Firejail causes PulseAudio issues with sandboxed applications [3], the following command may be used:

$ 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.

hidepid

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"[4].

Proprietary Nvidia drivers

Some users report problems when using Firejail and proprietary graphic drivers from NVIDIA (e.g. [5], [6] or [7]). 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

There is a bug on firejail 0.5.96 with linux >= 4.20.0, see [8] and [9]

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

For some applications (e.g. Firefox [10]) starting with Firejail may result in warnings like:

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.)

This means that AppArmor is not enabled as a kernel parameter, so you have to set it according to AppArmor#Installation.

/usr/bin/patch: **** Can't open patch file

This means the PKGBUILD uses patch with the -i argument so a whitelist for $SRCDEST in /etc/makepkg.conf is needed.

Create the override patch.local with the value of your $SRCDEST:

whitelist /path/to/makepkg/sources

Changing the PKGBUILD to use stdin also works:

patch -p1 < ../file.patch

Graphical applications hang on start with AMDGPU

Some graphical applications, e.g. Firefox and mpv, would hang on start when using AMDGPU with Mesa >= 19.3.4. See [11].

This should be fixed as of firejail 0.9.66, as kcmp is not dropped by default anymore (see also [12]). If this still happens, please report it.

As a workaround, 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 seccomp !chroot,!kcmp.

Daemonizing/backgrounded processes hang

There is a known issue that 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.

参照

• Firejail GitHub プロジェクトページ
• bubblewrap Firejail の最小限の代用品