RHEL で SELinux セキュリティを効果的に管理する方法

はじめに

この実験（Lab）では、RHEL における SELinux セキュリティの管理に関する実践的な経験を積みます。SELinux の強制モードを一時的および永続的に変更する方法、カスタム SELinux ファイルコンテキストを使用して Apache を設定する方法を学びます。また、この実験（Lab）では、ブール値を使用してユーザーホームディレクトリの SELinux ポリシーを調整する方法、Apache Web サーバーおよびカスタム Web コンテンツの SELinux 拒否に関するトラブルシューティングと解決のための実践的な手順についても説明します。

SELinux 施行モードの変更

このステップでは、SELinux モードを一時的および永続的に管理する方法を学びます。SELinux（Security-Enhanced Linux）は、Linux カーネルに必須アクセス制御（MAC）を提供するセキュリティメカニズムです。プロセス、ファイル、およびその他のシステムリソースへのアクセス権を定義します。

SELinux は、主に次の 3 つのモードで動作します。

Enforcing（強制）: SELinux ポリシーが適用されます。ポリシーによって拒否されたアクセスはブロックされ、ログに記録されます。これはデフォルトであり、最も安全なモードです。
Permissive（許可）: SELinux ポリシーは適用されません。ポリシーによって拒否されたアクセスはログに記録されますが、ブロックされません。このモードは、トラブルシューティングや新しいポリシーのテストに役立ちます。
Disabled（無効）: SELinux はオフになっています。ポリシーはロードも適用もされません。このモードは、通常、本番システムには推奨されません。

コマンドラインツールを使用し、設定ファイルを変更して、SELinux モードを変更する練習を行います。

まず、現在の SELinux 強制モードを確認しましょう。

現在の SELinux 強制モードを確認します。

getenforceコマンドを使用して、現在の SELinux モードをすばやく確認できます。
```
getenforce
```
出力としてEnforcingが表示され、SELinux が現在ポリシーを適用していることを示します。
```
Enforcing
```
SELinux モードを一時的にpermissiveに変更します。

setenforceコマンドを使用すると、実行時に SELinux モードを変更できます。値0はモードをpermissiveに設定し、1はenforcingに設定します。この変更は一時的であり、再起動後も保持されません。
```
sudo setenforce 0
```
次に、getenforceをもう一度使用して変更を確認します。
```
getenforce
```
出力はPermissiveになるはずです。
```
Permissive
```
SELinux モードを一時的にenforcingに戻します。

一時的な変更を元に戻すには、setenforce 1を使用します。
```
sudo setenforce 1
```
もう一度モードを確認します。
```
getenforce
```
出力は再びEnforcingになるはずです。
```
Enforcing
```
デフォルトの SELinux モードを永続的にpermissiveに変更します。

再起動後も SELinux モードの変更を永続的に行うには、/etc/selinux/configファイルを変更する必要があります。このファイルは、システムのデフォルトの SELinux モードを定義します。

nanoを使用して設定ファイルを開きます。
```
sudo nano /etc/selinux/config
```
nanoエディタ内で、SELINUX=で始まる行を見つけ、その値をenforcingからpermissiveに変更します。
```
## This file controls the state of SELinux on the system.
## SELINUX= can take one of these three values:
##     enforcing - SELinux security policy is enforced.
##     permissive - SELinux prints warnings instead of enforcing.
##     disabled - No SELinux policy is loaded.
SELINUX=permissive
## SELINUXTYPE= can take one of these three values:
##     targeted - Targeted processes are protected,
##                for the majority of users.
##     minimum - Modification of targeted policy
##               uses current settings and adds to it.
##     mls - Multi Level Security protection.
SELINUXTYPE=targeted
```
Ctrl+Xを押して終了し、次にYを押して保存を確認し、Enterを押して同じファイルに書き込みます。

