Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
コンテンツコンテンツ
セキュリティ強化ガイド
  1. 前書き
  2. 1 セキュリティと機密保持
  3. 2 コモンクライテリア (Common Criteria)
  4. I 認証
    1. 3 PAM を利用した認証
    2. 4 NIS の使用
    3. 5 YaST を利用した認証クライアントの設定
    4. 6 389 LDAP ディレクトリサービス
    5. 7 Kerberos を利用したネットワーク認証
    6. 8 Active Directory サポート
    7. 9 FreeRADIUS サーバの構築
  5. II ローカルセキュリティ
    1. 10 物理的なセキュリティ
    2. 11 seccheck を利用した自動的なセキュリティチェック
    3. 12 ソフトウエア管理
    4. 13 ファイルの管理
    5. 14 パーティションやファイルの暗号化
    6. 15 cryptctl を利用したアプリケーション向けのストレージ暗号化
    7. 16 ユーザ管理
    8. 17 Spectre/Meltdown チェッカー
    9. 18 YaST を利用したセキュリティの設定
    10. 19 PolKit による認可制御
    11. 20 Linux でのアクセス制御リスト
    12. 21 証明書ストア
    13. 22 AIDE を利用した侵入検知
  6. III ネットワークセキュリティ
    1. 23 X Window System と X 認証
    2. 24 SSH: 機密を保持するネットワーク操作
    3. 25 マスカレードとファイアウオール
    4. 26 VPN サーバの設定
    5. 27 X Window System で動作する PKI マネージャ XCA による管理
  7. IV AppArmor による権限の制限
    1. 28 AppArmor の紹介
    2. 29 入門
    3. 30 プログラムに対する予防接種
    4. 31 プロファイルのコンポーネントと文法
    5. 32 AppArmor のプロファイルリポジトリ
    6. 33 YaST を利用したプロファイルの構築と管理
    7. 34 コマンドラインからのプロファイル構築
    8. 35 チェンジハット機能による Web アプリケーションのプロファイル作成
    9. 36 pam_apparmor によるユーザの制限
    10. 37 プロファイルを作成したアプリケーションの管理
    11. 38 サポート
    12. 39 AppArmor 用語集
  8. V SELinux
    1. 40 SELinux の設定
  9. VI Linux 監査フレームワーク
    1. 41 Linux 監査システムの概要
    2. 42 Linux 監査フレームワークの設定
    3. 43 監査ルールセットの紹介
    4. 44 その他の情報源
  10. A GNU ライセンス
ナビゲーション
適用先 openSUSE Leap 15.2

40 SELinux の設定

本章では、 openSUSE Leap 上で SELinux を使用する際の、設定と管理の方法について説明しています。下記のトピックをカバーしています:

  • なぜ SELinux を使用するのか

  • SELinux とは

  • SELinux の設定方法

  • SELinux の管理

40.1 なぜ SELinux を使用するのか

SELinux は Linux カーネル内でのセキュリティフレームワークを使用する、追加の Linux セキュリティソリューションとして開発されてきました。既存の読み込みと書き込み、実行に対するパーミッション設定で利用可能な機能に加える形で、さらにきめ細かいセキュリティポリシーを適用できるようにし、 Linux 上で利用できる様々なケーパビリティに対して、さらに詳しいアクセス許可設定を実現するためのものです。 SELinux はカーネルに対して届くすべてのシステムコールを捉え、既定では拒否するように設定されています。これにより、 SELinux が有効化されている環境では、何も設定されていないと何も動作しないことになります。お使いのシステムが何らかの動作を必要とする場合、管理者はルールを作成してポリシー内に配置する必要があります。

下記の例では、なぜ SELinux (もしくはその同等品である AppArmor) が必要となるのかについて、説明しています:

ある朝、私はサーバがクラックされていることに気がついた。サーバは openSUSE Leap ですべての修正 (パッチ) が適用され動作していた。ファイアウオールについても正しく設定が行われ、そのサーバでは不要なサービスは全く提供していなかった。より詳しく調査を行うと、クラッカーはサーバ内の Apache 仮想ホスト内の 1 つに設置された、脆弱性のある PHP スクリプトを通して侵入を行っていた。クラッカーはその後、 Apache Web サーバで使用されている wwwrun を利用して、シェルへのアクセスを取得していた。この wwwrun での侵入後、 /var/tmp および /tmp の各ディレクトリ内に複数のスクリプトを作成し、これを様々なサーバへの分散型サービス拒否攻撃のボットネットとして動作させていた。

ここで注目すべき点は、このクラッキングでは、サーバ側の設定を誤っているわけではない、という点です。すべてのパーミッションの設定が正しいにも関わらず、侵入者はシステム内に入り込むことができてしまっています。この例で悪い点があるとすれば、追加のセキュリティシステムが必要であるにもかかわらず、それを導入していなかった点にあります。このような要件に対応できるのが SELinux です。 SELinux とは異なり、完成度が低いものの簡易的なセキュリティとして使用できるのが AppArmor となります。

AppArmor はプロセスに対して権限を制限し、ファイル (もしくはその他のオブジェクト) に対して、読み込みや書き込み、実行などの制御を行います。もちろんプロセス内部からは、その制限を回避することができません。

SELinux では、オブジェクト (ファイルやバイナリ、ネットワークソケット) に対してラベルを設定し、このラベルを権限の境界線を決めるものとして使用します。そのため、複数のプロセスやシステム全体にまたがる制限レベルを設定することができます。

SELinux は アメリカ国家安全保障局 (US National Security Agency (NSA)) が開発してきたソフトウエアで、 Red Hat 社も大きく開発に関わっています。 SELinux の初期バージョンは、 2006 年前後に公開された Red Hat Enterprise Linux 4™ で初めて提供されました。当初は基本的なサービスにのみ対応していたものの、後年になって幅広いサービスに対する保護を提供する目的で、様々なポリシーを含む多数のルールがシステムに取り込まれるようになりました。

