CentOS7でのSELinuxの概要–パート2:ファイルとプロセス
序章
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_tタイプに属していることがわかります。 /etc
ディレクトリ。 仮に、タイプはファイルの一種の「グループ」または属性と考えることができます。これは、ファイルを分類する方法です。
また、一部のファイルが他のタイプに属している可能性があることもわかります。 locale.conf
locale_tタイプです。 ここにリストされているすべてのファイルのユーザーとグループの所有者が同じである場合でも、それらのタイプは異なる可能性があります。
別の例として、ユーザーのホームディレクトリのタイプコンテキストを確認してみましょう。
- 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コンテンツのファイルコンテキストは
-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が実行されているのと同じドメインです。 ファイルであり、
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
それのためのコマンド。 The --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
The html
内のディレクトリ /var/www/
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
このコンテキストの変更は、 --preserver=context
の節 cp
指図。
ファイルまたはディレクトリが移動されると、元のコンテキストが保持されます。 次のコマンドでは、 /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
ルートの下。 また、というフォルダを作成します html
下 www
.
- mkdir -p /www/html
実行すると ls -Z
コマンドを実行すると、これらのディレクトリが
- 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/
コピーされたファイルのコンテキストは
ここで編集します 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
ファイルの正しいコンテキストを知っている必要があります。 the --type
flagは、ターゲットのコンテキストを指定します。 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
...
index.htmlファイルのコンテキストを恒久的に変更するには /www/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
その下のディレクトリと index.html
下のファイル /www/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
The 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プロセスの置き換えであり、
- 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 ドメイン内で実行されているプロセスは短期間のものであり、バイナリ実行可能ファイルを呼び出します /usr/sbin/vsftpd
、ftpd_exec_tのタイプコンテキストがあります。 バイナリ実行可能ファイルが起動すると、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デーモンの例を取り上げて、 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には、制限のないドメイン内で実行されるプロセスもあります。 ご想像のとおり、制限のないプロセスは、システム内のすべてのタイプのアクセス権を持ちます。 それでも、このフルアクセスは任意ではありません。フルアクセスはSELinuxポリシーでも指定されています。
制限されていないプロセスドメインの例は、unconfined_tです。 これは、ログインしているユーザーがデフォルトでプロセスを実行するのと同じドメインです。 以降のセクションでは、ユーザーとプロセスドメインへのアクセスについて説明します。
結論
本日、ここでいくつかの非常に重要なSELinuxの概念について説明しました。 ファイルとプロセスのコンテキストの管理は、SELinuxの実装を成功させるための中心です。 このシリーズの次の最後の部分で見るように、パズルのもう1つのピースが残っています。SELinuxユーザーです。