11.3. 問題の修正

以下のセクションでは、問題の解決方法を説明します。取り上げるトピックは以下のとおりです。Linux パーミッションのチェック - これは SELinux ルールの前にチェックされます。拒否がログ記録されない場合に SELinux がアクセスを拒否する理由。サービスの man ページ - これにはラベル付けとブール値の情報が含まれます。あるプロセスがシステム全体ではなく permissive で実行することを許可するための permissive ドメイン。拒否メッセージの検索方法および表示方法。拒否の分析。audit2allow によるカスタムポリシーモジュールの作成。

11.3.1. Linux パーミッション

アクセスが拒否されたら、標準 Linux パーミッションをチェックしてください。「1章はじめに」の説明にあるように、ほとんどのオペレーティングシステムでは任意アクセス制御 (DAC) を使ってアクセスを制御しており、ユーザーが所有しているファイルのパーミッションを自分で管理できるようになっています。SELinux ポリシールールは DAC ルールの後にチェックされます。最初に DAC ルールがアクセスを拒否すれば、SELinux ポリシールールは使われません。
アクセスが拒否され、SELinux 拒否がログ記録されていない場合、以下のコマンドを使って標準 Linux パーミッションを表示します。 
~]$ ls -l /var/www/html/index.html
-rw-r----- 1 root root 0 2009-05-07 11:06 index.html
この例では、index.html は root ユーザーとグループが所有しています。root ユーザーには読み取りおよび書き込みパーミッション (-rw) があり、root グループのメンバーには読み取りパーミッション (-r-) があります。それ以外の人にはアクセスがありません (---)。デフォルトでは、これらのパーミッションは httpd によるこのファイルの読み取りを許可しません。この問題を解決するには、chown コマンドで所有者とグループを変更します。このコマンドは、root で実行する必要があります。 
~]# chown apache:apache /var/www/html/index.html
ここでは、httpd を Linux Apache ユーザーとして実行するというデフォルト設定を前提としています。httpd を別のユーザーで実行する場合は、apache:apache をそのユーザーで置き換えます。
Linux パーミッション管理の詳細については、Fedora ドキュメントプロジェクトの「Permissions」のドラフトを参照してください。

11.3.2. サイレント拒否の原因

状況によっては、SELinux がアクセスを拒否した際に AVC 拒否メッセージがログ記録されない場合もあります。アプリケーションやシステムライブラリー機能は、タスクの実行に必要なアクセス以上のものをプローブすることがよくあります。無害なアプリケーションプローブを AVC 拒否で監査ログ記録につけることなく最小の権限を維持するために、ポリシーは dontaudit ルールを使うことで、パーミッションを許可することなくサイレントな AVC 拒否を行うことができます。このルールは、標準ポリシーに共通のものです。dontaudit のマイナス面は、SELinux はアクセスを拒否するものの拒否メッセージがログ記録されないため、トラブルシューティングがより難しくなるという点です。
一時的に dontaudit ルールを無効にしてすべての拒否をログ記録できるようにするには、以下のコマンドを root で実行します。 
~]# semodule -DB
-D オプションは dontaudit ルールを無効にし、-B オプションはポリシーを再構築します。semodule -DB を実行した後、パーミッション問題があったアプリケーションを試します。そのアプリケーションに関連した SELinux 拒否がログ記録されているかどうかをチェックします。どの拒否を許可するかという決定は、注意して行ってください。なかには、無視して dontaudit ルールで扱われるべきものもあります。わからない場合やアドバイスが必要な場合は、fedora-selinux-list のような SELinux リストに掲載されている他の SELinux ユーザーや開発者に連絡してください。
ポリシーを再構築して dontaudit ルールを有効にするには、root で以下のコマンドを実行します。 
~]# semodule -B
これでポリシーが元の状態に復元されます。dontaudit ルールの完全なリストを表示させるには、sesearch --dontaudit コマンドを実行します。検索結果を絞り込むには、-s domain オプションと grep コマンドを使います。以下に例を挙げます。 
~]$ sesearch --dontaudit -s smbd_t | grep squid
dontaudit smbd_t squid_port_t : tcp_socket name_bind ;
dontaudit smbd_t squid_port_t : udp_socket name_bind ;
拒否の分析に関する情報は、「Raw Audit Messages」と「sealert メッセージ」を参照してください。

11.3.3. サービスの man ページ