SELinux は Common Criteria や FIPS 140 などの標準規格に従って開発されてきた経緯があります。そのため、これらの標準に従ったソリューションを求める顧客が要求を行ってきたことで、 SELinux は比較的早く有名な存在になりました。

SELinux の代替として、 2005 年に Novell に買収された Immunix 社が AppArmor を開発しました。 AppArmor は SELinux と同じセキュリティ原則で作成されていますが、 SELinux とは全く異なるアプローチで作られています。それは、ウイザード型の作業手順を適用することで、アプリケーションが必要とするリソースを正確に設定できるはずである、という考え方です。 SELinux よりも AppArmor のほうが、サーバの安全を確保するのに適切な点も存在するのですが、残念ながら AppArmor は SELinux と同じ状況には至っていません。

多くの組織では、 Linux ディストリビューションに対して SELinux を使用するように求めています。 SUSE もその中の 1 つで、 openSUSE Leap 内で SELinux フレームワークへの対応が求められてきました。もちろんこれは、 openSUSE Leap の既定のインストールで、近い将来 AppArmor が SELinux に置き換えられるというわけではありません。

40.1.1 サポート状態

SELinux フレームワークは openSUSE Leap でもサポート対象となっています。つまりopenSUSE Leap では、お使いのサーバ内で SELinux を使用するのに必要な、すべてのバイナリやライブラリが提供されます。

openSUSE Leap での SELinux は、比較的初期の段階にあるものと考えられています。つまり、場合によっては予期しない結果をもたらすこともあります。発生しうるリスクを最小限にするには、既定の openSUSE Leap で提供されるバイナリのみを使用するようにしてください。

40.1.2 SELinux のコンポーネント

SELinux の設定を始める前に、まずは SELinux の構成について知っておく必要があります。 SELinux では、下記の 3 種類から構成されています:

  • Linux カーネル内にあるセキュリティフレームワーク

  • SELinux のライブラリとバイナリ

  • SELinux のポリシー

openSUSE Leap の既定のカーネルであれば SELinux に対応していますので、ツールを使用するだけで管理を行うことができます。そのため、管理者にとって最も重要な作業は、 SELinux のポリシー管理ということになります。

警告
警告: 既定のポリシーが同梱されていない件について

