11.3. 問題の修正
以下のセクションでは、問題のトラブルシューティングを行う方法を説明します。SELinux ルールよりも前に確認される Linux のパーミッションの確認、SELinux によるアクセス拒否が考えられる原因があるが、拒否はログに記録されない場合、サービス用の man ページ (ラベリングとブール値に関する情報を記載)、システム全体ではなく 1 つ プロセスが Permissive を実行できるようにするための Permissive ドメイン、拒否メッセージの検索および表示方法、拒否の分析、
aud2allow
を使用したカスタムポリシーモジュールの作成について説明します。
11.3.1. Linux の権限
アクセスが拒否された場合は、標準の Linux 権限を確認します。1章導入部分 で説明されているように、ほとんどのオペレーティングシステムは DAC (Discretionary Access Control) システムを使用してアクセスを制御し、ユーザーが所有するファイルのパーミッションを制御できるようにします。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 Documentation Project "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 監査メッセージ」 および 「sealert メッセージ」 を参照してください。
11.3.3. サービスの man ページ
サービスの man ページには、指定した状況で使用するファイルタイプや、サービスのアクセスを変更するためのブール値 (NFS ボリュームにアクセスする
httpd
など) などの貴重な情報が記載されています。この情報は、標準のマニュアルページ、または sepolicy manpage
ユーティリティーを使用してすべてのサービスドメインの SELinux ポリシーから自動的に生成できるマニュアルページにある場合があります。このような 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 ページでは、nfsd プロセスをできるだけ安全な方法で設定できるように、SELinux の nfsd ポリシーを説明しています。
man ページの情報は、正しいファイルタイプとブール値の設定に役立ちます。これにより、SELinux によるアクセスを拒否することを防ぐことができます。
sepolicy manpage
の詳細は 「手動ページの生成: sepolicy manpage」 を参照してください。
11.3.4. Permissive ドメイン
SELinux が Permissive モードで実行している場合、SELinux はアクセスを拒否しませんが、Enforcing モードで実行しても拒否されるアクションのログは SELinux によって記録されます。以前は、1 つのドメインを Permissive にすることはできませんでした (プロセスはドメインで実行されることに注意してください)。特定の状況では、これによりシステム全体が問題のトラブルシューティングを受け入れられるようになりました。
パーミッションドメインを使用すると、管理者はシステム全体を許容するのではなく、1 つのプロセス (ドメイン) に対して Permissive を実行するように設定できます。SELinux によるチェックは依然として Permissive ドメインに対して実行されますが、カーネルは、SELinux がアクセスを拒否したであろう状況では、アクセスを許可し、AVC の拒否を報告します。
Permissive ドメインには、以下の用途があります。
- これを使用すると、1 つのプロセス (ドメイン) を Permissive にして、システム全体をリスクにさらさずに問題のトラブルシューティングを行うことができます。
- これにより、管理者は新しいアプリケーションのポリシーを作成できます。以前は、最小限のポリシーを作成してから、マシン全体を Permissive モードにしてアプリケーションを実行できるようにし、SELinux の拒否ログが記録されるようにすることが推奨されていました。次に、ポリシーを作成するために
aud2allow
を使用することができます。これにより、システム全体が危険にさらされていました。Permissive ドメインでは、システム全体を危険にさらさずに、新しいポリシーのドメインのみが Permissive とマークされます。
11.3.4.1. ドメインを Permissive にする
ドメインを Permissive にするには、semanage permissive -a domain コマンドを実行します。domain は、Permissive にするドメインです。たとえば、root で次のコマンドを実行して、
httpd_t
ドメイン (Apache HTTP サーバーを実行しているドメイン) を Permissive (許容) にします。
~]#
semanage permissive -a httpd_t
Permissive にしたドメインのリストを表示するには、root で semodule -l | grep permissive を実行します。以下に例を示します。
~]#
semodule -l | grep permissive
permissive_httpd_t (null)
permissivedomains (null)
ドメインを Permissive にしない場合は、root で semanage permissive -d domain コマンドを実行します。以下に例を示します。
~]#
semanage permissive -d httpd_t
11.3.4.2. Permissive ドメインの無効化
permissivedomains.pp
には、システム上にある Permissive ドメイン宣言がすべて含まれています。すべての Permissive ドメインを無効にするには、root で次のコマンドを実行します。
~]#
semodule -d permissivedomains
注記
module -d コマンドでポリシーモジュールが無効になると、semodule -l コマンドの出力に表示されなくなります。無効にしたものを含むすべてのポリシーモジュールを表示するには、root で次のコマンドを実行します。
~]#
semodule --list-modules=full
11.3.4.3. Permissive ドメインの拒否
SYSCALL
メッセージは、Permissive ドメインでは異なります。以下は、Apache HTTP サーバーによる 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
デーモンが実行していることを前提としています。これらのデーモンの起動方法は、「どのログファイルが使用されるか」 を参照してください。ausearch
、aureport
、および sealert
などの SELinux AVC メッセージの検索および表示には、多数のユーティリティーを使用できます。
ausearch
audit パッケージは、さまざまな検索基準に基づいてイベントの
audit
デーモンログを照会できる ausearch ユーティリティーを提供します。[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 サーバーの場合は 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
オプションは、識別子を引き数として取ります。sealert -l 8c123656-5dda-4e5d-8791-9e3bd03786b7 コマンドを実行すると、SELinux がアクセスを拒否した理由を詳細に分析し、アクセスを許可する解決策を示すことができます。
X Window System を実行中で、setroubleshoot パッケージおよび setroubleshoot-server パッケージがインストールされており、
setroubleshootd
デーモン、dbus
デーモン、および auditd
デーモンが実行されている場合は、SELinux がアクセスを拒否したときに警告が表示されます。

Show
をクリックすると、sealert
画面が表示されます。これにより、トラブルシューティングが可能になります。

または、sealert -b コマンドを実行して、sealert GUI を起動します。すべての拒否メッセージの詳細な解析を表示するには、sealert -l \* コマンドを実行します。
11.3.6. Raw 監査メッセージ
Raw 監査メッセージは
/var/log/audit/audit.log
にログ記録されます。以下は、Apache HTTP サーバー (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 は
httpd_t
タイプで実行している SELinux コンテキストです。 - tcontext="unconfined_u:object_r:samba_share_t:s0"
- プロセスがアクセスを試みたオブジェクトの SELinux コンテキスト (ターゲット)。この例では、これが
file1
の SELinux コンテキストです。samba_share_t
タイプは、httpd_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 メッセージ
拒否は、
/var/log/messages
にあるように ID が割り当てられています。以下は、Apache HTTP サーバー (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
- 概要
- 拒否されたアクションの概要これは、
/var/log/messages
の拒否と同じです。この例では、httpd
プロセスが、samba_share_t
タイプのラベルが付いたファイル (file1
) へのアクセスを拒否されています。 - 詳細な説明
- より詳細な説明この例では、
file1
にはsamba_share_t
タイプのラベルが付けられています。このタイプは、Samba を使用してエクスポートするファイルおよびディレクトリーに使用されます。この説明では、このようなアクセスが必要な場合は、Apache HTTP Server および Samba がアクセス可能なタイプにタイプを変更することが推奨されています。 - アクセスの許可
- アクセスを許可する方法を説明します。ファイルの再ラベル付け、ブール値の有効化、またはローカルポリシーモジュールの作成を行います。この場合、Apache HTTP Server と Samba の両方がアクセスできるタイプでファイルにラベルを付けることが提案されます。
- Fix コマンド
- アクセスを許可し、拒否を解決するための推奨されるコマンド。この例では、
file1
タイプをpublic_content_t
に変更するためのコマンドを提供します。これは Apache HTTP Server および Samba からアクセスできます。 - 追加情報
- バグ報告に役に立つ情報 (ポリシーパッケージの名前やバージョン (
selinux-policy-3.13.1-166.el7.noarch
) ですが、拒否が発生した理由の解決には役立たない場合があります。 - Raw 監査メッセージ
- 拒否に関連付けられた
/var/log/audit/audit.log
からの Raw 監査メッセージ。AVC 拒否に関する詳細は、「Raw 監査メッセージ」 を参照してください。
11.3.8. アクセスの許可: audit2allow
警告
実稼働環境では、このセクションの例を使用しないでください。これは、
aud2allow
ユーティリティーの使用を実証する目的でのみ使用されます。
aud2allow
ユーティリティーは、拒否された操作のログから情報を収集し、SELinux ポリシー許可ルールを生成します。[13] 「sealert メッセージ」に従って拒否メッセージを分析し、ラベル変更やブール値によるアクセスが許可されていない場合は、aud2allow
を使用してローカルポリシーモジュールを作成します。SELinux がアクセスを拒否した場合に、aud2allow
を実行すると、拒否したアクセスを許可する Type Enforcement ルールが生成されます。
audit2allow
を使用して、SELinux 拒否を確認する際に、最初のオプションとしてローカルポリシーモジュールを生成することはできません。トラブルシューティングは、ラベル付けの問題があるかどうかを最初に確認します。2 番目に多いのが、SELinux が、プロセスの設定変更を認識していない場合です。詳細は、Four Key Causes of SELinux Errors のホワイトペーパーを参照してください。
以下の例は、
aud2allow
を使用してポリシーモジュールを作成する例を示しています。
- 拒否メッセージと関連するシステムコールが
/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 メッセージ」に従って拒否メッセージを分析します。ラベル変更やブール値によるアクセスが許可されていない場合は、aud2allow
を使用してローカルポリシーモジュールを作成します。 - 以下のコマンドを入力して、アクセスが拒否された理由を人間が判読できるように説明します。
aud2allow
ユーティリティーは/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 - また、
aud2allow
は、Type Enforcement ルールをポリシーパッケージ (.pp
) にコンパイルします。~]#
ls mycertwatch.pp mycertwatch.teモジュールをインストールするには、root で以下のコマンドを実行します。~]#
semodule -i mycertwatch.pp重要aud2allow
で作成したモジュールは、必要以上のアクセスを許可する場合があります。aud2allow
で作成したポリシーは、アップストリームの SELinux リストに投稿して確認することが推奨されます。 ポリシーにバグがあると思われる場合は、Red Hat Bugzilla でバグを作成します。
複数のプロセスからの拒否メッセージが複数存在し、1 つのプロセスに対してのみカスタムポリシーを作成する場合は、
grep
ユーティリティーを使用して、aud2allow
の入力内容を絞り込みます。以下の例は、grep
を使用して、aud2allow
経由で certwatch
に関連する拒否メッセージのみを送信することを示しています。
~]#
grep certwatch /var/log/audit/audit.log | audit2allow -R -M mycertwatch2
******************** IMPORTANT ***********************
To make this policy package active, execute:
semodule -i mycertwatch2.pp