CentOS7でのSELinuxの概要–パート2：ファイルとプロセス

提供：Dev Guides
移動先:案内、検索

序章

SELinuxシリーズの最初のパートでは、SELinuxを有効または無効にする方法と、ブール値を使用して一部のポリシー設定を変更する方法を説明しました。 この第2部では、ファイルとプロセスのセキュリティコンテキストについて説明します。

前のチュートリアルからメモリを更新するために、ファイルセキュリティコンテキストは type であり、プロセスセキュリティコンテキストはdomainです。

注このチュートリアルに示されているコマンド、パッケージ、およびファイルは、CentOS7でテストされています。 概念は他のディストリビューションでも同じです。

このチュートリアルでは、特に明記されていない限り、rootユーザーとしてコマンドを実行します。 rootアカウントにアクセスできず、sudo権限を持つ別のアカウントを使用する場合は、コマンドの前にsudoキーワードを付ける必要があります。

テストユーザーアカウントの作成

まず、SELinuxの機能を示すために4つのユーザーアカウントを作成しましょう。

  • 通常のユーザー
  • Switcheduser
  • ゲストユーザー
  • 制限付きユーザー

現在、rootユーザーである必要があります。 次のコマンドを実行して、regularuserアカウントを追加しましょう。 

useradd -c "Regular User" regularuser

次に、passwdコマンドを実行して、パスワードを変更します。 

passwd regularuser

出力では、新しいパスワードの入力を求められます。 提供されると、アカウントはログインの準備が整います。 

Changing password for user regularuser.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

他のアカウントも作成しましょう： 

useradd -c "Switched User" switcheduser
passwd switcheduser

useradd -c "Guest User" guestuser
passwd guestuser 

useradd -c "Restricted Role User" restricteduser
passwd restricteduser

プロセスとファイルのためのSELinux

SELinuxの目的は、プロセスがLinux環境でファイルにアクセスする方法を保護することです。 SELinuxがない場合、Apacheデーモンのようなプロセスまたはアプリケーションは、それを開始したユーザーのコンテキストで実行されます。 したがって、rootユーザーの下で実行されている不正なアプリケーションによってシステムが侵害された場合、rootにはすべてのファイルに対する包括的な権限があるため、アプリは必要な処理を実行できます。

SELinuxはさらに一歩進んで、このリスクを排除しようとします。 SELinuxを使用すると、プロセスまたはアプリケーションは、機能するために必要な権限のみを持ち、それ以上は何も持ちません。 アプリケーションのSELinuxポリシーは、アクセスする必要のあるファイルのタイプと、遷移できるプロセスを決定します。 SELinuxポリシーはアプリ開発者によって作成され、それをサポートするLinuxディストリビューションに同梱されています。 ポリシーは基本的に、プロセスとユーザーをそれらの権限にマップする一連のルールです。

チュートリアルのこの部分の説明は、SELinuxコンテキストおよびドメインの意味を理解することから始めます。

セキュリティの最初の部分では、Linuxシステムの各エンティティにlabelを配置します。 ラベルは、他のファイルまたはプロセス属性（所有者、グループ、作成日など）と同様です。 リソースのコンテキストが表示されます。 では、コンテキストとは何ですか？ 簡単に言うと、コンテキストは、SELinuxがアクセス制御の決定を行うのに役立つセキュリティ関連情報のコレクションです。 Linuxシステムのすべてにセキュリティコンテキストを設定できます。ユーザーアカウント、ファイル、ディレクトリ、デーモン、またはポートにすべてセキュリティコンテキストを設定できます。 ただし、セキュリティコンテキストは、オブジェクトの種類ごとに異なる意味を持ちます。 ​

SELinuxファイルコンテキスト

SELinuxファイルのコンテキストを理解することから始めましょう。 /etcディレクトリに対する通常のls-lコマンドの出力を見てみましょう。 