openSUSE Leap では、既定のポリシーや標準のポリシーは提供されておりません。 SELinux はポリシー無しでは動作しませんので、ポリシーを構築してインストールしなければならないことになります。 SELinux の Reference Policy Project ( https://github.com/SELinuxProject/refpolicy/wiki ) (英語) にはポリシーの作成に関する例や詳細な情報がありますが、本章でも SELinux のポリシー管理に関するガイダンスを説明しています。

SELinux のポリシーでは、 Linux サーバ内の様々なオブジェクトに対して、セキュリティラベルを設定します。これらのオブジェクトには、ユーザやポート、プロセスやファイルなどが含まれます。このようなセキュリティラベルを使用することで、サーバ内での許可を判断することになります。ただし、既定の SELinux ではすべてのものを拒否する仕組みであることから、どうしても必要なアクセスのみを許可する適切なルール構築が重要となります。そのため、ルールはシステム内で使用するすべてのプログラムに対して存在していなければならないことになります。システムの一部に対して制限を撤廃することもできますが、その場合は、制限を撤廃したポートやプログラム、ユーザやディレクトリなどが、 SELinux で保護されないことになります。このモードでは、重要なサービスのみを SELinux で保護し、その他のサービスについては何もしないようにすることができます。ただし、システムの安全性という観点では、このような構成は避けるべきものです。

お使いのシステムに対して適切な保護を実現するには、 SELinux のポリシーを設定する必要があります。これはすべてのファイルに対してラベルを提供するよう仕立て上げられたポリシーでなければならず、すべてのサービスやユーザに対してセキュリティラベルを設定し、サーバ内でどのファイルやディレクトリにアクセスを許可するのかを設定するものでなければなりません。このようなポリシーの作成には、途方もない労力が必要となります。

SELinux は複雑な仕組みであることから、その使用を避けられる理由の 1 つにもなってしまっています。一般的な Linux システムも非常に複雑な仕組みであることから、何らかの考慮漏れを生み出す原因になってしまっていて、システムに侵入できる突破口を残してしまう原因にもなっています。また、あるべき姿で完全に設定した場合であっても、 SELinux に関わるすべての要素を管理者が網羅するのは非常に難しいものです。複雑性という観点では、 AppArmor は全く異なるアプローチになっています。 AppArmor では、管理者がその保護を設定する際、何が起こっているのかを理解するのに十分な自動化を提供しています。

なお、無償で提供されている様々な SELinux ポリシーは、お使いのサーバでも問題なく動作するとは思いますが、独自にポリシーを構築するのに比べると、保護レベルが落ちることがほとんどであることに注意してください。また、 SUSE ではサードパーティ製のポリシーへのサポートは行っておりません。

40.2 ポリシー

SELinux で鍵となるコンポーネントはポリシーそのものです。 openSUSE Leap には既定のポリシーや標準ポリシーのようなものは提供しておりませんので、お使いの環境の要件にあわせて、独自のルールを構築してインストールしなければなりません(警告: 既定のポリシーが同梱されていない件について をお読みください) 。

SELinux のポリシーでは、システムに存在するファイルやディレクトリ、ポートやプロセスに対して、アクセスルールを規定するものです。これを実現するために、これらすべてに対してセキュリティコンテキストを定義しています。 SELinux のポリシーが適用されるファイルシステムではラベルが設定されていますので、 ls -Z のように入力して実行すると、そのディレクトリ内に存在するファイルに対して割り当てられているセキュリティコンテキストを表示することができます。 例 40.1: 「ls -Z を使用したセキュリティコンテキスト設定」 では、 SELinux のラベルが設定された openSUSE Leap システムで、 / に対するセキュリティコンテキストの設定を示しています。

例 40.1: ls -Z を使用したセキュリティコンテキスト設定
ls -Z
system_u:object_r:bin_t bin
system_u:object_r:boot_t boot
system_u:object_r:device_t dev
system_u:object_r:etc_t etc
system_u:object_r:home_root_t home
system_u:object_r:lib_t lib
system_u:object_r:lib_t lib64
system_u:object_r:lost_found_t lost+found
system_u:object_r:mnt_t media
system_u:object_r:mnt_t mnt
system_u:object_r:usr_t opt
system_u:object_r:proc_t proc
system_u:object_r:default_t root
system_u:object_r:bin_t sbin
system_u:object_r:security_t selinux
system_u:object_r:var_t srv
system_u:object_r:sysfs_t sys
system_u:object_r:tmp_t tmp
system_u:object_r:usr_t usr
system_u:object_r:var_t var

セキュリティコンテキストで最も重要な箇所は、コンテキストタイプの表示です。これはセキュリティコンテキストの一部で、 _t で終わる名前で示されているものです。これは、 SELinux でどのような種類のオブジェクトアクセスを許可するのかを表わしています。ポリシー内では、どの種類のユーザもしくはどの種類の役割から、この種類のコンテキストにアクセスを許可するのかを設定します。たとえば下記のようなルールがあります:

allow user_t bin_t:file {read execute gettattr};

この例では、コンテキストタイプ user_t が設定されているユーザから、コンテキストタイプ bin_t (ターゲット) が設定されたクラス "file" のオブジェクトに対して、アクセスを許可するようなルールになっています。この際、読み込みと実行、および getattr の権限が与えられています。

使用しようとしている標準ポリシーには、多数のルールが含まれています。より管理をやりやすくするため、ポリシーはモジュールとして分割されることもしばしばあります。このような構造により、システム内の様々なパーツに対して、管理者が保護の ON/OFF を切り替えることができるようになっています。

お使いのシステムにポリシーをコンパイルする際、モジュール型のポリシーだけでなく、お使いのシステムを保護する際のポリシーを 1 つにまとめた一枚岩のポリシーを使用することもできます。一枚岩のポリシーであると管理が非常に難しくなることから、特段の理由がない限り、モジュール型のポリシーを採用しておくことを強くお勧めします。これにより、管理もやりやすくなります。

40.3 SELinux パッケージのインストールと GRUB 2 の変更

すべての SELinux コンポーネントをインストールする場合、最も簡単な方法は YaST を使用することです。下記の手順では、インストール済みの openSUSE Leap で、インストールを行う方法を示しています:

  1. サーバに対して root でログインし、 YaST を起動します。

  2. ソフトウエア › ソフトウエア管理 を選択します。

  3. 表示 › パターン を選択し、 C/C++ 開発 の分類を選択して、 C 言語向けのパッケージをインストールするように選択します。

  4. さらに 表示 › 検索 を選択し、 名前 , キーワード , 概要 が選択されていることを確認してから、 selinux と入力して 検索 を押します。これにより、パッケージの一覧が表示されます。

  5. 検出したすべてのパッケージをインストールするよう選択し、 了解 を押してパッケージをインストールします。

YaST 内でのすべての SELinux パッケージの選択
図 40.1: YaST 内でのすべての SELinux パッケージの選択

SELinux 関連のパッケージをインストールしたら、 GRUB 2 ブートローダの設定変更を行います。 YaST を起動して システム › ブートローダ › カーネルのパラメータ を選択し、下記の内容を オプションのカーネルコマンドラインパラメータ に追加します:

security=selinux selinux=1 enforcing=0

それぞれのオプションの意味は下記のとおりです:

security=selinux

このオプションを指定することにより、 AppArmor ではなく SELinux を使用することを宣言します。

selinux=1

このオプションを指定することにより、 SELinux を有効化します。

enforcing=0

このオプションを設定することにより、 permissive (許容) モードに設定します。このモードでは、 SELinux が完全に動作するものの、ポリシー内に書かれたセキュリティ設定は、実際には強制されなくなります。システムの動作確認を終え、 SELinux の保護を有効化 したい場合は、このオプションを enforcing=1 に設定し、 /etc/selinux/config 内で SELINUX=enforcing を設定してください。

SELinux パッケージをインストールし、 SELinux を GRUB 2 ブートローダ内のパラメータで有効化したら、あとは設定を反映させるため、再起動を行ってください。

40.4 SELinux のポリシー

ポリシーは SELinux で必須の部品です。 openSUSE Leap 15.2 では、既定のポリシーや標準のポリシーは同梱されておりませんので、お使いの環境に合わせてポリシーを構築し、インストールしなければならないことになります。テスト方法や学習方法について、詳しくは SELinux の Reference Policy Project ( https://github.com/SELinuxProject/refpolicy/wiki ) (英語) をお読みください。なお、ポリシーの無い状態では、 SELinux は動作しません。

ポリシーをインストールしたら、ファイルシステムに対するラベル付けを行います。下記のとおり入力して実行してください:

tux > sudo restorecon -Rp /

上記を実行すると、 /sbin/setfiles コマンドを実行して、お使いのシステム内にあるすべてのファイルに対して、ラベルを設定するようになります。このとき、 /etc/selinux/minimum/contexts/files/file_contexts という入力ファイルを使用します。 file_contexts ファイルには、お使いのファイルシステムにできる限りマッチするよう設定する必要があります。正しく設定しておかないと、お使いのシステムを全く起動することができなくなってしまいます。もしもこのような状況になってしまった場合は、 semanage fcontext コマンドで file_contexts 内のレコードを修正し、お使いのサーバ内のファイルシステム構造に対応するよう、設定を行ってください。たとえば下記のようになります:

tux > sudo semanage fcontext -a -t samba_share_t /etc/example_file

上記を実行すると、ファイルタイプの既定値である etc_tsamba_share_t に変更し、下記の内容を file_contexts.local 内に追加することができます:

/etc/example_file    unconfined_u:object_r:samba_share_t:s0

あとは下記のように入力して実行します:

tux > sudo restorecon -v /etc/example_file

これにより、タイプの変更を反映させることができます。

これを行う前に、本章の残りの部分を読んでおくことで、どのようにしてコンテキストタイプがファイルやディレクトリに適用されているのかを完全に知ることができます。なお、作業を始める前に、 file_contexts ファイルのバックアップを忘れずに採取しておいてください。

注記
注記: ユーザ nobody について

semanage を使用すると、 nobody のホームディレクトリに関するメッセージが出力されることがあります。このような場合は、 nobody に対して設定するシェルを、 /sbin/nologin にしてください。あとは nobody の設定を現在のポリシー設定にあわせてください。

もう一度再起動を行うことで、 SELinux が正しく動作するようになります。動作状況を確認したい場合は、 sestatus -v を実行してください。これにより、 例 40.2: 「SELinux が動作していることの確認」 のような出力が現われるはずです。

例 40.2: SELinux が動作していることの確認
tux > sudo sestatus -v
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          permissive
Policy version:                 26
Policy from config file:        minimum

Process contexts:
Current context:                root:staff_r:staff_t
Init context:                   system_u:system_r:init_t
/sbin/mingetty                  system_u:system_r:sysadm_t
/usr/sbin/sshd                  system_u:system_r:sshd_t

File contexts:
Controlling term:               root:object_r:user_devpts_t
/etc/passwd                     system_u:object_r:etc_t
/etc/shadow                     system_u:object_r:shadow_t
/bin/bash                       system_u:object_r:shell_exec_t
/bin/login                      system_u:object_r:login_exec_t
/bin/sh                         system_u:object_r:bin_t -> system_u:object_r:shell_exec_t
/sbin/agetty                    system_u:object_r:getty_exec_t
/sbin/init                      system_u:object_r:init_exec_t
/sbin/mingetty                  system_u:object_r:getty_exec_t
/usr/sbin/sshd                  system_u:object_r:sshd_exec_t
/lib/libc.so.6                  system_u:object_r:lib_t -> system_u:object_r:lib_t
/lib/ld-linux.so.2              system_u:object_r:lib_t -> system_u:object_r:ld_so_t

40.5 SELinux の設定

この時点では既に SELinux システムを完全に動作できていますので、後は設定作業ということになります。現時点では SELinux が動作しているものの、強制 (enforcing) モードにはなっていません。つまり、何をするにしても制限が加わっておらず、強制モードに移行した際に実施される制限がログに記録されるだけです。ログファイルを読むことで、何が阻害されるのかを知ることができるという点で、このモードは有用です。ここでは、最初のテストとして SELinux を強制モードに移行し、サーバを問題なく使用できるかどうかを確認します。これを行うには、 GRUB 2 の設定ファイル内で enforcing=1 を設定し、 /etc/selinux/config 内で SELINUX=enforcing を指定します。設定が終わったらサーバを再起動し、きちんと起動ができるかどうかを確認してください。問題なく動作した場合は、そのままサーバの残りの機能が一通り動作するよう、必要に応じて設定を変更していきます。サーバが起動できない状態になってしまった場合は、 SELinux の強制モードを解除して、サーバの調整作業を行ってください。

サーバの調整作業を行う場合、まずは SELinux のインストールを確認します。既に sestatus -v というコマンドを使用していますので、ここに表示されている現在のモードとプロセス、ファイルコンテキストをそれぞれ確認します。あとは下記のように実行して、利用可能な可否設定を確認します:

tux > sudo semanage boolean -l

この可否設定の一覧を表示することで、ポリシーへのアクセスも同時に検証することができます。 例40.3「可否設定の一覧表示とポリシーアクセスの確認」 には、このコマンドの出力例が示されています:

例 40.3: 可否設定の一覧表示とポリシーアクセスの確認
tux > sudo semanage boolean -l
SELinux boolean                          Description
ftp_home_dir                   -> off   ftp_home_dir
mozilla_read_content           -> off   mozilla_read_content
spamassassin_can_network       -> off   spamassassin_can_network
httpd_can_network_relay        -> off   httpd_can_network_relay
openvpn_enable_homedirs        -> off   openvpn_enable_homedirs
gpg_agent_env_file             -> off   gpg_agent_env_file
allow_httpd_awstats_script_anon_write -> off   allow_httpd_awstats_script_anon_write
httpd_can_network_connect_db   -> off   httpd_can_network_connect_db
allow_ftpd_full_access         -> off   allow_ftpd_full_access
samba_domain_controller        -> off   samba_domain_controller
httpd_enable_cgi               -> off   httpd_enable_cgi
virt_use_nfs                   -> off   virt_use_nfs

この時点で有用なコマンドがもう 1 つあります。それは下記のとおりです:

tux > sudo semanage fcontext -l

上記は、ポリシーによって提供される既定のファイルコンテキスト設定を表示することができます (詳しくは 例 40.4: 「ファイルのコンテキスト情報の取得」 をご覧ください) 。

例 40.4: ファイルのコンテキスト情報の取得
tux > sudo semanage fcontext -l
/var/run/usb(/.*)?                                 all files          system_u:object_r:hotplug_var_run_t
/var/run/utmp                                      regular file       system_u:object_r:initrc_var_run_t
/var/run/vbe.*                                     regular file       system_u:object_r:hald_var_run_t
/var/run/vmnat.*                                   socket             system_u:object_r:vmware_var_run_t
/var/run/vmware.*                                  all files          system_u:object_r:vmware_var_run_t
/var/run/watchdog\.pid                             regular file       system_u:object_r:watchdog_var_run_t
/var/run/winbindd(/.*)?                            all files          system_u:object_r:winbind_var_run_t
/var/run/wnn-unix(/.*)                             all files          system_u:object_r:canna_var_run_t
/var/run/wpa_supplicant(/.*)?                      all files          system_u:object_r:NetworkManager_var_run_t
/var/run/wpa_supplicant-global                     socket             system_u:object_r:NetworkManager_var_run_t
/var/run/xdmctl(/.*)?                              all files          system_u:object_r:xdm_var_run_t
/var/run/yiff-[0-9]+\.pid                          regular file       system_u:object_r:soundd_var_run_t

40.6 SELinux の管理

ここまでの作業で SELinux を動作させることができましたので、次は設定作業に移ります。 SELinux では、プロセスやユーザがどのファイルやディレクトリ、ポートなどにアクセスできるのかを、正確に定義するための追加のルールセットを使用します。ルールセットの設定を行うにあたって、 SELinux はそれぞれのファイルやディレクトリ、プロセスやポートに対してコンテキストを設定し、それをセキュリティラベルとして使用します。セキュリティラベルは、それらをどのように扱うべきかを示しているもので、 SELinux のポリシー側から指定が行われます。既定では、ポリシーは全てのアクセスを拒否するように設定されていますので、お使いのシステムが何らかの動作を必要とする場合、管理者はルールを作成してポリシー内に配置する必要があります。

40.6.1 セキュリティコンテキストの表示

上述のとおり、ファイルやディレクトリ、ポートなどに対してラベルを設定することができます。ラベル内では様々なコンテキストを使用します。管理者が日々の作業を実施できるようにするためには、コンテキストタイプについて最も知識を持っておく必要があります。様々なコマンドに用意された -Z オプションを使用することで、現在のコンテキスト設定を表示することができるようになります。 例 40.5: 「ルートディレクトリ内でのディレクトリ向け既定コンテキスト」 には、ルートディレクトリ内でのコンテキスト設定の例を示しています。

例 40.5: ルートディレクトリ内でのディレクトリ向け既定コンテキスト
tux > sudo ls -Z
dr-xr-xr-x. root root system_u:object_r:bin_t:s0       bin
dr-xr-xr-x. root root system_u:object_r:boot_t:s0      boot
drwxr-xr-x. root root system_u:object_r:cgroup_t:s0    cgroup
drwxr-xr-x+ root root unconfined_u:object_r:default_t:s0 data
drwxr-xr-x. root root system_u:object_r:device_t:s0    dev
drwxr-xr-x. root root system_u:object_r:etc_t:s0       etc
drwxr-xr-x. root root system_u:object_r:home_root_t:s0 home
dr-xr-xr-x. root root system_u:object_r:lib_t:s0       lib
dr-xr-xr-x. root root system_u:object_r:lib_t:s0       lib64
drwx------. root root system_u:object_r:lost_found_t:s0 lost+found
drwxr-xr-x. root root system_u:object_r:mnt_t:s0       media
drwxr-xr-x. root root system_u:object_r:autofs_t:s0    misc
drwxr-xr-x. root root system_u:object_r:mnt_t:s0       mnt
drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 mnt2
drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 mounts
drwxr-xr-x. root root system_u:object_r:autofs_t:s0    net
drwxr-xr-x. root root system_u:object_r:usr_t:s0       opt
dr-xr-xr-x. root root system_u:object_r:proc_t:s0      proc
drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 repo
dr-xr-x---. root root system_u:object_r:admin_home_t:s0 root
dr-xr-xr-x. root root system_u:object_r:bin_t:s0       sbin
drwxr-xr-x. root root system_u:object_r:security_t:s0  selinux
drwxr-xr-x. root root system_u:object_r:var_t:s0       srv
-rw-r--r--. root root unconfined_u:object_r:swapfile_t:s0 swapfile
drwxr-xr-x. root root system_u:object_r:sysfs_t:s0     sys
drwxrwxrwt. root root system_u:object_r:tmp_t:s0       tmp
-rw-r--r--. root root unconfined_u:object_r:etc_runtime_t:s0 tmp2.tar
-rw-r--r--. root root unconfined_u:object_r:etc_runtime_t:s0 tmp.tar
drwxr-xr-x. root root system_u:object_r:usr_t:s0       usr
drwxr-xr-x. root root system_u:object_r:var_t:s0       var

上述の一覧に書かれているとおり、全てのディレクトリに対してコンテキストが設定されていることがわかります。ここにはユーザと役割、タイプがそれぞれ示されています。残る s0 はマルチレベルセキュリティ環境でのセキュリティレベルを示すもので、ここでは説明していません。このような環境では s0 が設定されていることを確認してください。コンテキストの種類は、そのディレクトリ内でどのような種類の動作を許可するのかを表わしています。たとえば /root ディレクトリには admin_home_t というコンテキストタイプが割り当てられ、 /home ディレクトリには admin_home_t というコンテキストタイプが割り当てられています。 SELinux のポリシーでは、これらのコンテキストタイプに対して様々な種類のアクセスが定義されています。

セキュリティラベルはファイルに対して割り当てられるだけでなく、ポートやプロセスなどにも割り当てられます。 例 40.6: 「ps Zaux によるプロセス向け SELinux 設定の表示」 では、サーバ内のプロセスに対するコンテキスト設定の表示例を示しています。

例 40.6: ps Zaux によるプロセス向け SELinux 設定の表示
tux > sudo ps Zaux
LABEL                           USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
system_u:system_r:init_t        root         1  0.0  0.0  10640   808 ?        Ss   05:31   0:00 init [5]
system_u:system_r:kernel_t      root         2  0.0  0.0      0     0 ?        S    05:31   0:00 [kthreadd]
system_u:system_r:kernel_t      root         3  0.0  0.0      0     0 ?        S    05:31   0:00 [ksoftirqd/0]
system_u:system_r:kernel_t      root         6  0.0  0.0      0     0 ?        S    05:31   0:00 [migration/0]
system_u:system_r:kernel_t      root         7  0.0  0.0      0     0 ?        S    05:31   0:00 [watchdog/0]
system_u:system_r:sysadm_t      root      2344  0.0  0.0  27640   852 ?        Ss   05:32   0:00 /usr/sbin/mcelog --daemon --config-file /etc/mcelog/mcelog.conf
system_u:system_r:sshd_t        root      3245  0.0  0.0  69300  1492 ?        Ss   05:32   0:00 /usr/sbin/sshd -o PidFile=/var/run/sshd.init.pid
system_u:system_r:cupsd_t       root      3265  0.0  0.0  68176  2852 ?        Ss   05:32   0:00 /usr/sbin/cupsd
system_u:system_r:nscd_t        root      3267  0.0  0.0 772876  1380 ?        Ssl  05:32   0:00 /usr/sbin/nscd
system_u:system_r:postfix_master_t root   3334  0.0  0.0  38320  2424 ?        Ss   05:32   0:00 /usr/lib/postfix/master
system_u:system_r:postfix_qmgr_t postfix  3358  0.0  0.0  40216  2252 ?        S    05:32   0:00 qmgr -l -t fifo -u
system_u:system_r:crond_t       root      3415  0.0  0.0  14900   800 ?        Ss   05:32   0:00 /usr/sbin/cron
system_u:system_r:fsdaemon_t    root      3437  0.0  0.0  16468  1040 ?        S    05:32   0:00 /usr/sbin/smartd
system_u:system_r:sysadm_t      root      3441  0.0  0.0  66916  2152 ?        Ss   05:32   0:00 login -- root
system_u:system_r:sysadm_t      root      3442  0.0  0.0   4596   800 tty2     Ss+  05:32   0:00 /sbin/mingetty tty2

40.6.2 SELinux モードの選択

SELinux では、 3 種類のモードを使用します:

強制 (Enforcing):

こちらが既定のモードです。 SELinux では、ポリシー内のルールに従ってサーバを保護します。合わせて SELinux では、監査ログ内に動作状況を記録します。

許容 (Permissive):

このモードはトラブルシューティングで有用な仕組みです。許容モードでは、 SELinux はサーバを保護しませんが、ログファイル内への記録は変わらず行われます。

無効 (Disabled):

このモードでは、 SELinux は完全に無効化され、ログへの記録も行われません。ファイルシステム内に設定されたラベルについては、ファイルシステムから削除されることはありません。

SELinux のモードの設定方法については前述のとおり、システム起動時の GRUB 2 でパラメータを指定して行います。

40.6.3 SELinux のコンテキストタイプの変更

管理者の作業として重要なものとして、 SELinux を正しく動作させるため、ファイルにコンテキストタイプを設定する作業があります。

ファイルが特定のディレクトリ内に作成されると、既定では親のディレクトリのコンテキストタイプを継承します。ですが、ファイルが一方のディレクトリから他方のディレクトリに移動されると、以前の場所でのコンテキストタイプをそのまま適用し続けます。

ファイルに対してコンテキストタイプを設定するには、 semanage fcontext コマンドを使用します。このコマンドでは、新しいコンテキストタイプをポリシー内に書き込むまでは行うものの、実際のコンテキストタイプを即時に反映することは行いません。ポリシー内のコンテキストタイプを実際に反映させるには、設定後に restorecon コマンドを実行します。

semanage fcontext を利用してみる前に、まずは実際にどのようなコンテキストが必要なのかを確認します。具体的には下記のように実行します:

tux > sudo semanage fcontext -l

上記のように実行することで、ポリシー内に設定されている全てのコンテキストを表示することができます。ですが、出力は比較的長いものであるため、実際に必要なコンテキストを知るには少し面倒ではあります (例 40.7: 「既定のファイルコンテキストの表示」 をご覧ください) 。

例 40.7: 既定のファイルコンテキストの表示
tux > sudo semanage fcontext -l | less
SELinux fcontext                                   type               Context

/                                                  directory          system_u:object_r:root_t:s0
/.*                                                all files          system_u:object_r:default_t:s0
/[^/]+                                             regular file       system_u:object_r:etc_runtime_t:s0
/\.autofsck                                        regular file       system_u:object_r:etc_runtime_t:s0
/\.autorelabel                                     regular file       system_u:object_r:etc_runtime_t:s0
/\.journal                                         all files          X:>>None>>
/\.suspended                                       regular file       system_u:object_r:etc_runtime_t:s0
/a?quota\.(user|group)                             regular file       system_u:object_r:quota_db_t:s0
/afs                                               directory          system_u:object_r:mnt_t:s0
/bin                                               directory          system_u:object_r:bin_t:s0
/bin/.*                                            all files          system_u:object_r:bin_t:s0

お使いのサービスでどのようなコンテキスト設定が利用できるのかを確認する方法には、下記の 3 つの方法があります:

  • サービスをインストールして、使用されている既定のコンテキストを判別する方法。この方法が最も簡単であり、推奨される方法です。

  • 特定のサービスに対してマニュアルページを確認します。サービスによっては _selinux で終わる名前のマニュアルページを用意しているものがあり、必要なコンテキスト設定の情報を取得できるものがあります。

    正しいコンテキスト設定を見つけることができたら、 semanage fcontext を利用して設定を適用します。このコマンドでは -t のコンテキストタイプの指定を最初のパラメータとして指定し、その後ろに適用したい先のディレクトリやファイルを指定します。コンテキストを適用したいディレクトリ内に存在する全てに対して、コンテキストを適用したい場合は、ディレクトリ名の箇所に (/.*)? を指定します。これは正規表現で、スラッシュに続いて任意の文字が続くものを表わしています。このほかにも、 semanage のマニュアルページ内の examples セクションには、 semanage を使用する際の様々な便利な例が示されています。正規表現に関する詳しい情報については、 https://ja.wikipedia.org/wiki/%E6%AD%A3%E8%A6%8F%E8%A1%A8%E7%8F%BE をお読みください。

  • お使いのシステムで利用可能な全てのコンテキストタイプを一覧表示する方法:

    tux > sudo seinfo -t

    コマンドそれ自身は非常に多くの情報を出力します。そのため、 grep などのコマンドを併用して、必要な情報だけを取得するようにしてください。

40.6.4 ファイルコンテキストの適用

SELinux のコンテキストを正しく適用するため、下記の手順では semanage fcontextrestorecon を使用して、コンテキストを設定する方法を示しています。ここまでの説明でご存じのとおり、既定のドキュメントルート以外を使用した場合、 Web サーバが動作しません。 SELinux の設定を変更して、正しく動作するようにするまでの手順を示します:

  1. /web ディレクトリを作成し、そのディレクトリに移動します:

    tux > sudo mkdir /web  && cd /web
  2. テキストエディタを利用して、 /web/index.html ファイルを作成し、どんなものでもかまいませんのでコンテンツを作成します。

  3. /etc/apache2/default-server.conf ファイルをエディタで開いて、 DocumentRoot の行を DocumentRoot /web のように変更します。

  4. Apache Web サーバを再起動します:

    tux > sudo systemctl start apache2
  5. ローカルの Web サーバが表示できるかどうか、テストを行います:

    tux > w3m localhost

    Connection refused (接続が拒否されました) のようなメッセージが表示されるかと思います。 Enter を押したあと、 q を押して w3m を終了します。

  6. Apache Web サーバ既定の ドキュメントルート に対して、コンテキストタイプを表示します。このディレクトリは /srv/www/htdocs になっています。このディレクトリに対しては、 httpd_sys_content_t が設定されているはずです:

    tux > sudo ls -Z /srv/www
  7. ポリシー内に新しいコンテキストを設定します。下記のとおり入力して Enter を押します:

    tux > sudo semanage fcontext -a -f "" -t httpd_sys_content_t '/web(/.*) ?'
  8. 新しいコンテキストタイプを適用します:

    tux > sudo restorecon /web
  9. /web ディレクトリ内のファイルのコンテキスト情報を表示します。/web ディレクトリには正しく設定されているものの、そのディレクトリ内のファイルには設定されていないはずです:

    tux > sudo ls -Z /web
  10. 今度は新しいコンテキストを、 /web ディレクトリ以下の全てに対して再帰的に適用します。これでファイルにも新しいコンテキストが適用されるようになります:

    tux > sudo restorecon -R /web
  11. Web サーバを再起動します:

    tux > sudo systemctl restart apache2

    これで /web ディレクトリ内のコンテンツについても、問題なくアクセスできるようになっているはずです。

40.6.5 SELinux ポリシーの設定

ポリシーの動作を変更する際、最も簡単なものは可否設定 (boolean) です。可否設定はオンとオフを切り替えることのできる項目で、ポリシー内で変更することのできるものです。利用可能な設定の一覧を取得するには、下記のように入力して実行します:

tux > sudo semanage boolean -l

上記を実行すると、可否設定の長い一覧と共に、それぞれの可否設定に対する短い説明文が表示されます。必要な可否設定を見つけることができたら、あとは setsebool -P を利用して、設定作業を行います。このコマンドの後ろには可否設定の名前を指定します。このとき、 setsebool-P というオプションを指定していることに注目してください。このオプションは、ディスク上にあるポリシーファイル内に設定を書き込むためのもので、システムを再起動しても設定を残すように設定するための唯一の方法でもあります。

下記の手順では、可否設定の変更例を示しています:

  1. まずは FTP サーバに関連する可否設定を一覧表示します:

    tux > sudo semanage boolean -l | grep ftp
  2. 可否設定をオフにします:

    tux > sudo setsebool allow_ftpd_anon_write off

    なお、変更を書き込むのにそれほど時間はかかりません。設定を書き込んだら、本当にオフになっているのかを確認します:

    tux > sudo semanage boolean -l|grep ftpd_anon
  3. あとはサーバを再起動します。

  4. 再起動後、 allow_ftpd_anon_write の設定がオンに戻っていることを確認します。これは、ポリシーがファイルには書き込まれなかったためです。

  5. 再度可否設定を切り替えて、今度はポリシーファイルにも書き込みます:

    tux > sudo setsebool -P allow_ftpd_anon_write

40.6.6 SELinux モジュールの使用

既定では、 SELinux はモジュール型のポリシーを使用します。これは、 SELinux の機能が単一の巨大なポリシーとして作られているのではなく、多数の小さいモジュールとして構成されていることを意味しています。それぞれのモジュールには、それぞれ対応する SELinux の設定パートがあります。このような SELinux の仕組みにより、サードパーティのベンダがサービスを提供する場合でも、自身のサービスを SELinux に対応できるようにすることができます。 SELinux のモジュールの一覧を取得するには、 semodule -l コマンドを実行します。このコマンドは、 SELinux で使用されている全てのモジュールと、そのバージョン番号を表示します。

管理者の権限を使用すると、モジュールを個別にオンもしくはオフにすることができます。これは SELinux の一部の機能のみを無効化したい場合や、全てのサービスを SELinux で保護する必要がない場合に便利な仕組みです。特に openSUSE Leap では、 SELinux ポリシーを完全にサポートしているわけではないので、全てのモジュールをいったんオフに設定して、必要なサービスにのみ SELinux の保護を適用したほうが都合がよいことがあります。 SELinux のモジュールをオフにしたい場合は、下記のように入力して実行します:

tux > sudo semodule -d モジュール名

オンに戻したい場合は、下記のように入力して実行します:

tux > sudo semodule -e モジュール名

ポリシーモジュールファイル内の内容を変更するには、まずは変更点を新しいポリシーモジュールファイルにコンパイルする必要があります。これを行うには、 selinux-policy-devel パッケージをインストールしたあと、 audit2allow コマンドで作成したファイルのあるディレクトリ内で、下記のように入力して実行します:

tux > make -f /usr/share/selinux/devel/Makefile

make の処理が完了したあとは、 semodule -i を使用することで、モジュールを手作業でシステムに読み込むことができるようになります。

40.7 トラブルシューティング

既定では、 SELinux が何らかの理由で動作しない場合、ログメッセージが /var/log/audit/audit.log ファイル内に記録されます。ただし、このファイルに書き込みを行うには、 auditd サービスを動作させて置かなければなりません。 /var/log/audit ディレクトリ内に何もファイルが存在しない場合は、下記のように入力して実行し、 auditd サービスを開始してください:

tux > sudo systemctl start auditd

また、システムの起動時に開始するように設定したい場合は、下記のように入力して実行します:

tux > sudo systemctl enable auditd

例 40.8: 「/etc/audit/audit.log の例」 には、 /var/log/audit/audit.log の内容の出力例があります:

例 40.8: /etc/audit/audit.log の例
type=DAEMON_START msg=audit(1348173810.874:6248): auditd start, ver=1.7.7 format=raw kernel=3.0.13-0.27-default auid=0 pid=4235 subj=system_u:system_r:auditd_t res=success
type=AVC msg=audit(1348173901.081:292): avc:  denied  { write } for  pid=3426 comm="smartd" name="smartmontools" dev=sda6 ino=581743 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=dir
type=AVC msg=audit(1348173901.081:293): avc:  denied  { remove_name } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state~" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=dir
type=AVC msg=audit(1348173901.081:294): avc:  denied  { unlink } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state~" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.081:295): avc:  denied  { rename } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582373 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.081:296): avc:  denied  { add_name } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state~" scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=dir
type=AVC msg=audit(1348173901.081:297): avc:  denied  { create } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.081:298): avc:  denied  { write open } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.081:299): avc:  denied  { getattr } for  pid=3426 comm="smartd" path="/var/lib/smartmontools/smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.309:300): avc:  denied  { append } for  pid=1316

