Product SiteDocumentation Site

第9章 SELinux

9.1. SELinux 概要
9.1.1. SELinux を実行する利点
9.1.2. 例
9.1.3. SELinux アーキテクチャー
9.1.4. 他のオペレーティングシステムにおける SELinux
9.2. SELinux コンテキスト
9.2.1. ドメイン遷移
9.2.2. プロセスの SELinux コンテキスト
9.2.3. ユーザー向け SELinux コンテキスト
9.3. Targeted Policy
9.3.1. Confined Processes
9.3.2. Unconfined Processes
9.3.3. Confined and Unconfined Users
9.4. SELinux での動作
9.4.1. SELinux パッケージ
9.4.2. 使用するログファイル
9.4.3. メインの設定ファイル
9.4.4. SELinux の有効化および無効化
9.4.5. SELinux モード
9.4.6. ブーリアン
9.4.7. SELinux コンテキスト - ファイルのラベルづけ
9.4.8. file_t および default_t のタイプ
9.4.9. ファイルシステムのマウント
9.4.10. SELinux ラベルのメンテナンス
9.5. ユーザーの制限
9.5.1. Linux と SELinux のユーザーマッピング
9.5.2. 制限された新規 Linux ユーザー: useradd
9.5.3. 制限された既存の Linux ユーザー: semanage login
9.5.4. 標準の対応付けの変更
9.5.5. xguest: キオスクモード
9.5.6. ユーザー実行アプリケーション向けブーリアン
9.6. トラブルシューティング
9.6.1. アクセスが拒否されたときに何が起こるでしょうか
9.6.2. 問題の 3 大原因
9.6.3. 問題の修復
9.7. 詳細情報
9.7.1. 貢献者
9.7.2. 他のリソース

9.1. SELinux 概要

Security-Enhanced Linux (SELinux) は Linux カーネルにおける 強制アクセス制御 機構の実装です。これは、標準的な任意アクセス制御が確認された後で、許可された操作であることを確認します。これは National Security Agency により作成されました。Linux システムにおいてファイルとプロセスに対して、また、定義されたポリシーに基づいてアクションに対してルールを強制できます。
SELinux を使用するとき、ディレクトリやデバイスを含む、ファイルをオブジェクトとして参照します。ユーザーが実行するコマンドや Mozilla® Firefox® アプリケーションのようなプロセスは、サブジェクトとして参照されます。多くのオペレーティングシステムは、サブジェクトがどのようにオブジェクトとやりとりするか、およびサブジェクトがどのようにお互いにやりとりするかを制御する、任意アクセス制御 (DAC: Discretionary Access Control) システムを使用します。DAC を使用するオペレーティングシステムにおいて、ユーザーが所有するファイル (オブジェクト) のパーミッションを制御します。たとえば、Linux® オペレーティングシステムにおいて、ユーザーが自身のホームディレクトリを全体読み込み可能にできます。ユーザーやプロセス (サブジェクト) が潜在的に機微な情報にアクセスする可能性があります。この望まないアクションにさらなら保護がありません。
DAC 機構のみに依存することは、強固なシステムセキュリティに基本的に適していません。DAC アクセス判定は、ユーザーと所有者のみに基づいており、ユーザーの役割、プログラムの関数および信頼性、およびデータの機密性や完全性のような、他のセキュリティ関連の情報を無視します。それぞれのユーザーが自身のファイルに関する完全な決定権を持ち、システム全体のセキュリティポリシーを強制することが不可能です。さらに、すべてのプログラムが、ユーザーに権限委譲されたパーミッションをすべて引き継ぐことにより実行されます。そして、これはユーザーのファイルに対するアクセス権を自由に変更します。そのため、悪意のあるソフトウェアに対して何も保護されません。多くのシステムサービスと特権プログラムが、その要件をはるかに超える荒い権限で実行する必要があります。そのため、これらのプログラムのどれかにおける欠陥がシステムの完全アクセス権を手に入れる危険にさらされる可能性があります。[14]
以下は、Security-Enhanced Linux (SELinux) を実行していない Linux オペレーティングシステムにおいて使用されるパーミッションの例です。これらの例におけるパーミッションと出力はお使いのシステムと異なるかもしれません。ファイルのパーミッションを表示するには ls -l コマンドを使用します:
$ ls -l file1
-rw-rw-r--. 1 user1 group1 0 May 11 10:46 file1
最初 3 つのパーミッションビット rwxfile1 に対して Linux user1 ユーザー (この場合、所有者) の持つアクセス権を制御します。次の 3 つのパーミッションビット rw- が、file1 に対して Linux group1 グループの持つアクセス権を制御します。最後の 3 つのパーミッションビット r-- が、file1 に対してすべてのユーザーが持つアクセス権を制御します。これは、すべてのユーザーとプロセスが含まれます。
DAC 機構は基本的に強固なシステムセキュリティに適していません。DAC アクセス判定は、ユーザーと所有者のみに基づいており、ユーザーの役割、プログラムの関数および信頼性、およびデータの機密性や完全性のような、他のセキュリティ関連の情報を無視します。それぞれのユーザーが自身のファイルに関する完全な決定権を持ち、システム全体のセキュリティポリシーを強制することが不可能です。さらに、すべてのプログラムが、ユーザーに権限委譲されたパーミッションをすべて引き継ぐことにより実行されます。そして、これはユーザーのファイルに対するアクセス権を自由に変更します。そのため、悪意のあるソフトウェアに対して何も保護されません。多くのシステムサービスと特権プログラムが、その要件をはるかに超える荒い権限で実行する必要があります。そのため、これらのプログラムのどれかにおける欠陥がシステムの完全アクセス権を手に入れる危険にさらされる可能性があります。[15]
以下は、SELinux を実行する Linux オペレーティングシステムにおいて、プロセス、Linux ユーザー、およびファイルに使用されるセキュリティ関連情報を含むラベルの例です。この情報は SELinux コンテキスト と呼ばれ、ls -Z コマンドを使用して表示されます:
$ ls -Z file1
-rw-rw-r--. user1 group1 unconfined_u:object_r:user_home_t:s0 file1
この例では、SELinux が (unconfined_u)、ロール (object_r)、タイプ (user_home_t) およびレベル (s0) を提供します。この情報はアクセス制御の判定のために使用されます。DAC を用いると、アクセス権が Linux ユーザーとグループ ID のみに基づいて制御されます。SELinux ポリシールールは DAC ルールのに確認されることを覚えておくことが重要です。まず DAC ルールがアクセスを拒否すれば、SELinux ポリシールールが使用されません。
Linux と SELinux のユーザー
SELinux を実行する Linux オペレーティングシステムにおいて、Linux ユーザーと同じように SELinux ユーザーがあります。SELinux ユーザーは SELinux ポリシーの一部です。Linux ユーザーが SELinux ユーザーに対応づけられます。混乱を避けるため、このドキュメントは両者を区別するために、"Linux ユーザー" と "SELinux ユーザー" を使用します。