ファイルを保存した後、grepを使用して設定ファイル内の変更を確認できます。
```
grep '^SELINUX' /etc/selinux/config
```
出力にはSELINUX=permissiveが表示されるはずです。
```
SELINUX=permissive
SELINUXTYPE=targeted
```
重要事項: /etc/selinux/configを変更しても、アクティブな SELinux モードがすぐに変更されるわけではありません。これは、次のシステム再起動後に適用されるモードを設定するだけです。現在のアクティブなモードを確認するには、引き続きgetenforceを使用する必要があります。
```
getenforce
```
システムがまだ再起動されていないため、引き続きEnforcingが表示されるはずです。
```
Enforcing
```

設定ファイルでデフォルトの SELinux モードをenforcingに戻します。

次に、永続的なモードをenforcingに戻しましょう。これは、SELinux の推奨される最も安全な設定です。

設定ファイルをもう一度開きます。

sudo nano /etc/selinux/config

SELINUX=パラメータをenforcingに戻します。

## This file controls the state of SELinux on the system.
## SELINUX= can take one of these three values:
##     enforcing - SELinux security policy is enforced.
##     permissive - SELinux prints warnings instead of enforcing.
##     disabled - No SELinux policy is loaded.
SELINUX=enforcing
## SELINUXTYPE= can take one of these three values:
##     targeted - Targeted processes are protected,
##                for the majority of users.
##     minimum - Modification of targeted policy
##               uses current settings and adds to it.
##     mls - Multi Level Security protection.
SELINUXTYPE=targeted

ファイルを保存して終了します（Ctrl+X、Y、Enter）。

設定ファイル内の変更を確認します。

grep '^SELINUX' /etc/selinux/config

出力には、SELINUX=enforcingが表示されるはずです。

SELINUX=enforcing
SELINUXTYPE=targeted

この時点で、システムの有効な SELinux モードはまだEnforcingであり（ステップ 4 の後に再起動していない場合）、永続的な設定もEnforcingです。

カスタム SELinux ファイルコンテキストを使用した Apache の構成

このステップでは、Apache を非標準ディレクトリから Web コンテンツを提供し、その SELinux ファイルコンテキストを管理するように設定する方法を学びます。デフォルトでは、SELinux ポリシーは Apache（httpd）を特定のディレクトリ（主に/var/www/html）からのみファイルを提供するように制限しています。Web コンテンツを別の場所に配置すると、ファイルシステムのアクセス許可が正しくても、SELinux は Apache がそれにアクセスするのを防ぎます。ここで SELinux ファイルコンテキストが重要になります。

SELinux ファイルコンテキストは、ファイルのセキュリティ属性を定義するファイルまたはディレクトリに適用されるラベルです。Apache がカスタムの場所からコンテンツを提供するには、その場所とその内容が正しい SELinux コンテキスト（通常はhttpd_sys_content_t）を持っている必要があります。semanage fcontextを使用して永続的なルールを定義し、restoreconを使用してそれを適用します。

まず、Apache HTTP サーバーをインストールする必要があります。

Apache HTTP サーバーをインストールします。

dnfパッケージマネージャーを使用して、httpdパッケージをインストールします。
```
sudo dnf install -y httpd
```
httpdパッケージとその依存関係が正常にインストールされたことを示す出力が表示されるはずです。
Web コンテンツ用のカスタムディレクトリとindex.htmlファイルを作成します。

/customという名前の新しいディレクトリを作成し、その中に単純なindex.htmlファイルを配置します。これが、非標準の Web ドキュメントルートになります。
```
sudo mkdir /custom
echo 'This is custom web content.' | sudo tee /custom/index.html
```
index.htmlファイルの内容を確認します。
```
cat /custom/index.html
```
```
This is custom web content.
```
新しいドキュメントルートを使用するように Apache を設定します。

Apache のメイン設定ファイルは/etc/httpd/conf/httpd.confです。このファイルを編集して、デフォルトの/var/www/htmlではなく、新しい/customディレクトリを指すように Apache を設定する必要があります。