はじめて audit.log をお読みになる方にとっては、少しわかりにくいと感じることでしょう。しかしながら、読み方がわかればそれほど難しくはありません。各行はそれぞれセクションに分割することができます。たとえば末尾の行の意味は下記のようになります:

type=AVC :

それぞれの SELinux 関連の監査ログ行には、 type=AVC という種類判別用の記述が書き込まれます。

msg=audit(1348173901.309:300) :

これはタイムスタンプを意味しています。ただし、エポック秒と呼ばれる、 1970 年 1 月 1 日からの経過秒数で書かれています。整数部分については、 date -d コマンドで日時に変換することができます:

tux > date -d @1348173901
2012年  9月 21日 金曜日 05:45:01 JST
avc: denied { append } :

拒否された処理の内容を示しています。この場合、システムはデータをファイルに追記する処理が拒否されたことを表わしています。監査ログファイル内では、ファイルを開いたり属性を取得したりなど、様々な処理が記録されることになります。

for pid=1316 :

その処理を実施したコマンドもしくはプロセスのプロセス ID です。

comm="rsyslogd" :

その PID に結びつけられたコマンドを表わしています。

name="smartmontools" :

処理を実行しようとしたアプリケーションの名前を表わしています。

dev=sda6 ino=582296 :

対象となるファイルが存在するブロックデバイス名と inode 番号です。