ls -l /etc/*.conf

これにより、おなじみの出力が表示されます。 

... 
-rw-r--r--. 1 root root    19 Aug 19 21:42 /etc/locale.conf
-rw-r--r--. 1 root root   662 Jul 31  2013 /etc/logrotate.conf
-rw-r--r--. 1 root root  5171 Jun 10 07:35 /etc/man_db.conf
-rw-r--r--. 1 root root   936 Jun 10 05:59 /etc/mke2fs.conf
...

簡単ですよね？ 次に、-Zフラグを追加しましょう。 

ls -Z /etc/*.conf

これで、ユーザーとグループの所有権の後に追加の情報列ができました。 

...
-rw-r--r--. root root system_u:object_r:locale_t:s0    /etc/locale.conf
-rw-r--r--. root root system_u:object_r:etc_t:s0       /etc/logrotate.conf
-rw-r--r--. root root system_u:object_r:etc_t:s0       /etc/man_db.conf
-rw-r--r--. root root system_u:object_r:etc_t:s0       /etc/mke2fs.conf
...

この列には、ファイルのセキュリティコンテキストが表示されます。 この情報を利用できる場合、ファイルにはセキュリティコンテキストがラベルされていると言われます。 セキュリティコンテキストの1つを詳しく見てみましょう。 

-rw-r--r--. root     root  system_u:object_r:etc_t:s0       /etc/logrotate.conf

セキュリティコンテキストは次の部分です。 

system_u:object_r:etc_t:s0

4つの部分があり、セキュリティコンテキストの各部分はコロン（:)で区切られています。 最初の部分は、ファイルのSELinux userコンテキストです。 SELinuxユーザーについては後で説明しますが、今のところ、system_uであることがわかります。 各LinuxユーザーアカウントはSELinuxユーザーにマップされ、この場合、ファイルを所有するrootユーザーはsystem_uSELinuxユーザーにマップされます。 このマッピングはSELinuxポリシーによって行われます。

2番目の部分は、SELinux role 、つまりobject_rを指定します。 SELinuxの役割をブラッシュアップするには、最初のSELinuxの記事を振り返ってください。

ここで最も重要なのは、3番目の部分であるetc_tとしてここにリストされているファイルのtypeです。 これは、ファイルまたはディレクトリが属するtypeを定義する部分です。 ほとんどのファイルが/etcディレクトリのetc_tタイプに属していることがわかります。 仮に、タイプはファイルの一種の「グループ」または属性と考えることができます。これは、ファイルを分類する方法です。

また、 locale_tタイプのlocale.confなど、他のタイプに属するファイルもあります。 ここにリストされているすべてのファイルのユーザーとグループの所有者が同じである場合でも、それらのタイプは異なる可能性があります。

別の例として、ユーザーのホームディレクトリのタイプコンテキストを確認してみましょう。 

ls -Z /home

ホームディレクトリのコンテキストタイプは異なります： user_home_dir_t 

drwx------. guestuser      guestuser      unconfined_u:object_r:user_home_dir_t:s0       guestuser
drwx------. root           root           system_u:object_r:lost_found_t:s0 lost+found
drwx------. regularuser    regularuser    unconfined_u:object_r:user_home_dir_t:s0      regularuser
drwx------. restricteduser restricteduser unconfined_u:object_r:user_home_dir_t:s0      restricteduser
drwx------. switcheduser   switcheduser   unconfined_u:object_r:user_home_dir_t:s0      switcheduser
drwx------. sysadmin       sysadmin       unconfined_u:object_r:user_home_dir_t:s0      sysadmin

セキュリティコンテキストの4番目の部分であるs0は、マルチレベルセキュリティまたはMLSと関係があります。 基本的に、これはSELinuxセキュリティポリシーを適用する別の方法であり、この部分はリソースの感度（ s0 ）を示しています。 感度とカテゴリについては後で簡単に説明します。 SELinuxのほとんどのバニラセットアップでは、最初の3つのセキュリティコンテキストがより重要です。

SELinuxプロセスコンテキスト

次に、プロセスのセキュリティコンテキストについて説明します。

ApacheおよびSFTPサービスを開始します。 これらのサービスは、最初のSELinuxチュートリアルでインストールしました。 

service httpd start
service vsftpd start

いくつかのフラグを指定してpsコマンドを実行し、サーバーで実行されているApacheおよびSFTPプロセスを表示できます。 

ps -efZ | grep 'httpd\|vsftpd'

ここでも、SELinuxコンテキストを表示するために-Zフラグが使用されます。 出力には、プロセスを実行しているユーザー、プロセスID、および親プロセスIDが表示されます。 

system_u:system_r:httpd_t:s0         root        7126    1       0 16:50 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:httpd_t:s0            apache      7127    7126    0 16:50 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:httpd_t:s0            apache      7128    7126    0 16:50 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:httpd_t:s0            apache      7129    7126    0 16:50 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:httpd_t:s0            apache      7130    7126    0 16:50 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:httpd_t:s0            apache      7131    7126    0 16:50 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:ftpd_t:s0-s0:c0.c1023 root        7209    1       0 16:54 ?        00:00:00 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 7252 2636  0 16:57 pts/0 00:00:00 grep --color=auto httpd\|vsftpd

セキュリティコンテキストは次の部分です。 

system_u:system_r:httpd_t:s0

セキュリティコンテキストには、ユーザー、役割、ドメイン、機密性の4つの部分があります。 ユーザー、役割、および機密性は、ファイルの同じコンテキストと同じように機能します（前のセクションで説明しました）。 ドメインはプロセスに固有です。

上記の例では、いくつかのプロセスが httpd_t ドメイン内で実行されているのに対し、1つはftpd_tドメイン内で実行されていることがわかります。

では、ドメインはプロセスに対して何をしているのでしょうか？ プロセスに実行するコンテキストを提供します。 それは、がそれを閉じ込めるプロセスの周りのバブルのようなものです。 プロセスに何ができるか、何ができないかを伝えます。 この制限により、各プロセスドメインが特定のタイプのファイルにのみ作用し、それ以上は作用しないようにします。

このモデルを使用すると、プロセスが別の悪意のあるプロセスまたはユーザーによって乗っ取られた場合でも、アクセスできるファイルに損傷を与える可能性があります。 たとえば、vsftpデーモンは、sendmailやsambaなどで使用されるファイルにアクセスできません。 この制限はカーネルレベルから実装されます。SELinuxポリシーがメモリにロードされるときに適用されるため、アクセス制御は必須になります。

命名規則

先に進む前に、SELinuxの命名規則について説明します。 SELinuxユーザーの接尾辞は「_u」、ロールの接尾辞は「_r」、タイプ（ファイルの場合）またはドメイン（プロセスの場合）の接尾辞は「_t」です。

プロセスがリソースにアクセスする方法

これまでのところ、ファイルとプロセスは異なるコンテキストを持つことができ、それらは独自のタイプまたはドメインに制限されていることを確認しました。 では、プロセスはどのように実行されますか？ 実行するには、プロセスはそのファイルにアクセスし、それらに対していくつかのアクション（開く、読み取る、変更、または実行）を実行する必要があります。 また、各プロセスが特定の種類のリソース（ファイル、ディレクトリ、ポートなど）にのみアクセスできることも学びました。

SELinuxは、これらのアクセスルールをポリシーで規定しています。 アクセスルールは、標準のallowステートメント構造に従います。 

allow <domain> <type>:<class> { <permissions> };

ドメインとタイプについてはすでに説明しました。 クラスは、リソースが実際に表すもの（ファイル、ディレクトリ、シンボリックリンク、デバイス、ポート、カーソルなど）を定義します。

この一般的なallowステートメントの意味は次のとおりです。

  • プロセスが特定のドメインのものである場合
  • また、アクセスしようとしているリソースオブジェクトは、特定のクラスとタイプのものです。
  • 次に、アクセスを許可します
  • それ以外の場合はアクセスを拒否します

これがどのように機能するかを確認するために、CentOS7システムで実行されているhttpdデーモンのセキュリティコンテキストについて考えてみましょう。 

system_u:system_r:httpd_t:s0     7126 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     7127 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     7128 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     7129 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     7130 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     7131 ?        00:00:00 httpd

Webサーバーのデフォルトのホームディレクトリは/var/www/htmlです。 そのディレクトリ内にファイルを作成し、そのコンテキストを確認してみましょう。 

touch /var/www/html/index.html
ls -Z /var/www/html/*

Webコンテンツのファイルコンテキストはhttpd_sys_content_t[X68X]になります。 

-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/html/index.html

sesearchコマンドを使用して、httpdデーモンに許可されているアクセスのタイプを確認できます。 

sesearch --allow --source httpd_t --target httpd_sys_content_t --class file

コマンドで使用されるフラグはかなり自明です。ソースドメインはhttpd_tであり、Apacheが実行されているのと同じドメインです。 ファイルであり、httpd_sys_content_t[X106X]のタイプコンテキストを持つターゲットリソースに関心があります。 出力は次のようになります。 

Found 4 semantic av rules:
   allow httpd_t httpd_sys_content_t : file { ioctl read getattr lock open } ;
   allow httpd_t httpd_content_type : file { ioctl read getattr lock open } ;
   allow httpd_t httpd_content_type : file { ioctl read getattr lock open } ;
   allow httpd_t httpdcontent : file { ioctl read write create getattr setattr lock append unlink link rename execute open } ;

最初の行に注意してください。 

allow httpd_t httpd_sys_content_t : file { ioctl read getattr lock open } ;

これは、httpdデーモン（Apache Webサーバー）がhttpd_sys_contentタイプのファイルへのI/O制御、読み取り、属性の取得、ロック、およびオープンアクセスを持っていることを示しています。 この場合、index.htmlファイルは同じタイプです。

さらに一歩進んで、最初にWebページ（/var/www/html/index.html）を変更しましょう。 このコンテンツを含むようにファイルを編集します。 

<html>
    <title>
        This is a test web page
    </title>
    <body>
        <h1>This is a test web page</h1>
    </body>
</html>

次に、/var/www/フォルダーとその内容のアクセス許可を変更し、httpdデーモンを再起動します。 

chmod -R 755 /var/www
service httpd restart

次に、ブラウザからアクセスを試みます。

注サーバーの設定方法によっては、サーバーの外部からの着信HTTPトラフィックを許可するために、IPTablesファイアウォールでポート80を有効にする必要がある場合があります。 ここでは、IPTablesでポートを有効にする方法の詳細については説明しません。 使用できるトピックに関する優れたDigitalOcean記事がいくつかあります。

ここまでは順調ですね。 httpdデーモンは特定のタイプのファイルにアクセスすることを許可されており、ブラウザーを介してアクセスするとそれを確認できます。 次に、ファイルのコンテキストを変更して、状況を少し変えてみましょう。 chconコマンドを使用します。 コマンドの--typeフラグを使用すると、ターゲットリソースの新しいタイプを指定できます。 ここでは、ファイルタイプをvar_tに変更しています。 

chcon --type var_t /var/www/html/index.html

タイプの変更を確認できます。 

ls -Z /var/www/html/

-rwxr-xr-x. root root unconfined_u:object_r:var_t:s0   index.html

次に、Webページにアクセスしようとすると（つまり、 httpdデーモンがファイルを読み取ろうとすると、 Forbidden エラーが発生するか、一般的なCentOSの「Testing123」ページが表示される場合があります。

では、ここで何が起こっているのでしょうか。 明らかに、一部のアクセスは現在拒否されていますが、誰のアクセスですか？ SELinuxに関する限り、Webサーバーは特定のタイプのファイルにのみアクセスすることを許可されており、var_tはそれらのコンテキストの1つではありません。 index.htmlファイルのコンテキストをvar_tに変更したため、Apacheはそれを読み取ることができなくなり、エラーが発生します。

再び動作させるために、restoreconコマンドでファイルタイプを変更しましょう。 -vスイッチは、コンテキストラベルの変更を示します。 

restorecon -v /var/www/html/index.html

restorecon reset /var/www/html/index.html context unconfined_u:object_r:var_t:s0->unconfined_u:object_r:httpd_sys_content_t:s0

ここでページにアクセスしようとすると、「これはテストWebページです」というテキストが再度表示されます。

これは理解するための重要な概念です。ファイルとディレクトリに正しいコンテキストがあることを確認することは、SELinuxが正常に動作していることを確認するために極めて重要です。 このセクションの最後で実際のユースケースを見ていきますが、その前に、さらにいくつかのことについて話しましょう。

ファイルとディレクトリのコンテキスト継承

SELinuxは、「コンテキスト継承」と呼ぶことができるものを強制します。 これが意味するのは、ポリシーで指定されていない限り、プロセスとファイルは親のコンテキストで作成されるということです。

したがって、「proc_a」というプロセスが「proc_b」という別のプロセスを生成する場合、SELinuxポリシーで特に指定されていない限り、生成されたプロセスは「proc_a」と同じドメインで実行されます。

同様に、「some_context_t」タイプのディレクトリがある場合、その下に作成されたファイルまたはディレクトリは、ポリシーで特に指定されていない限り、同じタイプのコンテキストになります。

これを説明するために、/var/www/ディレクトリのコンテキストを確認してみましょう。 

ls -Z /var/www

/var/www/内のhtmlディレクトリには、httpd_sys_content_t[X72X]タイプのコンテキストがあります。 前に見たように、その中のindex.htmlファイルは同じコンテキスト（つまり、親のコンテキスト）を持っています： 

drwxr-xr-x. root root system_u:object_r:httpd_sys_script_exec_t:s0 cgi-bin
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 html

ファイルが別の場所にコピーされる場合、この継承は保持されません。 コピー操作では、コピーされたファイルまたはディレクトリは、ターゲットの場所のタイプコンテキストを想定します。 以下のコードスニペットでは、index.htmlファイル（「httpd_sys_content_t」タイプのコンテキストを含む）を/var/ディレクトリにコピーしています。 

cp /var/www/html/index.html /var/

コピーしたファイルのコンテキストを確認すると、現在の親ディレクトリのコンテキストであるvar_tに変更されていることがわかります。 

ls -Z /var/index.html

-rwxr-xr-x. root root unconfined_u:object_r:var_t:s0   /var/index.html

このコンテキストの変更は、cpコマンドの--preserver=context句によってオーバーライドできます。

ファイルまたはディレクトリが移動されると、元のコンテキストが保持されます。 次のコマンドでは、/var/index.htmlを/etc/ディレクトリに移動しています。 

mv  /var/index.html  /etc/

移動したファイルのコンテキストを確認すると、var_tコンテキストが/etc/ディレクトリに保存されていることがわかります。 

ls -Z /etc/index.html

-rwxr-xr-x. root root unconfined_u:object_r:var_t:s0   /etc/index.html

では、なぜファイルコンテキストにそれほど関心があるのでしょうか。 このコピーアンドムーブの概念が重要なのはなぜですか？ 考えてみてください。おそらく、すべてのWebサーバーのHTMLファイルをルートフォルダーの下の別のディレクトリにコピーすることにしました。 これは、バックアッププロセスを簡素化し、セキュリティを強化するために行いました。ハッカーがWebサイトのファイルの場所を簡単に推測することは望ましくありません。 ディレクトリのアクセス制御を更新し、新しい場所を指すようにWeb構成ファイルを変更し、サービスを再起動しましたが、それでも機能しません。 おそらく、次のトラブルシューティング手順として、ディレクトリとそのファイルのコンテキストを確認できます。 実例として実行してみましょう。

SELinuxの動作：ファイルコンテキストエラーのテスト

まず、ルートの下にwwwという名前のディレクトリを作成しましょう。 また、wwwの下にhtmlというフォルダーを作成します。 

mkdir -p /www/html

ls -Zコマンドを実行すると、これらのディレクトリがdefault_t[X103X]コンテキストで作成されていることがわかります。 

ls -Z /www/

drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 html

次に、/var/www/htmlディレクトリの内容を/www/htmlにコピーします。 

cp /var/www/html/index.html /www/html/

コピーされたファイルのコンテキストはdefault_t[X52X]になります。 これが親ディレクトリのコンテキストです。

ここで、httpd.confファイルを編集して、この新しいディレクトリをWebサイトのルートフォルダとして指定します。 また、このディレクトリのアクセス権を緩和する必要があります。 

vi /etc/httpd/conf/httpd.conf

まず、ドキュメントルートの既存の場所をコメントアウトし、新しいDocumentRootディレクティブを/www/htmlに追加します。 

# DocumentRoot "/var/www/html"

DocumentRoot "/www/html"

また、既存のドキュメントルートのアクセス権セクションをコメントアウトし、新しいセクションを追加します。 

#<Directory "/var/www">
#    AllowOverride None
    # Allow open access:
#    Require all granted
#</Directory>

<Directory "/www">
    AllowOverride None
    # Allow open access:
    Require all granted
</Directory>

cgi-binディレクトリの場所はそのままにしておきます。 ここでは、詳細なApache構成については説明していません。 SELinuxの目的でサイトを機能させたいだけです。

最後に、httpdデーモンを再起動します。 

service httpd restart

サーバーが再起動されると、Webページにアクセスすると、以前に見たのと同じ「403 Forbidden」エラー（またはデフォルトの「Testing123」ページ）が表示されます。

コピー操作中にindex.htmlファイルのコンテキストが変更されたため、エラーが発生しています。 元のコンテキスト（httpd_sys_content_t）に戻す必要があります。

しかし、どうすればそれを行うことができますか？

SELinuxファイルコンテキストの変更と復元

前のコードサンプルでは、ファイルの内容を変更するための2つのコマンドchconとrestoreconを見ました。 chconの実行は一時的な対策です。 これを使用して、アクセス拒否エラーのトラブルシューティングのためにファイルまたはディレクトリのコンテキストを一時的に変更できます。 ただし、この方法は一時的なものです。ファイルシステムのラベルを変更するか、restoreconコマンドを実行すると、ファイルが元のコンテキストに戻ります。

また、chconを実行するには、ファイルの正しいコンテキストを知っている必要があります。 --typeフラグは、ターゲットのコンテキストを指定します。 restoreconはこれを指定する必要はありません。 restoreconを実行すると、ファイルに正しいコンテキストが再適用され、変更が永続的になります。

しかし、ファイルの正しいコンテキストがわからない場合、システムはrestoreconの実行時にどのコンテキストを適用するかをどのように知るのでしょうか？

便利なことに、SELinuxはサーバー内のすべてのファイルまたはディレクトリのコンテキストを「記憶」します。 CentOS 7では、システムにすでに存在するファイルのコンテキストが/etc/selinux/targeted/contexts/files/file_contextsファイルに一覧表示されます。 これは大きなファイルであり、Linuxディストリビューションでサポートされているすべてのアプリケーションに関連付けられているすべてのファイルタイプが一覧表示されます。 新しいディレクトリとファイルのコンテキストは、/etc/selinux/targeted/contexts/files/file_contexts.localファイルに記録されます。 したがって、restoreconコマンドを実行すると、SELinuxはこれら2つのファイルのいずれかから正しいコンテキストを検索し、それをターゲットに適用します。

以下のコードスニペットは、ファイルの1つからの抜粋を示しています。 

cat /etc/selinux/targeted/contexts/files/file_contexts

...
/usr/(.*/)?lib(/.*)?    system_u:object_r:lib_t:s0
/opt/(.*/)?man(/.*)?    system_u:object_r:man_t:s0
/dev/(misc/)?agpgart    -c      system_u:object_r:agp_device_t:s0
/usr/(.*/)?sbin(/.*)?   system_u:object_r:bin_t:s0
/opt/(.*/)?sbin(/.*)?   system_u:object_r:bin_t:s0
/etc/(open)?afs(/.*)?   system_u:object_r:afs_config_t:s0
...