nanoを使用して設定ファイルを開きます。
```
sudo nano /etc/httpd/conf/httpd.conf
```
エディタ内で、DocumentRoot "/var/www/html"と<Directory "/var/www/html">という行を見つけます。/var/www/htmlのすべての出現箇所を/customに変更します。

変更後の関連セクションは次のようになります。
```
#
## DocumentRoot: The directory out of which you will serve your
## documents. By default, all requests are taken from this directory, but
## symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "/custom"

#
## Relax access to content within /var/www.
#
<Directory "/custom">
    AllowOverride None
    ## Allow open access:
    Require all granted
</Directory>
```
ファイルを保存して終了します（Ctrl+X、Y、Enter）。
Apache Web サービスを開始して有効にします。

設定を変更した後、httpdサービスを開始する必要があります。コンテナ環境にいるため、systemctlは利用できません。httpdを直接開始します。
```
sudo /usr/sbin/httpd -DFOREGROUND &
```
&記号は、コマンドをバックグラウンドで実行し、ターミナルを使い続けることができます。Apache が起動していることを示す次のような出力が表示されるはずです。
```
[1] 5094
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using fe80::216:3eff:fe00:63b%eth0. Set the 'ServerName' directive globally to suppress this message
```
注: サーバーの完全修飾ドメイン名に関する警告メッセージは、この実験（Lab）環境では正常であり、安全に無視できます。

Apache が実行されていることを確認するには、httpdプロセスを確認できます。
```
ps aux | grep httpd
```
いくつかのhttpdプロセスが実行されているはずです。
```
root        ... /usr/sbin/httpd -DFOREGROUND
apache      ... /usr/sbin/httpd -DFOREGROUND
...output omitted...
```
Web ページへのアクセスを試みます。

次に、curlを使用して Web ページにアクセスしてみます。同じマシン上にあるため、localhostを使用できます。
```
curl http://localhost/index.html
```
注: この特定の環境では、root_tコンテキストでも Web ページにアクセスできる場合があります。これは、SELinux が適用されている間、root_tコンテキストが予想よりも広いアクセス許可を持っている可能性があることを示しています。ただし、セキュリティのベストプラクティスと適切な SELinux 設定のために、Web コンテンツは引き続き適切なhttpd_sys_content_tコンテキストを使用する必要があります。
```
This is custom web content.
```
カスタムディレクトリの現在の SELinux コンテキストを確認します。

ls -Zコマンドを使用して、/customディレクトリとindex.htmlファイルの SELinux コンテキストを表示します。
```
ls -Zd /custom /custom/index.html
```
それらがroot_tコンテキストを持っていることに気付くでしょう。これは、Apache Web コンテンツに推奨されるコンテキストではありません。
```
system_u:object_r:root_t:s0 /custom
system_u:object_r:root_t:s0 /custom/index.html
```
これをデフォルトの Apache ドキュメントルートと比較します。
```
ls -Zd /var/www/html
```
/var/www/htmlがhttpd_sys_content_tコンテキストを持っていることがわかります。これは、カスタムディレクトリに適用する必要があるコンテキストです。
```
system_u:object_r:httpd_sys_content_t:s0 /var/www/html
```
/customの永続的な SELinux ファイルコンテキストルールを定義します。

semanage fcontextコマンドは、SELinux ファイルコンテキストマッピングルールを管理するために使用されます。-aオプションは新しいルールを追加し、-tはターゲットタイプを指定し、正規表現'/custom(/.*)?'は/customディレクトリ自体と、その中のすべてのファイルとサブディレクトリに一致します。
```
sudo semanage fcontext -a -t httpd_sys_content_t '/custom(/.*)?'
```
このコマンドは、SELinux ポリシーにルールを追加しますが、既存のファイルのコンテキストをすぐに変更するわけではありません。
新しい SELinux コンテキストをファイルに適用します。