scontext=system_u:system_r:syslogd_t :

ソースコンテキストと呼ばれ、処理を実行しようとした側のコンテキストを表わしています。

tclass=file :

処理内容の分類名を表わしています。

audit.log 内の各イベントの意味を自分自身で解釈する以外の方法もあります。それは、 audit2allow というコマンドです。このコマンドは、わかりにくい /var/log/audit/audit.log 内のメッセージを分析するための支援を行うソフトウエアです。下記に示す 3 種類の形態が用意されています。 1 つめは audit2allow -w -a のような実行形態で、より読みやすい形式で監査情報を表示することができます。 audit2allow -w -a は、既定では audit.log ファイルを読み込みます。 audit.log ファイル内の特定のメッセージのみを分析したい場合は、一時ファイルにコピーして下記のように入力して実行してください:

tux > sudo audit2allow -w -i ファイル名
例 40.9: 監査メッセージの分析
tux > sudo audit2allow -w -i testfile
type=AVC msg=audit(1348173901.309:300): avc:  denied  { append } for  pid=1316
comm="rsyslogd" name="acpid" dev=sda6 ino=582296
scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:apmd_log_t tclass=file
これは下記の理由によって発生しています:

タイプ強制 (Type Enforcement; TE) の許可ルールが存在しないためです。