/www/htmlの下のindex.htmlファイルのコンテキストを永続的に変更するには、2段階のプロセスに従う必要があります。

  • まず、semanage fcontextコマンドを実行します。 これにより、新しいコンテキストが/etc/selinux/targeted/contexts/files/file_contexts.localファイルに書き込まれます。 ただし、ファイル自体のラベルは変更されません。 これは両方のディレクトリに対して行います。
semanage fcontext --add --type httpd_sys_content_t "/www(/.*)?"
semanage fcontext --add --type httpd_sys_content_t "/www/html(/.*)?"

確認するために、ファイルコンテキストデータベースを確認できます（file_contexts.localファイルを使用していることに注意してください）。 

cat /etc/selinux/targeted/contexts/files/file_contexts.local

更新されたコンテキストが表示されます。 

# This file is auto-generated by libsemanage
# Do not edit directly.

/www(/.*)?    system_u:object_r:httpd_sys_content_t:s0
/www/html(/.*)?    system_u:object_r:httpd_sys_content_t:s0

次に、restoreconコマンドを実行します。 これにより、前の手順で記録されたものでファイルまたはディレクトリのラベルが変更されます。 

restorecon -Rv /www

これにより、コンテキストが3つのレベルでリセットされます。最上位の/wwwディレクトリ、その下の/www/htmlディレクトリ、および/www/htmlの下のindex.htmlファイルです。 