restoreconコマンドは、ファイルとディレクトリの SELinux コンテキストを、ポリシーで定義されているデフォルト値に復元するために使用されます。-Rオプションは変更を再帰的に適用し、-vは詳細出力を提供します。
```
sudo restorecon -Rv /custom
```
/customと/custom/index.htmlのコンテキストが再ラベル付けされたことを示す出力が表示されるはずです。
```
Relabeled /custom from system_u:object_r:root_t:s0 to system_u:object_r:httpd_sys_content_t:s0
Relabeled /custom/index.html from system_u:object_r:root_t:s0 to system_u:object_r:httpd_sys_content_t:s0
```
ls -Zを使用して、コンテキストをもう一度確認します。
```
ls -Zd /custom /custom/index.html
```
これで、httpd_sys_content_tコンテキストを持っているはずです。
```
system_u:object_r:httpd_sys_content_t:s0 /custom
system_u:object_r:httpd_sys_content_t:s0 /custom/index.html
```
Web ページに再度アクセスします。

SELinux コンテキストが正しく設定されたので、curlを使用して Web ページに再度アクセスしてみます。
```
curl http://localhost/index.html
```
これで、index.htmlファイルの内容が表示されるはずです。
```
This is custom web content.
```
最後に、Apache HTTP サーバープロセスを停止します。
```
sudo pkill httpd
```
httpdプロセスが実行されていないことを確認します。
```
ps aux | grep httpd
```
grepプロセス自体のみが表示されるはずです。
```
labex     ... grep httpd
```

ブール値を使用したユーザーホームディレクトリの SELinux ポリシー調整

このステップでは、ブール値を使用して SELinux ポリシーを調整し、Apache がユーザーのホームディレクトリから Web コンテンツを提供できるようにする方法を学びます。デフォルトでは、SELinux は、セキュリティ上の理由から、Apache などのサービスがユーザーのホームディレクトリ内のファイルにアクセスすることを防ぎます。ただし、個人用 Web ページなど、この機能が必要な特定のシナリオがあります。

SELinux ブール値は、管理者が複雑なカスタムポリシーを作成することなく、SELinux ポリシーの動作を変更できる true/false 設定です。特定のセキュリティ機能を有効または無効にする柔軟な方法を提供します。たとえば、Apache がユーザーのホームディレクトリにアクセスできるようにするためのブール値があります。

Apache のユーザーディレクトリ機能を有効にします。

Apache には、ユーザーが自分のホームディレクトリ内のpublic_htmlディレクトリ（例：~/public_html）から Web コンテンツを公開できるようにするmod_userdirと呼ばれるモジュールがあります。この機能は通常、/etc/httpd/conf.d/userdir.confで設定されます。デフォルトでは、この機能は無効になっていることがよくあります。

nanoを使用して設定ファイルを開きます。
```
sudo nano /etc/httpd/conf.d/userdir.conf
```
エディタ内で、UserDirに関連する行が見つかります。UserDirを無効にする行をコメントアウトし、public_htmlに対して有効にする行をコメント解除する必要があります。

変更前：
```
UserDir disabled
#UserDir public_html
```
変更後：
```
#UserDir disabled
UserDir public_html
```
ファイルを保存して終了します（Ctrl+X、Y、Enter）。
ホームディレクトリにpublic_htmlディレクトリとindex.htmlファイルを作成します。

public_htmlディレクトリと、その中にあるindex.htmlファイルを作成します。これが、個人用 Web コンテンツが配置される場所です。
```
mkdir ~/public_html
echo 'This is labex user content.' > ~/public_html/index.html
```
index.htmlファイルの内容を確認します。
```
cat ~/public_html/index.html
```
```
This is labex user content.
```
情報: ~/public_htmlディレクトリを作成したとき、user_home_tと~/（ホームディレクトリ）がhome_dir_tSELinux コンテキストで自動的に設定されました。Apache Web サーバープロセス（httpd_t）は、デフォルトでは SELinux ポリシーにより、user_home_tまたはhome_dir_tというラベルの付いたファイルを読み取ることができません。
Apache Web サービスを開始します。