このアクセスを許可するような読み込みモジュールを生成するには、下記のように入力して実行します:

tux > sudo audit2allow

アクセスを拒否したルールを見つけたい場合は、 audit2allow -a と入力して実行し、 audit.log ファイル内に記録された全てのメッセージから、対応する強制ルールを表示することができるほか、 audit2allow -i ファイル名 のように入力して実行することで、指定したファイル内に保存されているメッセージに対する強制ルールを表示することもできます。

例 40.10: アクセス拒否内容の表示
tux > sudo audit2allow -i testfile
#============= syslogd_t ==============
allow syslogd_t apmd_log_t:file append;

mymodule という名前の SELinux モジュールを作成し、以前は拒否されていたアクセスを許可するように設定したい場合は、下記のように入力して実行します:

tux > sudo audit2allow -a -R -M mymodule

audit.log に記録されている全てのイベントに対して、同様のことを行いたい場合は、パラメータに -a -M を追加します。また、特定のファイル内のメッセージに対してのみ実施したい場合は、下記のように -i -M を追加します:

例 40.11: 以前に拒否されたアクションを許可するためのポリシー作成
tux > sudo audit2allow -i testfile -M example
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i example.pp

audit2allow コマンドの出力にもあるとおり、この後に semodule -i コマンドの後ろにモジュール名指定して、実行します。このとき、モジュール名は audit2allow で指定した名前となります (上記の例では example.pp です) 。

このページを印刷