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

より総合的な出力を得るには:

$ firejail --tree

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

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

blacklist は、ほとんどのプロファイルでインクルードされている様々な /etc/firejail/*.inc ファイルで頻繁に使用されています。blacklist は寛容的です:

あるディレクトリやファイルへのアクセスを拒否し、その他は許可する: blacklist <directory/file>
すでにブラックリストに載っているディレクトリやファイルのブラックリスト化を無効化/取り消し/無視する。例: *.inc ファイルで noblacklist <directory/file>

blacklist がプロファイルの中に現れる順番は重要です: noblacklist ディレクティブは blacklist ディレクティブより上に追加しなければなりません。

whitelist は明示的にホワイトリスト化されているもの以外をすべてブロックします。ランダムな場所へのアクセスを必要とするアプリケーションのプロファイル内では使用すべきではありません(例: テキストエディタ、画像ビューア/エディタ)。

あるディレクトリやファイルへのアクセスを許可し、その他を禁止する: whitelist <directory/file>
すでにホワイトリストに載っているディレクトリやファイルのホワイトリスト化を無効化/取り消し/無視する。例: *.inc ファイルで nowhitelist <directory/file>

whitelist がプロファイルの中に現れる順番は重要です: nowhitelist ディレクティブは whitelist ディレクティブより上に追加しなければなりません。

ホワイトリスト化は常にブラックリスト化よりも前に行われます。言及したように、whitelist ディレクティブは対象以外すべてをブラックリスト化します。ゆえに、whitelist ディレクティブが存在しない場合や、ある whitelist ディレクティブが緩すぎる場合、blacklist ディレクティブはフォールバックとなります。

(no)blacklist と (no)whitelist ディレクティブはしばしば組み合わせて使用されます。例: /etc/firejail/disable-programs.inc (すべてのプロファイルでインクルードされます)は以下のディレクトリを含んでいます:

blacklist ${HOME}/.mozilla

これにより、Firejail でサンドボックス化されているすべてのアプリケーションでそのディレクトリへのアクセスはブロックされます。/etc/firejail/firefox.profile はこのディレクティブを無効化しなければならず、かつ whitelist ディレクティブを追加してそのディレクトリへのアクセスを許可しなければなりません(Firefox プロファイルはホワイトリストプロファイルであるため):

noblacklist ${HOME}/.mozilla
whitelist ${HOME}/.mozilla

プロファイルの記述法

基本的な手順は以下の通りです:

/usr/share/doc/firejail/profile.template を /etc/firejail/ か ~/.config/firejail/ へコピーし、ファイル名を ProfileName.profile と変更してください。ProfileName はサンドボックス化する実行ファイルの名前と同じであるべきです。
include PROFILE.local の行を include ProfileName.local に変更してください。
対象のアプリケーションがサンドボックス内で実行できることを確かめながら、徐々に様々なオプションをコメントアウト/アンコメントしてください。テンプレート内のセクションの順番は変更しないでください。
Firejail のプロファイルで利用可能なオプションの詳細な説明は firejail-profile(5) man ページで見ることができます。
プロファイルにセキュリティホールがないかテストするには #プロファイルのテストを見てください。

ホワイトリストプロファイルを作成したい場合(例: whitelist ディレクティブを含むプロファイル)、以下のコマンドを実行することで、許可される場所のホワイトリストを作成することができます。

$ firejail --build application

ホワイトリストプロファイルはランダムな場所へのアクセスを必要とするアプリケーション(テキストエディタやファイルマネージャなど)においては問題が発生することを留意しておいてください。

ノート:

考え方としては、利便性を保ちつつ、可能な限り制限することです。この考え方では、潜在的に危険な機能を犠牲にしたり、大雑把なやり方を変える必要があるかもしれません。
デフォルトでは、seccomp のフィルタはブラックリストを使用して動作します(/usr/share/doc/firejail/syscalls.txt で見ることができます)。seccomp.keep を使ってアプリケーション用のフィルタのカスタムホワイトリストを作成することができます[1]。これらの手順を自動化する便利な方法は /usr/lib/firejail/syscalls.sh を実行することです。システムコールが存在しないことでアプリケーションがまだ動作しない場合、/usr/share/doc/firejail/syscalls.txt の下にある指示に従う必要があります。

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

プロファイルの標準的なレイアウトには　.local ファイルをインクルードすることにより永続的なローカルのカスタマイズを行う機能が含まれています[2]。基本的に、公式にサポートされているプロファイルには include ProgramName.local と include globals.local という行が含まれています。これらの *.local ファイルは /etc/firejail か ~/.config/firejail 下に配置されているかもしれません。優先順位はどのファイルが先に読まれるかによって決定されるので、これはローカルのカスタマイズを作成する非常に強力な方法になります。例えば、この firejail の質問では、グローバルに Apparmor を有効化してインターネットの接続を無効化するには、/etc/firejail/globals.local を作成/編集して以下の行を含めるだけです:

# enable Apparmor and disable Internet globally
net none
apparmor

そして、例えば "curl" はインターネットに接続出来るようにしつつ、Apparmor の制限を維持するには、/etc/firejail/curl.local を作成/編集して以下の行を含めます:

# enable internet for curl
ignore net

curl.local が globals.local より前に読み込まれるため、ignore net は net none をオーバーライドします。そして、また、上記の変更は将来のアップデートでも維持されます。

プロファイルのテスト

Firejail のプロファイルをテスト・監査する際には以下が役に立つかもしれません:

firejail --debug $Program > $PathToOutputFile はサンドボックスの詳細な分析を行います。
firejail --debug-blacklists $Program と firejail --debug-whitelists $Program は現在のプロファイルでブラックリスト化/ホワイトリスト化されているディレクトリおよびファイルを表示します。
firejail --debug-caps は現在の Firejail ソフトウェアビルドでサポートされているケーパビリティのリストを出力します。これは caps whitelist を作成する際に便利です。
firejail --help は --debug のオプションの完全なリストを出力します。
firemon PID は実行中のプロセスを監視します。詳細は firemon --help を見てください。
sudo jailcheck を実行するとサンドボックスの実行テストが行われます。詳細は jailcheck(1) の man ページを見てください。
どの標準セキュリティ機能が使用されているかを確かめる際には checksec も便利です。

Xorg と合わせて Firejail を使う

この記事またはセクションの正確性には問題があります。

理由: X11 をサンドボックス化するのになぜ DNS が必要なのか? (議論: トーク:Firejail#)

Xorg 上では、如何なるプログラムもすべてのキーボード入力をリッスンでき、すべてのスクリーンを録画できます。この挙動は特にブラウザのような、潜在的に悪意のある入力を扱う複雑なプログラムにおいて問題となります。X11 をサンドボックス化する目的はこの挙動を制限することです。

Xephyr と Xpra を使えば Xorg をサンドボックス化できます。Xpra はクリップボードを完全にサポートしますが、ネストされた X11 セッションでは非常に顕著で恒久的なラグが発生するため、Xephyr を使用することが推奨されています。

(理想的ではない)クリップボードサポート付き(クリップボードは常に共有されます)の完全なセットアップ方法については Sakaki's Gentoo guide を見てください。特にクリップボードと自動再スケーリングに関するセクションを見てください。

または、クリップボードのサポートは必要ないがウインドウの管理が必要な場合、Openbox などのスタンドアローンなウィンドウマネージャをインストールしてください。

xephyr-screen WidthxHeight は /etc/firejail/firejail.config 内で設定できます。Width と Height はピクセル単位で、スクリーンの解像度を元に設定します。

サンドボックスを開くには:

$ firejail --x11 --net=device openbox

device はアクティブなネットワークインターフェイスであり、DNS が機能するために必要です。その後、右クリックして、実行するアプリケーションを選んでください。

ノート: Unbound や dnsmasq、Pdnsd、あるいは 127.0.0.1 上で他のローカルのリゾルバを使用する場合、DNS が自動的に動作するはずなので --net=device をコマンドから除いてください。

似たようなガイドは Firejail Wordpress サイトを見てください。

そのガイドによると:

サンドボックスは標準的な X11 サーバを Xpra または Xephyr サーバで置き換えます。これにより、X11 キーボードロガーやスクリーンショットユーティリティがメインの X11 サーバにアクセスできなくなります。

以下の文章は不正確であることに注意してください:

抽象化ソケット @/tmp/.X11-unix/X0 を無効化する唯一の方法はネットワーク名前空間を使用することです。何らかの理由によりネットワーク名前空間を使用できない場合、抽象化ソケットはまだサンドボックスの内部から見えます。ハッカーはキーロガーやスクリーンショットプログラムをこのソケットにアタッチできます。

xserverrc は -nolisten local のように編集できます。これにより、X11 の抽象化ソケットを無効化でき、X11 を隔離できます。

ブラウザをサンドボックス化する

Openbox は起動時に特定のブラウザを起動するように設定できます。program.profile は /etc/firejail に含まれている個別のプロファイルで、--startup "command" はプログラムを起動する際に用いるコマンドラインです。例えば、Chromium をサンドボックス内で起動する場合:

$ firejail --x11 --profile=/etc/firejail/chromium.profile openbox --startup "chromium"

ヒントとテクニック

Firejail をより堅牢にする

Firejail が SUID 実行ファイルであることのセキュリティリスクは以下の行を /etc/firejail/firejail.config に追加することで緩和できます:

force-nonewprivs yes

しかし、これは特定のアプリケーションの機能を破壊する可能性があります。Arch Linux 上では、VirtualBox が起動できなくなります。linux-hardened カーネルでは、Wireshark や Chromium ベースのブラウザも影響を受けます。

特別な firejail のグループを作成してユーザをそのグループに追加したり、firejail 実行ファイルのファイルのモードを変更することでさらなる堅牢化をはかることができます。詳細はこのページを見てください。

スペースを含むパス

palemoon^AUR を使うようなカスタムプロファイル内でとあるディレクトリを参照/ホワイトリスト化/ブラックリスト化する必要がある場合、カプセル化やエスケープなしの絶対パスを用いなければなりません:

/home/user/.moonchild productions

プライベートモード

Firejail は一回限りのプライベートモードも含んでいます。このモードでは、ホームディレクトリへの chroot でマウントが行われません。こうすれば、ディスクへの変更を伴わずにアプリケーションを実行できます。例えば、okular をプライベートモードで実行する場合、以下のようにしてください:

$ firejail --seccomp --private okular

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

一部の Firejail 開発者はパッケージに同梱されているツールの問題を認識し、彼ら独自の改良されたバージョンを作成しました。

警告: いくつかのプロジェクトの説明にあるように、これらのツールは実験的であるかもしれません。

firecfg.py: firecfg の改良バージョン。
fjp: Firejail のプロファイルと対話するツール。
firejail-handler-http: アプリケーションをサンドボックス化しているときに HTTP(S) のリンクを適切に開くことを補助します。
firejail-handler-extra: 上のものに似ていますが、他のプロトコルも処理します。

トラブルシューティング

Firejail をデバッグするのは困難になる可能性があります。設定ミスや適切でないセットアップによる症状は、ランダムなセグメンテーションフォールトやアプリケーションのハングアップから単純なエラーメッセージまで多岐にわたります。

一部のアプリケーションは他のものよりもサンドボックス化が困難です。例えば、Web ブラウザや Electron アプリケーションは、トラブルになる要因が多いため、他のアプリケーションよりもトラブルシューティングを必要とする傾向にあります。デバッグは非常に多くの時間を要する可能性があるので、FAQ や open issues をチェックすることは欠かせません。

ヒント: アップストリームの wiki も参照してください。特に debugging Firejail のページです。

Firejail のシンボリックリンクを削除する

Firejail が作成したシンボリックリンクを削除するには(例えば、デフォルトに戻す場合):

# firecfg --clean

特定のアプリケーションに対しては Firejail を使いたくない場合(例えば、Firejail よりも AppArmor を使って制限を課したい場合)、手動で関連するシンボリックリンクを削除する必要があります:

# rm /usr/local/bin/application

この後に firecfg を実行すると、削除したシンボリックリンクが再び追加されるので、/etc/firejail/firecfg.config 内のそれぞれのアプリケーションをコメントアウトする必要があります。

デスクトップエントリの残骸が Firejail によって上書きされていないことを確認してください。

PulseAudio

ノート: PulseAudio バージョン 9.0 およびそれ以降を使用すればこの問題を修正できるはずです。

Firejail が、サンドボックス化されたアプリケーションで PulseAudio の問題を引き起こす場合[3]、以下のコマンドを使用できます:

$ firecfg --fix-sound

このコマンドは、enable-shm = no や利用可能な他の回避策を使用するカスタムの ~/.config/pulse/client.conf ファイルを現在のユーザに対して作成します。

hidepid

システムで hidepid カーネルパラメータが使用されている場合、Firemon は root としてしか実行できません。これは、とりわけ、Firetool GUI が "Capabilities" や "Protocols"、"Seccomp" の状態を正しく報告しない問題を引き起こします[4]。

プロプライエタリな Nvidia ドライバ

一部のユーザは、Firejail と NVIDIA のプロプライエタリなグラフィックドライバを使用した際に問題が発生することを報告しています(例: [5]、[6]、[7])。この問題は 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

Warning: Cannot confine the application using AppArmor

この記事あるいはセクションは #Enable AppArmor support と合併することが議論されています。

ノート: The requirement to enable AppArmor should be made explicit in the previous text. And note that Manjaro references are irrelevant. (議論: トーク: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 引数で使用していることを意味しています。ゆえに、$SRCDEST に対するホワイトリストが /etc/makepkg.conf 内で必要です。

patch.local を作成して $SRCDEST の値をオーバーライドしてください:

whitelist /path/to/makepkg/sources

PKGBUILD を stdin を使用するように変更しても機能します

patch -p1 < ../file.patch

AMDGPU を使用するとグラフィカルなアプリケーションが起動時にハングする

このセクションは削除するべきか検討が行われています。

Reason: This should be fixed since 2021-06 with the release of 0.9.66 (議論: トーク:Firejail#)

一部のグラフィカルなアプリケーション(例: Firefox、mpv)は AMDGPU と Mesa >= 19.3.4 を使用すると起動時にハングします。[11] を見てください。

firejail 0.9.66 以降 kcmp がデフォルトドロップされなくなったので、この問題は修正されているはずです。この問題がまだ発生する場合、報告してください。

回避策として、すべての影響を受けるアプリケーションに対して seccomp !kcmp を etc/firejail 下のプロファイルに追加してください。プロファイルにすでに seccomp 文が存在する場合、コンマで区切ったリストで繋げることができます(例: seccomp !chroot,!kcmp)。

デーモン化した/バックグラウンドのプロセスがハングする

プロセスをデーモン化できない既知の問題が存在します。現在、Firejail を使用せずに、影響を受けるアプリケーションをサンドボックス化する以外に解決法はありません。これは Firejail 内部のバグなので、設定によりこの問題を解決することはできません。幸い、issue で言及されたアプリケーションには通常大きな攻撃領域は存在しないので、これをサンドボックスなしで実行するリスクは比較的低いです。

参照

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