httpdサービスを開始します。このコンテナ環境ではsystemctlは利用できないため、httpdを直接開始します。
```
sudo /usr/sbin/httpd -DFOREGROUND &
```
サーバーの完全修飾ドメイン名に関する警告メッセージが表示される場合がありますが、この実験環境では安全に無視できます。

Apache が実行されていることを確認します。
```
ps aux | grep httpd
```
```
root        ... /usr/sbin/httpd -DFOREGROUND
apache      ... /usr/sbin/httpd -DFOREGROUND
...output omitted...
```
ユーザーの Web ページへのアクセスを試み、SELinux 拒否を観察します。

次に、curlを使用して個人用 Web ページにアクセスしてみます。ユーザーディレクトリの URL は、通常、http://localhost/~username/の形式に従います。
```
curl http://localhost/~labex/index.html
```
SELinux が原因で Apache がまだコンテンツにアクセスできないことを示す「Forbidden」エラーが表示される可能性があります。
```
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /~labex/index.html
on this server.<br />
</p>
</body></html>
```
httpdのホームディレクトリに関連する SELinux ブール値を確認します。

getseboolコマンドを使用すると、SELinux ブール値の現在の状態を表示できます。grepを使用して出力をフィルタリングし、httpdとホームディレクトリに関連するブール値を見つけることができます。
```
sudo getsebool -a | grep httpd | grep home
```
httpd_enable_homedirs --> offが表示され、このブール値が現在無効になっていることを示します。
```
httpd_enable_homedirs --> off
```
httpd_enable_homedirsブール値を永続的に有効にします。

setseboolコマンドは、SELinux ブール値の状態を変更するために使用されます。-Pオプションは、再起動後も変更を永続的にします。
```
sudo setsebool -P httpd_enable_homedirs on
```
ブール値が現在onになっていることを確認します。
```
sudo getsebool -a | grep httpd | grep home
```
```
httpd_enable_homedirs --> on
```
ホームディレクトリの正しいファイルアクセス許可を設定します。

SELinux ブール値が有効になっている場合でも、Apache は、ホームディレクトリとpublic_htmlディレクトリにアクセスするために、適切なファイルシステムアクセス許可が必要です。デフォルトでは、ユーザーのホームディレクトリは Apache ユーザーからアクセスできません。
```
chmod 711 ~
chmod 755 ~/public_html
chmod 644 ~/public_html/index.html
```
Web ページに再度アクセスします。

httpd_enable_homedirsブール値が有効になり、ファイルアクセス許可が正しく設定されたので、curlを使用して個人用 Web ページに再度アクセスしてみます。
```
curl http://localhost/~labex/index.html
```
これで、index.htmlファイルの内容が表示されるはずです。
```
This is labex user content.
```
トラブルシューティング: ブール値を有効にしてファイルアクセス許可を設定した後でもアクセスに関する問題が発生する場合は、これは Linux セキュリティの多層的な性質を示しています。一部の環境では、次のような追加の要因が考えられます。
- /etc/httpd/conf.d/userdir.confの Apache 設定ディレクティブ
- ホームディレクトリ構造の SELinux ファイルコンテキスト
- 追加の Apache モジュールまたはセキュリティ設定
に対処する必要がある場合があります。重要な学習ポイントは、SELinux ブール値が従来のファイルアクセス許可およびアプリケーション固有の設定とどのように連携して機能するかを理解することです。
Apache HTTP サーバープロセスを停止します。

最後に、Apache HTTP サーバープロセスを停止します。
```
sudo pkill httpd
```
httpdプロセスが実行されていないことを確認します。
```
ps aux | grep httpd
```
```
labex     ... grep httpd
```

Apache Web サーバーの SELinux 拒否に関するトラブルシューティング