restorecon reset /www context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:httpd_sys_content_t:s0
restorecon reset /www/html context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:httpd_sys_content_t:s0
restorecon reset /www/html/index.html context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:httpd_sys_content_t:s0

ここでWebページにアクセスしようとすると、機能するはずです。

matchpathconと呼ばれる気の利いたツールがあり、コンテキスト関連の問題のトラブルシューティングに役立ちます。 このコマンドは、リソースの現在のコンテキストを調べて、SELinuxコンテキストデータベースの下にリストされているものと比較します。 異なる場合は、必要な変更を提案します。 /www/html/index.htmlファイルでこれをテストしてみましょう。 コンテキストを検証する-Vフラグを使用します。 

matchpathcon -V /www/html/index.html

matchpathcon出力は、コンテキストが検証されたことを示しているはずです。 

/www/html/index.html verified.

誤ってラベル付けされたファイルの場合、メッセージにはコンテキストがどうあるべきかが示されます。 

/www/html/index.html has context unconfined_u:object_r:default_t:s0, should be system_u:object_r:httpd_sys_content_t:s0

ドメインの移行

これまで、プロセスがファイルシステムリソースにアクセスする方法を見てきました。 ここで、プロセスが他のプロセスにアクセスする方法を確認します。

ドメイン移行は、プロセスがコンテキストをあるドメインから別のドメインに変更する方法です。 それを理解するために、contexta_tのコンテキスト内で実行されているproc_aと呼ばれるプロセスがあるとしましょう。 ドメイン遷移を使用すると、proc_aは、別のプロセスをスポーンするapp_xというアプリケーション（プログラムまたは実行可能スクリプト）を実行できます。 この新しいプロセスはproc_bと呼ばれ、contextb_tドメイン内で実行されている可能性があります。 したがって、事実上、contexta_tはapp_xを介してcontextb_tに遷移されます。 app_x実行可能ファイルは、contextb_tへのエントリポイントとして機能しています。 フローは以下のように説明できます。