9.1.1. SELinux を実行する利点

  • すべてのプロセスとファイルはタイプでラベルが付けられます。タイプがプロセス向けのドメインとファイル向けのタイプを定義します。SELinux ポリシールールが、どのようにプロセスがファイルとやりとりするか、およびどのようにプロセスが相互にやりとりするかについて定義します。それを明示的に許可する SELinux ポリシーが存在するときのみ、アクセスが許可されます。
  • かなり精細なアクセス制御。ユーザーが任意に制御し、Linux ユーザーとグループ ID に基づく、伝統的な UNIX® パーミッションをはるかに超えて、SELinux は SELinux ユーザー、ロール、タイプおよびオプションのレベルのように、すべての利用可能な情報に基づいてアクセス権を判断します。
  • SELinux ポリシーは、管理者により定義され、システム全体で強制され、ユーザーにより任意に設定されません。
  • 権限を上昇される攻撃の脆弱性を減らします。ある例: プロセスがドメインで実行され、そのためお互いに分離されます、また、SELinux ポリシールールがどのようにプロセスがファイルや他のプロセスにアクセスするのかを定義します。そのため、プロセスが侵入されても、そのプロセスの通常の機能、およびプロセスがアクセスするよう設定されているファイルに対してのみ、攻撃者がアクセスできます。たとえば、Apache HTTP Server が侵入されても、SELinux ポリシールールがアクセスを許可するよう追加または設定されていなければ、攻撃者がユーザーのホームディレクトリにあるファイルを読み込むために、そのプロセスを使用できません。
  • 制限されたサービス。サービスおよびデーモンがより予測可能になり、通常の操作に必要となるアクセスのみを許可されるように、SELinux がそれらを制限する機能を含みます。
  • SELinux がデータの機密性および完全性を強制するために使用されます。また、プロセスを信頼されない入力から保護します。
SELinux は次のものではありません:
  • ウイルス対策ソフトウェア。
  • パスワード、ファイアウォール、または他のセキュリティシステムの代替。
  • 総合的なセキュリティソリューション。
SELinux は既存のセキュリティソリューションを改善するために設計されています。それらを置き換えるものではありません。SELinux を実行しているときでも、ソフトウェアを最新に保つこと、推測しにくいパスワードを使うこと、ファイアウォールなどの良いセキュリティ慣行に従い続けることが重要です。

9.1.2. 例