このステップでは、SELinux セキュリティ拒否を特定し、トラブルシューティングする方法を学びます。具体的には、Apache Web サーバーが正しく機能するのを妨げる可能性のある問題に焦点を当てます。SELinux が操作をブロックすると、「Access Vector Cache」（AVC）拒否メッセージが記録されます。これらのメッセージは、操作が失敗した理由と、それを解決する方法を理解するために不可欠です。

auditd（Linux Auditing System デーモン）やsealertなどのツールを使用して、これらの拒否メッセージを分析します。auditdは、SELinux 拒否を含むシステムコールとイベントを収集し、/var/log/audit/audit.logに保存します。sealertツールは、setroubleshoot-serverパッケージの一部であり、これらのログを解析し、SELinux 拒否に関する人間が読める説明と推奨される解決策を提供できます。

まず、auditdとsetroubleshoot-serverがインストールされていることを確認する必要があります。

auditdとsetroubleshoot-serverをインストールします。
```
sudo dnf install -y audit setroubleshoot-server
```
これらのパッケージが正常にインストールされたことを示す出力が表示されるはずです。
Apache Web サーバーを起動し、問題のあるファイルを作成します。

SELinux 拒否をシミュレートするために、誤った SELinux コンテキストを持つファイルを作成し、Apache で提供しようとします。

まず、Apache が実行されていることを確認します。
```
sudo /usr/sbin/httpd -DFOREGROUND &
```
次に、新しいディレクトリと、その中にindex.htmlファイルを作成します。今回は、このファイルに意図的に誤った SELinux コンテキストを設定して、拒否をトリガーします。
```
sudo mkdir /testweb
echo 'This is a test page.' | sudo tee /testweb/index.html
```
デフォルトでは、/testweb/index.htmlはroot_tコンテキストを持っている可能性があります。確認しましょう。
```
ls -Z /testweb/index.html
```
```
system_u:object_r:root_t:s0 /testweb/index.html
```
次に、/testwebから提供するように Apache を設定しましょう。/etc/httpd/conf/httpd.confを開きます。
```
sudo nano /etc/httpd/conf/httpd.conf
```
DocumentRootと<Directory>ディレクティブを/testwebに変更します。
```
DocumentRoot "/testweb"

<Directory "/testweb">
    AllowOverride None
    Require all granted
</Directory>
```
保存して終了します（Ctrl+X、Y、Enter）。

設定の変更を適用するために、Apache を再起動します。コンテナ内にいるため、古いプロセスを kill して新しいプロセスを開始する必要があります。
```
sudo pkill httpd
sudo /usr/sbin/httpd -DFOREGROUND &
```
Web ページへのアクセスを試みます。

curlを使用して Web ページにアクセスしてみます。
```
curl http://localhost/index.html
```
重要なお知らせ: この環境では、ステップ 2 で観察したように、root_tコンテキストでも Web ページにアクセスできる場合があります。これは、SELinux が適用されている間、root_tコンテキストが、より制限の厳しいコンテキストよりも広いアクセス許可を持っていることを示しています。
```
This is a test page.
```
ただし、SELinux のトラブルシューティング技術を学ぶために、拒否があったかのように進めます。より制限の厳しい SELinux 環境または異なるポリシー設定では、不適切なコンテキストを持つファイルにアクセスすると、実際に拒否が生成されます。
ausearchを使用した SELinux 拒否の調査について学びます。

ausearchコマンドは、監査ログを照会するために使用されます。今日発生した SELinux AVC 拒否（-m AVC）を検索できます（-ts today）。
```
sudo ausearch -m AVC -ts today
```
注: Web ページは環境内でアクセス可能であったため、この特定のテストに関連する最近の AVC 拒否は表示されない場合があります。ただし、このコマンドは、拒否があった場合、詳細な監査ログエントリを出力します。一般的な拒否シナリオでは、httpdと/testweb/index.htmlに関連するエントリを探します。