ドメイン移行のケースは、SELinuxではかなり一般的です。 サーバーで実行されているvsftpdプロセスについて考えてみましょう。 実行されていない場合は、service vsftpd startコマンドを実行してデーモンを起動できます。

次に、systemdプロセスについて検討します。 これは、すべてのプロセスの祖先です。 これはSystemVinitプロセスの置き換えであり、init_t[X92X]のコンテキスト内で実行されます。 : 

ps -eZ  | grep init

system_u:system_r:init_t:s0         1 ?        00:00:02 systemd
system_u:system_r:mdadm_t:s0      773 ?        00:00:00 iprinit

init_t ドメイン内で実行されているプロセスは短命です。つまり、ftpd_exec_tのタイプコンテキストを持つバイナリ実行可能ファイル/usr/sbin/vsftpdを呼び出します。 バイナリ実行可能ファイルが起動すると、vsftpdデーモン自体になり、ftpd_tドメイン内で実行されます。

ファイルとプロセスのドメインコンテキストを確認できます。 

ls -Z /usr/sbin/vsftpd

私たちに見せて下さい： 

-rwxr-xr-x. root root system_u:object_r:ftpd_exec_t:s0 /usr/sbin/vsftpd

プロセスの確認： 

ps -eZ | grep vsftpd