サービスの man ページには、特定の状況で使うべきファイルタイプやサービスの持つアクセス権限を変更するブール値 (NFS ボリュームにアクセスする httpd など) といった価値のある情報が含まれています。この情報は、通常の man ページや、sepolicy manpage ユーティリティーを使って各サービスドメインに SELinux ポリシーから自動で生成可能な man ページにあります。このような man ページは、service-name_selinux という形式の名前が付けられます。また、これらの man ページは selinux-policy-doc パッケージからも提供されます。
例えば、httpd_selinux(8) man ページには、特定の状況で使うべきファイルタイプやスクリプトを許可するブール値、共有ファイル、ユーザーのホームディレクトリー内にあるディレクトリーへのアクセスなどに関する情報があります。サービスに関する SELinux 情報の man ページには、以下のものがあります。
  • Samba: samba_selinux(8) man ページは、たとえば、samba_enable_home_dirs ブール値を有効にすると Samba がユーザーのホームディレクトリーを共有できるようになることを説明しています。
  • NFS: nfsd_selinux(8) man ページは、SELinux nfsd ポリシーを使うとユーザーが自身の nfsd プロセスを可能な限り安全な方法で設定できることを説明しています。
man ページの情報は、正しいファイルタイプとブール値の設定に役立ち、SELinux によるアクセス拒否を防ぎます。
sepolicy manpage についての詳細は、「Man ページの生成: sepolicy manpage」を参照してください。

11.3.4. Permissive ドメイン

SELinux が permissive モードで実行されていると、SELinux はアクセスを拒否しませんが、enforcing モードでは拒否されたであろうアクションの拒否がログに記録されます。以前は、単一ドメインを permissive にすることはできませんでした (プロセスはドメイン内で実行されます)。特定の状況ではこの結果、システム全体を permissive にして問題の解決を図っていました。
Permissive ドメインは、管理者がシステム全体を permissive にするのではなく、単一プロセス (ドメイン) を permissive で実行する設定を可能にするものです。permissive ドメインでは SELinux チェックは引き続き行われますが、カーネルがアクセスを許可し、SELinux がアクセスを拒否したであろう状況の AVC 拒否をレポートします。
Permissive ドメインには以下の利点があります。
  • システム全体を permissive にして危険にさらすことなく、単一のプロセス (ドメイン) を permissive にして問題解決ができます。
  • 管理者が新たなアプリケーション用のポリシーを作成できます。以前は最低限のポリシーを作成し、マシン全体を permissive モードにすることでアプリケーションが実行できるようにすることが推奨されていましたが、SELinux 拒否はログ記録されていました。そして audit2allow を使ってポリシーを記述することができました。これは、システム全体を危険にさらしていました。permissive ドメインでは、新規ポリシー内のドメインのみが permissive でマークされるので、システム全体を危険にさらすことはありません。

11.3.4.1. ドメインを permissive にする

ドメインを permissive にするには、semanage permissive -a domain コマンドを実行します。ここでの domain は、permissive にするドメインのことです。例えば、root で以下のコマンドを実行し、httpd_t ドメイン (Apache HTTP Server が稼働するドメイン) を permissive にします。 
~]# semanage permissive -a httpd_t
permissive にしたドメインを一覧表示するには、root で semodule -l | grep permissive コマンドを実行します。以下のようになります。 
~]# semodule -l | grep permissive
permissive_httpd_t    (null)
permissivedomains     (null)
ドメインが permissive である必要がなければ、semanage permissive -d domain コマンドを root で実行します。以下のようになります。 
~]# semanage permissive -d httpd_t

11.3.4.2. Permissive ドメインを無効にする

permissivedomains.pp モジュールには、システム上で提示されるすべての permissive ドメイン宣言が含まれています。これらの permissive ドメインすべてを無効にするには、root で以下のコマンドを実行します。 
~]# semodule -d permissivedomains

注記

semodule -d コマンドでポリシーモジュールを無効にすると、semodule -l コマンドでそのモジュールが表示されなくなります。無効になっているものも含めてすべてのポリシーモジュールを表示するには、root で以下のコマンドを実行します。 
~]# semodule --list-modules=full

11.3.4.3. Permissive ドメイン での拒否

SYSCALL メッセージは、permissive ドメインでは違ったものになります。以下は、Apache HTTP Server からの AVC 拒否 (および関連するシステムコール) の例です。 
type=AVC msg=audit(1226882736.442:86): avc:  denied  { getattr } for  pid=2427 comm="httpd" path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