一般的な AVC 拒否エントリは次のようになります。
```
----
time->...
type=AVC msg=audit(...): avc:  denied  { getattr } for  pid=... comm="httpd" path="/testweb/index.html" dev="overlay" ino=... scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=0
...output omitted...
```
AVC 拒否の主要な部分は次のとおりです。
- denied { getattr }: 拒否された操作（ファイルの属性の取得）。
- comm="httpd": 拒否されたプロセス（Apache HTTP サーバー）。
- path="/testweb/index.html": アクセスされたファイル。
- scontext=system_u:system_r:httpd_t:s0: ソースの SELinux コンテキスト（Apache）。
- tcontext=system_u:object_r:root_t:s0: ターゲットの SELinux コンテキスト（index.htmlファイル）。
- tclass=file: ターゲットのタイプ（ファイル）。
この出力は、httpd_t（Apache）が、default_tコンテキストを持つファイルへのgetattrアクセスを拒否されたことを明確に示しています。
SELinux 分析にsealertを使用することについて学びます。

sealertは、監査ログを解析し、よりユーザーフレンドリーな情報を提供できます。最近のすべての拒否を分析するにはsealert -aを実行するか、/var/log/messagesのsetroubleshootメッセージから特定の UUID がある場合はsealert -l <UUID>を使用できます。
```
sudo sealert -a /var/log/audit/audit.log
```
注: この環境では実際の拒否が発生していないため、sealertを実行しても、/testwebの例に関連する結果は表示されない場合があります。ただし、SELinux 拒否が発生するシナリオでは、sealertは監査ログを分析し、概要を提示します。

httpd コンテキストの問題に対する一般的なsealert出力は次のようになります。
```
SELinux is preventing /usr/sbin/httpd from getattr access on the file /testweb/index.html.

***** Plugin catchall_labels (83.8 confidence) suggests *******************
If you want to allow httpd to have getattr access on the index.html file
Then you need to change the label on /testweb/index.html
Do ## semanage fcontext -a -t FILE_TYPE '/testweb/index.html'
where FILE_TYPE is one of the following:
httpd_sys_content_t, httpd_sys_script_exec_t, httpd_unconfined_script_exec_t, ...

***** Plugin httpd_can_network_connect (93.8 confidence) suggests *********
If you want to allow httpd to connect to the network (for example, to a database)
Then you must set the httpd_can_network_connect boolean to on.
Do ## setsebool -P httpd_can_network_connect on
...output omitted...
```
sealertの出力は、実際の拒否シナリオで非常に役立ちます。問題が明確に示され、semanage fcontext -a -t FILE_TYPE '/testweb/index.html'でラベルを変更し、httpd_sys_content_tを適切なFILE_TYPEとしてリストするなど、解決策が提案されます。

最後に、Apache HTTP サーバープロセスを停止します。
```
sudo pkill httpd
```
httpdプロセスが実行されていないことを確認します。
```
ps aux | grep httpd
```
```
labex     ... grep httpd
```

カスタム Web コンテンツの SELinux 問題解決

この最終ステップでは、前のトラブルシューティング演習から得られた知識を適用して、Apache が/testwebディレクトリからコンテンツを提供することを妨げていた SELinux 拒否を解決します。semanage fcontextを使用して、カスタム Web コンテンツの正しい SELinux コンテキストを定義し、restoreconを使用してそれを適用します。

このプロセスは、SELinux コンテキストがどのように機能し、Apache などのサービスに対してそれらを正しく構成する方法の理解を強化します。

Apache が実行されており、構成が整っていることを確認します。