私たちに見せて下さい： 

system_u:system_r:ftpd_t:s0-s0:c0.c1023 7708 ? 00:00:00 vsftpd

したがって、ここでは、 init_t ドメインで実行されているプロセスが、ftpd_exec_tタイプのバイナリファイルを実行しています。 そのファイルは、ftpd_tドメイン内でデーモンを起動します。

この遷移は、アプリケーションまたはユーザーが制御できるものではありません。 これは、システムの起動時にメモリにロードされるSELinuxポリシーで規定されています。 SELinux以外のサーバーでは、ユーザーはより強力なアカウントに切り替えることでプロセスを開始できます（ユーザーがそうする権利を持っている場合）。 SELinuxでは、このようなアクセスは事前に作成されたポリシーによって制御されます。 そしてそれが、SELinuxが強制アクセス制御を実装していると言われているもう1つの理由です。

ドメインの移行には、次の3つの厳格なルールが適用されます。

  • ソースドメインの親プロセスには、両方のドメインの間にあるアプリケーションの実行権限が必要です（これはエントリポイントです）。
  • アプリケーションのファイルコンテキストは、ターゲットドメインのエントリポイントとして識別される必要があります。
  • 元のドメインは、ターゲットドメインへの移行を許可されている必要があります。

上記のvsftpdデーモンの例を取り上げて、デーモンがこれら3つのルールに準拠しているかどうかを確認するために、さまざまなスイッチでsesearchコマンドを実行してみましょう。