type=SYSCALL msg=audit(1226882736.442:86): arch=40000003 syscall=196 success=no exit=-13 a0=b9a1e198 a1=bfc2921c a2=54dff4 a3=2008171 items=0 ppid=2425 pid=2427 auid=502 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
デフォルトでは httpd_t ドメインは permissive ではないので、アクションは拒否され SYSCALL メッセージに success=no が含まれます。以下の例は、同じ状況での AVC 拒否ですが、semanage permissive -a httpd_t コマンドを実行して httpd_t ドメインを permissive にしてある点が異なります。 
type=AVC msg=audit(1226882925.714:136): avc:  denied  { read } for  pid=2512 comm="httpd" name="file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

type=SYSCALL msg=audit(1226882925.714:136): arch=40000003 syscall=5 success=yes exit=11 a0=b962a1e8 a1=8000 a2=0 a3=8000 items=0 ppid=2511 pid=2512 auid=502 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
このケースでは、AVC 拒否はログ記録されましたが、SYSCALL メッセージの success=yes にあるように、アクセスは拒否されませんでした。
permissive ドメインに関する詳細情報は、Dan Walsh のブログ記事「Permissive Domains」を参照してください。

11.3.5. 拒否の検索および表示

このセクションでは、setroubleshoot、setroubleshoot-server、dbus、audit のパッケージがインストールされ、auditd、rsyslogd、setroubleshootd のデーモンが実行中であることを前提としています。これらのデーモンのスタート方法に関しては、「使用するログファイル」を参照してください。SELinux AVC メッセージの検索および表示には、ausearch、aureport、sealert などの数多くのユーティリティーが利用できます。

ausearch

audit パッケージが ausearch ユーティリティーを提供します。このユーティリティーは、異なる検索条件に基づいて audit デーモンログイベントにクエリを行うことができます[10]。ausearch ユーティリティーは /var/log/audit/audit.log にアクセスするので、root ユーザーで実行する必要があります。
検索対象コマンド
すべての拒否ausearch -m avc,user_avc,selinux_err,user_selinux_err
当日の拒否ausearch -m avc -ts today
過去 10 分間の拒否ausearch -m avc -ts recent
特定のサービスの SELinux AVC メッセージを検索するには、-c comm-name オプションを使います。ここでの comm-name は実行可能ファイルの名前です。例えば、Apache HTTP Server の場合は httpd、Samba の場合は smbd になります。 
~]# ausearch -m avc -c httpd
~]# ausearch -m avc -c smbd
ausearch コマンドでは、読みやすくするためには --interpret (-i) オプションを、スクリプト処理には --raw (-r) オプションを使用することが推奨されます。ausearch オプションの詳細については、ausearch(8) man ページを参照してください。

aureport

audit パッケージは aureport ユーティリティーを提供し、これは監査システムログのサマリーレポートを作成します[11]。aureport ユーティリティーは /var/log/audit/audit.log にアクセスするので、root ユーザーで実行する必要があります。SELinux 拒否メッセージの一覧を表示し、その発生頻度を確認するには、aureport -a コマンドを実行します。以下の例では出力に 2 つの拒否があります。 
~]# aureport -a

AVC Report
========================================================
# date time comm subj syscall class permission obj event
========================================================
1. 05/01/2009 21:41:39 httpd unconfined_u:system_r:httpd_t:s0 195 file getattr system_u:object_r:samba_share_t:s0 denied 2
2. 05/03/2009 22:00:25 vsftpd unconfined_u:system_r:ftpd_t:s0 5 file read unconfined_u:object_r:cifs_t:s0 denied 4

sealert

setroubleshoot-server パッケージは sealert ユーティリティーを提供します。これは、setroubleshoot-server が変換した拒否メッセージを読み取ります[12]。/var/log/messages にあるように、拒否には ID が割り当てられます。以下の例は、messages からの拒否です。 
setroubleshoot: SELinux is preventing /usr/sbin/httpd from name_bind access on the tcp_socket. For complete SELinux messages. run sealert -l 8c123656-5dda-4e5d-8791-9e3bd03786b7
この例の拒否 ID は、8c123656-5dda-4e5d-8791-9e3bd03786b7 です。-l オプションは、ID を引数 として取ります。sealert -l 8c123656-5dda-4e5d-8791-9e3bd03786b7 コマンドを実行すると、SELinux がアクセスを拒否した詳細な分析とアクセスを許可するソリューションが提示されます。
X Window System を実行中で setroubleshoot と setroubleshoot-server パッケージがインストールされ、setroubleshootd、dbus、および auditd デーモンが稼働している場合、SELinux がアクセスを拒否すると警告が表示されます。
An AVC denial message
表示 をクリックすると sealert GUI が起動し、問題の解決を図ることができます。
別の方法では sealert -b コマンドを実行すると、sealert GUI を開始することができます。拒否メッセージすべての詳細な分析を表示するには、sealert -l \* コマンドを実行します。

