「Firejail」の版間の差分
(→トラブルシューティング: 翻訳) |
細 (→トラブルシューティング: リンクを修正) |
||
279行目: | 279行目: | ||
Firejail をデバッグするのは困難になる可能性があります。設定ミスや適切でないセットアップによる症状は、ランダムなセグメンテーションフォールトやアプリケーションのハングアップから単純なエラーメッセージまで多岐にわたります。 |
Firejail をデバッグするのは困難になる可能性があります。設定ミスや適切でないセットアップによる症状は、ランダムなセグメンテーションフォールトやアプリケーションのハングアップから単純なエラーメッセージまで多岐にわたります。 |
||
− | 一部のアプリケーションは他のものよりもサンドボックス化が困難です。例えば、[[Web ブラウザ]]や [[Electron]] アプリケーションは、トラブルになる要因が多いため、他のアプリケーションよりもトラブルシューティングを必要とする傾向にあります。デバッグは非常に多くの時間を要する可能性があるので、[https://github.com/netblue30/firejail/wiki/Frequently-Asked-Questions FAQ] や [https://github.com/netblue30/firejail/issues open issues] をチェックすることは欠かせません。 |
+ | 一部のアプリケーションは他のものよりもサンドボックス化が困難です。例えば、[[アプリケーション一覧#ウェブブラウザ|Web ブラウザ]]や [[Electron]] アプリケーションは、トラブルになる要因が多いため、他のアプリケーションよりもトラブルシューティングを必要とする傾向にあります。デバッグは非常に多くの時間を要する可能性があるので、[https://github.com/netblue30/firejail/wiki/Frequently-Asked-Questions FAQ] や [https://github.com/netblue30/firejail/issues open issues] をチェックすることは欠かせません。 |
{{Tip|[https://github.com/netblue30/firejail/wiki アップストリームの wiki] も参照してください。特に [https://github.com/netblue30/firejail/wiki/Debugging-Firejail debugging Firejail] のページです。}} |
{{Tip|[https://github.com/netblue30/firejail/wiki アップストリームの wiki] も参照してください。特に [https://github.com/netblue30/firejail/wiki/Debugging-Firejail debugging Firejail] のページです。}} |
2022年5月27日 (金) 08:25時点における版
Firejail は使いやすい SUID サンドボックスプログラムであり、Linux の名前空間や seccomp-bpf、Linux ケイパビリティを使うことで、信頼のおけないアプリケーションの実行環境を制限することにより、セキュリティ侵害のリスクを軽減します。
インストール
firejail または firejail-gitAUR パッケージをインストールしてください。Firejail で使用するためのGUIアプリケーション、firetools も用意されています。
設定
ほとんどのユーザはカスタムの設定をする必要はないでしょう。その場合、#使用方法 に進むことができます。
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=
行を手動で変更する必要があるでしょう。
アプリケーションごとに手動で設定するには以下を実行してください:
# ln -s /usr/bin/firejail /usr/local/bin/application
hardened_malloc を使う
hardened_mallocAUR は 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
ホワイトリストプロファイルはランダムな場所へのアクセスを必要とするアプリケーション(テキストエディタやファイルマネージャなど)においては問題が発生することを留意しておいてください。
ローカルのカスタムプロファイルを永続化する
プロファイルの標準的なレイアウトには .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 を使う
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 が機能するために必要です。その後、右クリックして、実行するアプリケーションを選んでください。
似たようなガイドは 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 実行ファイルのファイルのモードを変更することでさらなる堅牢化をはかることができます。詳細はこのページを見てください。
スペースを含むパス
palemoonAUR を使うようなカスタムプロファイル内でとあるディレクトリを参照/ホワイトリスト化/ブラックリスト化する必要がある場合、カプセル化やエスケープなしの絶対パスを用いなければなりません:
/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 をチェックすることは欠かせません。
Firejail のシンボリックリンクを削除する
Firejail が作成したシンボリックリンクを削除するには(例えば、デフォルトに戻す場合):
# firecfg --clean
特定のアプリケーションに対しては Firejail を使いたくない場合(例えば、Firejail よりも AppArmor を使って制限を課したい場合)、手動で関連するシンボリックリンクを削除する必要があります:
# rm /usr/local/bin/application
この後に firecfg を実行すると、削除したシンボリックリンクが再び追加されるので、/etc/firejail/firecfg.config
内のそれぞれのアプリケーションをコメントアウトする必要があります。
デスクトップエントリの残骸が Firejail によって上書きされていないことを確認してください。
PulseAudio
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
一部のアプリケーションでは (例: 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 を使用するとグラフィカルなアプリケーションが起動時にハングする
一部のグラフィカルなアプリケーション(例: 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 の最小限の代用品