Show Table of Contents
10.3. 問題の修正
以下のセクションでは、問題の解決方法を説明します。取り上げるトピックは以下のとおりです。Linux パーミッションのチェック - これは SELinux ルールの前にチェックされます。拒否がログ記録されない場合に SELinux がアクセスを拒否する理由。サービスの man ページ - これにはラベル付けとブール値の情報が含まれます。あるプロセスがシステム全体ではなく permissive で実行することを許可するための permissive ドメイン。拒否メッセージの検索方法および表示方法。拒否の分析。
audit2allow によるカスタムポリシーモジュールの作成。
10.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」のドラフトを参照してください。
10.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 squiddontaudit smbd_t squid_port_t : tcp_socket name_bind ; dontaudit smbd_t squid_port_t : udp_socket name_bind ;
拒否の分析に関する情報は、「Raw Audit Messages」と「sealert メッセージ」を参照してください。
10.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」を参照してください。
10.3.4. Permissive ドメイン
SELinux が permissive モードで実行されていると、SELinux はアクセスを拒否しませんが、enforcing モードでは拒否されたであろうアクションの拒否がログに記録されます。以前は、単一ドメインを permissive にすることはできませんでした (プロセスはドメイン内で実行されます)。特定の状況ではこの結果、システム全体を permissive にして問題の解決を図っていました。
Permissive ドメインは、管理者がシステム全体を permissive にするのではなく、単一プロセス (ドメイン) を permissive で実行する設定を可能にするものです。permissive ドメインでは SELinux チェックは引き続き行われますが、カーネルがアクセスを許可し、SELinux がアクセスを拒否したであろう状況の AVC 拒否をレポートします。
Permissive ドメインには以下の利点があります。
- システム全体を permissive にして危険にさらすことなく、単一のプロセス (ドメイン) を permissive にして問題解決ができます。
- 管理者が新たなアプリケーション用のポリシーを作成できます。以前は最低限のポリシーを作成し、マシン全体を permissive モードにすることでアプリケーションが実行できるようにすることが推奨されていましたが、SELinux 拒否はログ記録されていました。そして
audit2allowを使ってポリシーを記述することができました。これは、システム全体を危険にさらしていました。permissive ドメインでは、新規ポリシー内のドメインのみが permissive でマークされるので、システム全体を危険にさらすことはありません。
10.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 permissivepermissive_httpd_t 1.0 permissivedomains 1.0.0
ドメインが permissive である必要がなければ、
semanage permissive -d domain コマンドを root で実行します。以下のようになります。
~]#semanage permissive -d httpd_t
10.3.4.2. Permissive ドメインを無効にする
permissivedomains.pp モジュールには、システム上で提示されるすべての permissive ドメイン宣言が含まれています。これらの permissive ドメインすべてを無効にするには、root で以下のコマンドを実行します。
~]#semodule -d permissivedomains
注記
semodule -d コマンドでポリシーモジュールを無効にすると、semodule -l コマンドでそのモジュールが表示されなくなります。無効になっているものも含めてすべてのポリシーモジュールを表示するには、root で以下のコマンドを実行します。
~]#semodule --list-modules=full
10.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」を参照してください。
10.3.5. 拒否の検索および表示
このセクションでは、setroubleshoot、setroubleshoot-server、dbus、audit のパッケージがインストールされ、
auditd、rsyslogd、setroubleshootd のデーモンが実行中であることを前提としています。これらのデーモンのスタート方法に関しては、「使用するログファイル」を参照してください。SELinux AVC メッセージの検索および表示には、ausearch、aureport、sealert などの数多くのユーティリティーが利用できます。
ausearch
audit パッケージが
ausearch ユーティリティーを提供します。このユーティリティーは、異なる検索条件に基づいて audit デーモンログイベントにクエリを行うことができます[12]。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 ユーティリティーを提供し、これは監査システムログのサマリーレポートを作成します[13]。aureport ユーティリティーは /var/log/audit/audit.log にアクセスするので、root ユーザーで実行する必要があります。SELinux 拒否メッセージの一覧を表示し、その発生頻度を確認するには、aureport -a コマンドを実行します。以下の例では出力に 2 つの拒否があります。
~]#aureport -aAVC 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 が変換した拒否メッセージを読み取ります[14]。/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 がアクセスを拒否すると警告が表示されます。
表示 をクリックすると sealert GUI が起動し、問題の解決を図ることができます。
別の方法では
sealert -b コマンドを実行すると、sealert GUI を開始することができます。拒否メッセージすべての詳細な分析を表示するには、sealert -l \* コマンドを実行します。
10.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 ページで指定されたタイプ以外にはアクセスすべきではありません。
10.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 84e0b04d-d0ad-4347-8317-22e74f6cd020
以下のように、
sealert -l 84e0b04d-d0ad-4347-8317-22e74f6cd020 コマンドを実行して完全なメッセージを表示します。このコマンドはローカルマシン上でのみ機能し、sealert GUI と同じ情報を提示します。
~]$sealert -l 84e0b04d-d0ad-4347-8317-22e74f6cd020Summary: SELinux is preventing httpd (httpd_t) "getattr" to /var/www/html/file1 (samba_share_t). Detailed Description: SELinux denied access to /var/www/html/file1 requested by httpd. /var/www/html/file1 has a context used for sharing by different program. If you would like to share /var/www/html/file1 from httpd also, you need to change its file context to public_content_t. If you did not intend to this access, this could signal a intrusion attempt. Allowing Access: You can alter the file context by executing chcon -t public_content_t '/var/www/html/file1' Fix Command: chcon -t public_content_t '/var/www/html/file1' Additional Information: Source Context unconfined_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 /usr/sbin/httpd Port <Unknown> Host hostname Source RPM Packages httpd-2.2.10-2 Target RPM Packages Policy RPM selinux-policy-3.5.13-11.fc12 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name public_content Host Name hostname Platform Linux hostname 2.6.27.4-68.fc12.i686 #1 SMP Thu Oct 30 00:49:42 EDT 2008 i686 i686 Alert Count 4 First Seen Wed Nov 5 18:53:05 2008 Last Seen Wed Nov 5 01:22:58 2008 Local ID 84e0b04d-d0ad-4347-8317-22e74f6cd020 Line Numbers Raw Audit Messages node=hostname type=AVC msg=audit(1225812178.788:101): avc: denied { getattr } for pid=2441 comm="httpd" path="/var/www/html/file1" dev=dm-0 ino=284916 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file node=hostname type=SYSCALL msg=audit(1225812178.788:101): arch=40000003 syscall=196 success=no exit=-13 a0=b8e97188 a1=bf87aaac a2=54dff4 a3=2008171 items=0 ppid=2439 pid=2441 auid=502 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=3 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
- 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に変更するコマンドを提示しています。 - Additional Information
- ポリシーパッケージ名やバージョン (
selinux-policy-3.5.13-11.fc12) などのバグレポートに便利な情報です。ただ、拒否が発生した原因の解決には役立たない可能性があります。 - Raw Audit Messages
/var/log/audit/audit.logからの拒否に関連した raw 監査メッセージです。AVC 拒否の各アイテムに関しては、「Raw Audit Messages」を参照してください。
10.3.8. アクセス許可: audit2allow
警告
実稼働環境では、このセクションの例を使用しないでください。これは、
audit2allow ユーティリティーの使用を説明する目的でのみ、使われています。
audit2allow ユーティリティーは拒否された操作のログから情報を収集し、SELinux policy allow ルールを生成します[15]。「sealert メッセージ」にあるように拒否メッセージを分析し、ラベル変更がないもしくはブール値で許可されたアクセスがない場合は、audit2allow を使用してローカルポリシーモジュールを作成します。SELinux にアクセスを拒否された場合は、audit2allow を実行すると以前は拒否されたアクセスを許可する Type Enforcement ルールが生成されます。
以下の例では、
audit2allow を使ってポリシーモジュールを作成します。
- 拒否メッセージおよび関連するシステムコールは、
/var/log/audit/audit.logファイルにログ記録されます。type=AVC msg=audit(1226270358.848:238): avc: denied
{ write }for pid=13349comm="certwatch"name="cache" dev=dm-0 ino=218171 scontext=system_u:system_r:certwatch_t:s0tcontext=system_u:object_r:var_t:s0tclass=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を使ってローカルポリシーモジュールを作成します。 - 以下のコマンドを実行して、アクセスが拒否された理由についてヒューマンリーダブルな記述を作成します。
audit2allowユーティリティーは/var/log/audit/audit.logを読み取るので、root ユーザーで実行する必要があります。~]#audit2allow -w -atype=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 ルールがないのでアクセスが拒否されました。 - 以下のコマンドを実行して、拒否されたアクセスを許可する 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コマンドの出力も報告してください。 audit2allow -aが表示したルールを使うには、root で以下のコマンドを実行してカスタムモジュールを作成します。-Mオプションは、現在作業中のディレクトリーに-Mで指定された名前のついた Type Enforcement ファイル (.te) を作成します。~]#audit2allow -a -M mycertwatch******************** IMPORTANT *********************** To make this policy package active, execute: semodule -i mycertwatch.pp- また、
audit2allowは Type Enforcement ルールをポリシーパッケージ (.pp) にコンパイルします。~]#lsmycertwatch.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
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.