まず、ソースドメインinit_tは、ftpd_exec_tコンテキストを使用してエントリポイントアプリケーションに対する実行権限を持っている必要があります。 したがって、次のコマンドを実行すると、次のようになります。 

sesearch -s init_t -t ftpd_exec_t -c file -p execute -Ad

結果は、init_tドメイン内のプロセスが、ftpd_exec_tコンテキストのファイルを読み取り、属性を取得し、実行し、開くことができることを示しています。 

Found 1 semantic av rules:
   allow init_t ftpd_exec_t : file { read getattr execute open } ;

次に、バイナリファイルがターゲットドメインftpd_tのエントリポイントであるかどうかを確認します。 

sesearch -s ftpd_t -t ftpd_exec_t -c file -p entrypoint -Ad

そして確かにそうです： 

Found 1 semantic av rules:
   allow ftpd_t ftpd_exec_t : file { ioctl read getattr lock execute execute_no_trans entrypoint open } ;

そして最後に、ソースドメインinit_tには、ターゲットドメインftpd_tに移行するためのアクセス許可が必要です。 

sesearch -s init_t -t ftpd_t -c process -p transition -Ad

以下に示すように、ソースドメインにはその権限があります。 

Found 1 semantic av rules:
   allow init_t ftpd_t : process transition ;

制限のないドメイン

ドメインの概念を導入したとき、それをプロセスの周りの架空のバブルと比較しました。これは、プロセスが実行できることと実行できないことを規定するものです。 これがプロセスを制限するものです。

SELinuxには、制限のないドメイン内で実行されるプロセスもあります。 ご想像のとおり、制限のないプロセスは、システム内のすべてのタイプのアクセス権を持ちます。 それでも、このフルアクセスは任意ではありません。フルアクセスはSELinuxポリシーでも指定されています。

制限されていないプロセスドメインの例は、unconfined_tです。 これは、ログインしているユーザーがデフォルトでプロセスを実行するのと同じドメインです。 以降のセクションでは、ユーザーとプロセスドメインへのアクセスについて説明します。

結論

本日、ここでいくつかの非常に重要なSELinuxの概念について説明しました。 ファイルとプロセスのコンテキストの管理は、SELinuxの実装を成功させるための中心です。 このシリーズの次の最後の部分で見るように、パズルのもう1つのピースが残っています。SELinuxユーザーです。

「https://www.finddevguides.com/index.php?title=CentOS7でのSELinuxの概要–パート2：ファイルとプロセス&oldid=107407」から取得
Powered by MediaWiki