Show Table of Contents
このページには機械翻訳が使用されている場合があります (詳細はこちら)。
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 がアクセスを拒否すると警告が表示されます。

表示
をクリックすると 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
を使ってポリシーモジュールを作成します。
- 拒否メッセージおよび関連するシステムコールは、
/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: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
を使ってローカルポリシーモジュールを作成します。 - 以下のコマンドを実行して、アクセスが拒否された理由についてヒューマンリーダブルな記述を作成します。
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 ルールがないのでアクセスが拒否されました。 - 以下のコマンドを実行して、拒否されたアクセスを許可する 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
) にコンパイルします。~]#
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
このページには機械翻訳が使用されている場合があります (詳細はこちら)。