11.3.6. Raw Audit Messages

Raw Audit Messages は /var/log/audit/audit.log に記録されます。以下の例は、Apache HTTP Server (httpd_t ドメインで稼働中) が /var/www/html/file1 ファイル (samba_share_t タイプでラベル付け) にアクセスしようとした際に発生したAVC 拒否メッセージ (および関連のシステムコール) です。 
type=AVC msg=audit(1226874073.147:96): avc:  denied  { getattr } for  pid=2465 comm="httpd" path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13 a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
{ getattr }
中括弧内のこのアイテムは、拒否されたパーミッションを示します。getattr エントリーは、ソースプロセスがターゲットファイルのステータス情報の読み取りを試みたことを示します。これは、ファイルの読み取り前に発生します。このアクションが拒否されたのは、アクセスされたファイルに間違ったラベルが付けられていためです。一般的に見られるパーミッションは、getattr、read、write などです。
comm="httpd"
プロセスを開始した実行可能ファイルです。このファイルの完全パスは、システムコール (SYSCALL) メッセージの exe= セクションにあります。このケースでは、exe="/usr/sbin/httpd" になります。
path="/var/www/html/file1"
プロセスがアクセスを試みたオブジェクト (ターゲット) へのパスです。
scontext="unconfined_u:system_r:httpd_t:s0"
拒否されたアクションを試みたプロセスの SELinux コンテキストです。このケースでは、Apache HTTP Server の SELinux コンテキストで、これは httpd_t ドメインで実行中です。
tcontext="unconfined_u:object_r:samba_share_t:s0"
プロセスがアクセスを試みたオブジェクト (ターゲット) の SELinux コンテキストです。このケースでは、file1 のコンテキストです。httpd_t ドメインで実行中のプロセスは samba_share_t タイプにはアクセスできないことに注意してください。
状況によっては、tcontext が scontext と一致する場合もあります。例えば、プロセスがユーザー ID など、その実行中のプロセスの特徴を変更することになるシステムサービスの実行を試みる場合などです。また、プロセスが通常の制限で許されている以上のリソース (メモリーなど) を使おうとして、そのプロセスが制限超過を許されているかどうかのセキュリティーチェックにつながる場合、tcontext が scontext と一致する可能性があります。
システムコール (SYSCALL) メッセージでは、2 つの点に注目します。
  • success=no は、拒否 (AVC) が強制されたかどうかを示します。success=no は、システムコールが成功しなかったことを示します (SELinux がアクセスを拒否)。success=yes は、システムコールが成功したことを示します。これは、unconfined_service_t や kernel_t などの permissive ドメインや制限のないドメインで見られます。
  • exe="/usr/sbin/httpd" は、プロセスを開始した実行可能ファイルへの完全パスです。このケースでは、exe="/usr/sbin/httpd" です。
SELinux がアクセスを拒否することになる原因の多くは、ファイルタイプが間違っていることです。トラブルシューティングを開始するには、ソースコンテキスト (scontext) とターゲットコンテキスト (tcontext) を比べます。プロセス (scontext) がそのようなオブジェクト (tcontext) にアクセスしてもよいかどうかを確認します。例えば、Apache HTTP Server (httpd_t) は特定の設定がない限り、httpd_sys_content_t や public_content_t など、httpd_selinux(8) man ページで指定されたタイプ以外にはアクセスすべきではありません。

11.3.7. sealert メッセージ

拒否には ID が割り当てられ、/var/log/messages で見ることができます。以下の例は、Apache HTTP Server (httpd_t ドメインで稼働中) が /var/www/html/file1 ファイル (samba_share_t タイプでラベル付け) にアクセスしようとした際に発生したAVC 拒否 (messages にログ記録) です。 
hostname setroubleshoot: SELinux is preventing httpd (httpd_t) "getattr" to /var/www/html/file1 (samba_share_t). For complete SELinux messages. run sealert -l 32eee32b-21ca-4846-a22f-0ba050206786
以下のように、sealert -l 32eee32b-21ca-4846-a22f-0ba050206786 コマンドを実行して完全なメッセージを表示します。このコマンドはローカルマシン上でのみ機能し、sealert GUI と同じ情報を提示します。 
~]$ sealert -l 32eee32b-21ca-4846-a22f-0ba050206786
SELinux is preventing httpd from getattr access on the file /var/www/html/file1.