以下の例は SELinux がどのようにセキュリティを向上させるかを説明します:
  • 標準のアクションは拒否です。プロセスがファイルを開くなどのアクセスを許可する特定の SELinux ポリシールールが存在しなければ、ファイルアクセスが拒否されます。
  • SELinux が Linux ユーザーを制限できます。数多くの制限された SELinux ユーザーが SELinux ポリシーに存在します。セキュリティルールとそれらに適用される機構の利点を得るために、Linux ユーザーが制限された SELinux ユーザーに対応づけられます。たとえば、Linux ユーザーを SELinux user_u ユーザーに対応づけることにより、Linux ユーザーが (他に設定されていない限り) sudosu のような set user ID (setuid) アプリケーションを実行できなくなります。また、ホームディレクトリにあるファイルやアプリケーションを実行できなくなります - 設定されていると、ユーザーがホームディレクトリにある悪意のあるファイルを実行することを防ぎます。
  • プロセス分離が使用されます。プロセスが自身のドメインで実行されます。これは、プロセスが他のプロセスにより使用されるファイルにアクセスすることを防ぎます。また、プロセスが他のプロセスにアクセスすることを防ぎます。たとえば、SELinux を実行しているとき、他に設定されていなければ、攻撃者が Samba サーバーに侵入できません。また、MySQL® により使用されるデータベースのような、他のプロセスにより使用されるファイルを読み書きするために、Samba サーバーに侵入することはできません。
  • SELinux が設定ミスにより被害を制限する役に立ちます。Domain Name System (DNS) サーバーがしばしば、お互いにゾーン転送として知られていることで情報を複製します。攻撃者が DNS サーバーを偽の情報で更新するためにゾーン転送を使用できます。Fedora で DNS サーバーとして Berkeley Internet Name Daemon (BIND) を実行しているとき、管理者がゾーン転送を実行できるサーバーを制限し忘れたときさえ、標準の SELinux ポリシーがゾーンファイル [16] を BIND named 自身により、または他のプロセスにより、ゾーン転送経由で更新されることを防ぎます。
  • Red Hat® Magazine の記事 Risk report: Three years of Red Hat Enterprise Linux 4[17]Red Hat® Enterprise Linux® 4 における標準の SELinux ターゲットポリシーのため、エクスプロイトが制限されました。
  • SELinux に関する背景情報および、SELinux により防がれるさまざまなエクスプロイトに関する情報は、次の LinuxWorld.com の記事を参照してください。A seatbelt for server software: SELinux blocks real-world exploits[18]
  • Red Hat Enterprise Linux 4 および 5 に同梱された SELinux により低減された OpenPegasus のエクスプロイトに関する詳細は、James Morris の SELinux mitigates remote root vulnerability in OpenPegasus ブログ投稿を参照してください。
Tresys Technology ウェブサイト (の右側) に SELinux Mitigation News セクションがあります。これは SELinux により低減または防止された最近のエクスプロイトを一覧化しています。

9.1.3. SELinux アーキテクチャー

SELinux は Linux カーネルの中に組み込まれた Linux セキュリティモジュールです。SELinux は読み込み可能なポリシールールにより動作します。プロセスがファイルを開くときのように、セキュリティ関連のアクセスが実行されるとき、操作がカーネルにおいて SELinux により割り込まれます。SELinux ポリシールールが操作を許可すると、継続されます。そうでなければ、操作がブロックされ、プロセスがエラーを受け取ります。
アクセスの許可や拒否のような SELinux の判断はキャッシュされます。このキャッシュはアクセスベクターキャッシュ (AVC: Access Vector Cache) として知られています。判断をキャッシュすることにより、SELinux ポリシールールが確認される必要性を減らし、パフォーマンスを改善します。まず DAC によりアクセスを拒否されると、SELinux ポリシールールが効果を持たないことを覚えておいてください。

9.1.4. 他のオペレーティングシステムにおける SELinux

オペレーティングシステムにおける SELinux の実行に関する詳細は以下の情報を参照ください:


[14] "Integrating Flexible Support for Security Policies into the Linux Operating System", by Peter Loscocco and Stephen Smalley. この論文は元々 National Security Agency のために準備され、公的分野において引き継がれています。初期リリースに関する詳細とドキュメントは元の論文を参照してください。すべての編集と変更が Murray McAllister により実行されました。
[15] "Integrating Flexible Support for Security Policies into the Linux Operating System", by Peter Loscocco and Stephen Smalley. この論文は元々 National Security Agency のために準備され、公的分野において引き継がれています。初期リリースに関する詳細とドキュメントは元の論文を参照してください。すべての編集と変更が Murray McAllister により実行されました。
[16] ホスト名と IP アドレスのマッピングのような情報を含み、DNS サーバーにより使用されるテキストファイル。
[17] Cox, Mark. "Risk report: Three years of Red Hat Enterprise Linux 4". 2008年2月26日発行。2009年8月27日アクセス確認: http://www.redhatmagazine.com/2008/02/26/risk-report-three-years-of-red-hat-enterprise-linux-4/.
[18] Marti, Don. "A seatbelt for server software: SELinux blocks real-world exploits". 2008年2月24日発行。2009年8月27日アクセス確認: http://www.linuxworld.com/news/2008/022408-selinux.html?page=1.