まず、Apache が/testwebから提供するように構成されており、実行されていることを確認します。前のステップで Apache を停止した場合は、再度起動します。
```
sudo /usr/sbin/httpd -DFOREGROUND &
```
/etc/httpd/conf/httpd.confのDocumentRootが/testwebに設定されていることを確認します。そうでない場合は、前のステップで行ったように変更します。
```
grep "DocumentRoot" /etc/httpd/conf/httpd.conf
```
```
DocumentRoot "/testweb"
```
また、/testweb/index.htmlが存在し、root_tコンテキストを持っていることを確認します。
```
ls -Z /testweb/index.html
```
```
system_u:object_r:root_t:s0 /testweb/index.html
```
Web ページにアクセスして、現在の動作を確認します。

現在、Web ページがroot_tコンテキストでアクセス可能であることを確認しましょう。
```
curl http://localhost/index.html
```
これまで見てきたように、root_tコンテキストでもページにアクセスできます。
```
This is a test page.
```
これは機能しますが、Web コンテンツの適切な SELinux 構成をデモンストレーションします。
/testwebの正しい SELinux ファイルコンテキストを定義します。

Apache が提供する Web コンテンツの正しい SELinux コンテキストはhttpd_sys_content_tです。semanage fcontextを使用して、永続的なルールを追加する必要があります。
```
sudo semanage fcontext -a -t httpd_sys_content_t '/testweb(/.*)?'
```
このコマンドは、/testweb内のすべてのファイルまたはディレクトリ（/testweb自体を含む）にhttpd_sys_content_tをラベル付けするように SELinux に指示します。
新しい SELinux コンテキストをファイルに適用します。

ルールを定義した後、restoreconを使用して既存のファイルに適用する必要があります。
```
sudo restorecon -Rv /testweb
```
コンテキストが再ラベル付けされたことを示す出力が表示されるはずです。
```
Relabeled /testweb from system_u:object_r:root_t:s0 to system_u:object_r:httpd_sys_content_t:s0
Relabeled /testweb/index.html from system_u:object_r:root_t:s0 to system_u:object_r:httpd_sys_content_t:s0
```
ls -Zを使用して、コンテキストを再度確認します。
```
ls -Z /testweb/index.html
```
```
system_u:object_r:httpd_sys_content_t:s0 /testweb/index.html
```
Web ページに再度アクセスして、適切な構成を確認します。

SELinux コンテキストがベストプラクティスに従って正しく適用されたので、curlを使用して Web ページに再度アクセスしてみます。
```
curl http://localhost/index.html
```
コンテンツは引き続きアクセス可能であり、推奨される SELinux コンテキストで適切に構成されるようになりました。
```
This is a test page.
```
これは、この環境ではroot_tコンテキストが機能する可能性がある一方で、適切なhttpd_sys_content_tコンテキストを使用すると、SELinux のベストプラクティスに従い、さまざまなセキュリティ構成間での互換性が確保されることを示しています。

最後に、Apache HTTP サーバープロセスを停止します。
```
sudo pkill httpd
```
httpdプロセスが実行されていないことを確認します。
```
ps aux | grep httpd
```
```
labex     ... grep httpd
```

まとめ

この実験では、RHEL で SELinux セキュリティを管理する方法を学びました。まず、setenforceを使用して一時的に、/etc/selinux/configを修正して永続的に、SELinux の施行モードを変更する方法を理解し、実践しました。これには、getenforceを使用した現在のモードの検証、および Enforcing、Permissive、Disabled モードの影響の理解が含まれていました。

さらに、semanage fcontextとrestoreconを使用して、カスタム SELinux ファイルコンテキストで Apache を構成し、Web サーバーの適切な動作を確保する実践的な経験を積みました。また、setseboolを使用して特定の SELinux ブール値を有効にすることにより、ユーザーホームディレクトリの SELinux ポリシーを調整する方法も学びました。最後に、この実験では、SELinux 拒否に関する基本的なトラブルシューティング技術をカバーしました。具体的には、Apache Web サーバーについて、ausearchとaudit2allowを使用して監査ログを分析し、カスタム Web コンテンツへのアクセス問題を特定して解決しました。

RHEL での SELinux セキュリティ管理