*****  Plugin restorecon (92.2 confidence) suggests   ************************

If you want to fix the label. 
/var/www/html/file1 default label should be httpd_sys_content_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /var/www/html/file1

*****  Plugin public_content (7.83 confidence) suggests   ********************

If you want to treat file1 as public content
Then you need to change the label on file1 to public_content_t or public_content_rw_t.
Do
# semanage fcontext -a -t public_content_t '/var/www/html/file1'
# restorecon -v '/var/www/html/file1'

*****  Plugin catchall (1.41 confidence) suggests   **************************

If you believe that httpd should be allowed getattr access on the file1 file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'httpd' --raw | audit2allow -M my-httpd
# semodule -i my-httpd.pp


Additional Information:
Source Context                system_u:system_r:httpd_t:s0
Target Context                unconfined_u:object_r:samba_share_t:s0
Target Objects                /var/www/html/file1 [ file ]
Source                        httpd
Source Path                   httpd
Port                          <Unknown>
Host                          hostname.redhat.com
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-166.el7.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     hostname.redhat.com
Platform                      Linux hostname.redhat.com
                              3.10.0-693.el7.x86_64 #1 SMP Thu Jul 6 19:56:57
                              EDT 2017 x86_64 x86_64
Alert Count                   2
First Seen                    2017-07-20 02:52:11 EDT
Last Seen                     2017-07-20 02:52:11 EDT
Local ID                      32eee32b-21ca-4846-a22f-0ba050206786

Raw Audit Messages
type=AVC msg=audit(1500533531.140:295): avc:  denied  { getattr } for  pid=24934 comm="httpd" path="/var/www/html/file1" dev="vda1" ino=31457414 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file


Hash: httpd,httpd_t,samba_share_t,file,getattr
Summary
拒否されたアクションの簡潔なサマリーです。これは、/var/log/messages の拒否と同じです。この例では、httpd プロセスが samba_share_t タイプのラベルが付けられたファイル (file1) へのアクセスを拒否されました。
Detailed Description
より詳細な説明です。この例では、file1 に samba_share_t タイプのラベルが付けられています。このタイプは、Samba を使用してエクスポートするファイルおよびディレクトリーに使われます。説明では、Apache HTTP Server および Samba によるアクセスが望まれる場合、タイプを Apache HTTP Server および Samba がアクセス可能なものに変更することを提案しています。
Allowing Access
アクセスを可能にする方法を提案しています。ファイルの再ラベル付けやブール値を有効にする、ローカルポリシーモジュールの作成、などの方法があります。このケースでは、Apache HTTP Server および Samba の両方がアクセス可能なタイプでファイルにラベル付けすることを提案しています。
Fix Command
アクセスを可能にし、拒否を解決するコマンドを提案しています。この例では、file1 タイプを Apache HTTP Server と Samba の両方がアクセス可能な public_content_t に変更するコマンドを提示しています。
追加情報
ポリシーパッケージ名やバージョン (selinux-policy-3.13.1-166.el7.noarch) などのバグレポートに便利な情報です。ただ、拒否が発生した原因の解決には役立たない可能性があります。
Raw Audit Messages
/var/log/audit/audit.log からの拒否に関連した raw 監査メッセージです。AVC 拒否の各アイテムに関しては、「Raw Audit Messages」を参照してください。

11.3.8. アクセス許可: audit2allow

警告

実稼働環境では、このセクションの例を使用しないでください。これは、audit2allow ユーティリティーの使用を説明する目的でのみ、使われています。
audit2allow ユーティリティーは拒否された操作のログから情報を収集し、SELinux policy allow ルールを生成します[13]。「sealert メッセージ」にあるように拒否メッセージを分析し、ラベル変更がないもしくはブール値で許可されたアクセスがない場合は、audit2allow を使用してローカルポリシーモジュールを作成します。SELinux にアクセスを拒否された場合は、audit2allow を実行すると以前は拒否されたアクセスを許可する Type Enforcement ルールが生成されます。
audit2allow を使用して、SELinux の拒否を確認する際の最初のオプションとしてローカルポリシーモジュールを生成しないでください。ラベリングの問題がある場合のトラブルシューティングには、チェックを開始する必要があります。2 番目に多いケースは、プロセスの設定を編集し、SELinux にそれを認識させることを忘れた場合です。詳細は、ホワイトペーパーの Four Key Causes of SELinux Errors を参照してください。
以下の例では、audit2allow を使ってポリシーモジュールを作成します。
  1. 拒否メッセージおよび関連するシステムコールは、/var/log/audit/audit.log ファイルにログ記録されます。 
    type=AVC msg=audit(1226270358.848:238): avc:  denied  { write } for  pid=13349 comm="certwatch" name="cache" dev=dm-0 ino=218171 scontext=system_u:system_r:certwatch_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir

type=SYSCALL msg=audit(1226270358.848:238): arch=40000003 syscall=39 success=no exit=-13 a0=39a2bf a1=3ff a2=3a0354 a3=94703c8 items=0 ppid=13344 pid=13349 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="certwatch" exe="/usr/bin/certwatch" subj=system_u:system_r:certwatch_t:s0 key=(null)
    この例では、certwatch は var_t タイプのラベルが付けられたディレクトリーへの書き込みアクセスが拒否されました。「sealert メッセージ」にあるように拒否メッセージを分析します。ラベル変更がないもしくはブール値で許可されたアクセスがない場合は、audit2allow を使ってローカルポリシーモジュールを作成します。
  2. 以下のコマンドを実行して、アクセスが拒否された理由についてヒューマンリーダブルな記述を作成します。audit2allow ユーティリティーは /var/log/audit/audit.log を読み取るので、root ユーザーで実行する必要があります。 
    ~]# audit2allow -w -a
type=AVC msg=audit(1226270358.848:238): avc:  denied  { write } for  pid=13349 comm="certwatch" name="cache" dev=dm-0 ino=218171 scontext=system_u:system_r:certwatch_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir
	Was caused by:
		Missing type enforcement (TE) allow rule.

	You can use audit2allow to generate a loadable module to allow this access.
    -a コマンドラインオプションにより、すべてを監査ログが読み取られます。-w オプションでは、ヒューマンリーダブルな記述が作成されます。上記では Type Enforcement ルールがないのでアクセスが拒否されました。
  3. 以下のコマンドを実行して、拒否されたアクセスを許可する Type Enforcement ルールを表示します。 
    ~]# audit2allow -a


#============= certwatch_t ==============
allow certwatch_t var_t:dir write;

    重要

    Type Enforcement ルールの欠如は通常、SELinux ポリシーのバグによって引き起こされ、Red Hat Bugzilla で報告されるべきです。Red Hat Enterprise Linux の場合、Red Hat Enterprise Linux 製品に対してバグを作成し、selinux-policy コンポーネントを選択します。バグ報告では、audit2allow -w -a および audit2allow -a コマンドの出力も報告してください。
  4. audit2allow -a が表示したルールを使うには、root で以下のコマンドを実行してカスタムモジュールを作成します。-M オプションは、現在作業中のディレクトリーに -M で指定された名前のついた Type Enforcement ファイル (.te) を作成します。 
    ~]# audit2allow -a -M mycertwatch
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i mycertwatch.pp
  5. また、audit2allow は Type Enforcement ルールをポリシーパッケージ (.pp) にコンパイルします。 
    ~]# ls
mycertwatch.pp  mycertwatch.te
    モジュールをインストールするには、以下のコマンドを root で実行します。 
    ~]# semodule -i mycertwatch.pp

    重要

    audit2allow で作成したモジュールは、必要以上にアクセスを許可する場合があります。audit2allow で作成されたモジュールは、アップストリームの SELinux リストに公表してレビューされることが推奨されます。ポリシーにバグがあると思われる場合は、Red Hat Bugzilla でバグを作成してください。
複数のプロセスから複数の拒否メッセージがあって、そのうちの 1 つのプロセスにのみカスタムポリシーを作成する場合は、grep ユーティリティーを使って audit2allow の入力を絞り込みます。以下の例では、grep を使って certwatch に関連した拒否メッセージのみを audit2allow に送信する方法を示しています。 
~]# grep certwatch /var/log/audit/audit.log | audit2allow -R -M mycertwatch2
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i mycertwatch2.pp

[10] ausearch についての詳細情報は、ausearch(8) の man ページを参照してください。
[11] aureport についての詳細は、aureport(8) の man ページを参照してください。
[12] sealert についての詳細は、sealert(8) の man ページを参照してください。
[13] audit2allow についての詳細は、audit2allow(1) man ページを参照してください。
このページには機械翻訳が使用されている場合があります (詳細はこちら)。