前書き

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

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

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

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

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

まず、4つのユーザーアカウントを作成して、SELinuxの機能を説明します。

  • 一般ユーザー

  • 切り替えユーザー

  • ゲストユーザー

  • 制限ユーザー

現在、* 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デーモンのようなプロセスまたはアプリケーションは、SELinuxを起動したユーザーのコンテキストで実行されます。 したがって、ルートユーザーの下で実行されている不正なアプリケーションによってシステムが侵害された場合、ルートはすべてのファイルに対するすべての権限を持っているため、アプリは何でも実行できます。

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

SELinux _contexts_および_domains_の意味を理解することから、チュートリアルのこの部分の説明を始めます。

セキュリティの最初の部分では、Linuxシステムの各エンティティに_label_を付けます。 ラベルは、他のファイルまたはプロセス属性(所有者、グループ、作成日など)と同様です。リソースの_context_を示しています。 それでは、コンテキストとは何ですか? 簡単に言えば、コンテキストとは、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_u * SELinuxユーザーにマップされます。 このマッピングは、SELinuxポリシーによって行われます。

2番目の部分はSELinux _role_を指定します。これは* object_r *です。 SELinuxの役割を磨くには、最初のSELinuxの記事を振り返ってください。

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

  • 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 *は、_multilevel security_またはMLSに関連しています。 基本的に、これはSELinuxセキュリティポリシーを実施する別の方法であり、この部分はリソース(_s0 *)の_sensitivity_を示しています。 感度とカテゴリについては後で簡単に説明します。 SELinuxのほとんどの一般的なセットアップでは、最初の3つのセキュリティコンテキストがより重要です。

SELinuxプロセスコンテキスト

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

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

service httpd start
service vsftpd start

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

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 *ドメイン内で実行されていることがわかります。

では、プロセスのためにドメインは何をしているのでしょうか? プロセス内で実行するコンテキストを提供します。 _confines_それはプロセスの周りのバブルのようなものです。 プロセスにできることとできないことをプロセスに伝えます。 この制限により、各プロセスドメインは特定の種類のファイルのみに作用し、それ以上のことはできません。

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

命名規則

先に進む前に、SELinuxの命名規則に関する注意事項を示します。 SELinuxユーザーの接尾辞は「_u」、ロールの接尾辞は「_r」、タイプ(ファイルの場合)またはドメイン(プロセスの場合)の接尾辞は「_t」です。

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

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

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

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

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

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

  • プロセスが特定のドメインのものである場合

  • そして、アクセスしようとしているリソースオブジェクトは、特定のクラスとタイプのものです

  • 次に、アクセスを許可します

  • それ以外の場合はアクセスを拒否します

これがどのように機能するかを見るために、CentOS 7システムで実行されている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 *になります。

-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 *のタイプコンテキストを持つターゲットリソースに関心があります。 出力は次のようになります。

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

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

image:https://assets.digitalocean.com/articles/SELinuxCentOS7/2.jpg [正しいSELiunux設定でWebページにアクセス]

_
+サーバーのセットアップ方法によっては、サーバー外部からの着信HTTPトラフィックを許可するために、IPTablesファイアウォールでポート80を有効にする必要があります。 ここでは、IPTablesでポートを有効にする詳細については説明しません。 いくつかの優れたDigitalOceanがありますhttps://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-iptables-on-ubuntu-14-04 [記事]使える。
_

ここまでは順調ですね。 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の「Testing 123」ページが表示される場合があります。

image:https://assets.digitalocean.com/articles/SELinuxCentOS7/3.jpg [SELinux設定が正しくないWebページへのアクセス]

ここで何が起きているのでしょうか? 明らかに一部のアクセスは現在拒否されていますが、誰のアクセスですか? 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_b」という別のプロセスを生成する「proc_a」というプロセスがある場合、SELinuxポリシーで特に指定されていない限り、生成されたプロセスは「proc_a」と同じドメインで実行されます。

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

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

ls -Z /var/www

`+ / var / www / `内の ` html `ディレクトリには* httpd_sys_content_t *タイプのコンテキストがあります。 前に見たように、その中の ` 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

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

SELinux in Action:ファイルコンテキストエラーのテスト

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

mkdir -p /www/html

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

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 *になります。 それが親ディレクトリのコンテキストです。

`+ 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」エラー(またはデフォルトの「Testing 123」ページ)が表示されます。

コピー操作中に `+ 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

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

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

ドメイン移行

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

_Domain transition_は、プロセスがコンテキストをドメイン間で変更する方法です。 それを理解するために、contexta_tのコンテキスト内で実行されるproc_aというプロセスがあるとします。 ドメインの移行により、proc_aはapp_xと呼ばれるアプリケーション(プログラムまたは実行可能スクリプト)を実行し、別のプロセスを_spawn_できます。 この新しいプロセスはproc_bと呼ばれ、contextb_tドメイン内で実行されます。 したがって、contexta_tはapp_xを介してcontextb_tに_transitioning_なります。 app_x実行可能ファイルは、contextb_tへの_entrypoint_として機能しています。 以下にフローを示します。

image:https://assets.digitalocean.com/articles/SELinuxCentOS7/4.jpg [SELinuxドメインの移行]

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

次に、systemdプロセスを検討します。 これは、すべてのプロセスの祖先です。 これはSystem V initプロセスの置き換えであり、* init_t *のコンテキスト内で実行されます。 :

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つの厳格なルールが適用されます。

  • ソースドメインの親プロセスには、両方のドメインの間にあるアプリケーションの実行権限が必要です(これは_entrypoint_です)。

  • アプリケーションのファイルコンテキストは、ターゲットドメインの_entrypoint_として識別される必要があります。

  • 元のドメインがターゲットドメインに移行できるようにする必要があります。

上記のvsftpdデーモンの例を使用して、異なるスイッチで `+ sesearch +`コマンドを実行して、デーモンがこれら3つのルールに準拠しているかどうかを確認します。

最初に、ソースドメイン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には、制限のないドメイン内で実行されるプロセスもあります。 ご想像のとおり、制限のないプロセスには、システム内のすべてのタイプのアクセス権があります。 それでも、このフルアクセスはarbitrary意的ではありません。フルアクセスはSELinuxポリシーでも指定されています。

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

結論

今日は、ここで非常に重要なSELinuxの概念をいくつか取り上げました。 ファイルおよびプロセスコンテキストの管理は、SELinux実装の成功の中心です。 次とhttps://www.digitalocean.com/community/tutorials/an-introduction-to-selinux-on-centos-7-part-3-users [このシリーズの最後の部分]で見るように、残りのパズルのピース:SELinuxユーザー。