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. 拒否の検索と表示

本セクションでは、setroubleshootsetroubleshoot-serverdbus、および audit パッケージがインストールされ、auditdrsyslogd、および setroubleshootd デーモンが実行していることを前提としています。これらのデーモンの起動方法は、「どのログファイルが使用されるか」 を参照してください。ausearchaureport、および 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 がアクセスを拒否したときに警告が表示されます。
AVC 拒否メッセージ
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 エントリーは、ターゲットファイルのステータス情報をソースプロセスが読み取ろうとしていることを示します。これは、ファイルを読み取る前に発生します。アクセスしているファイルのラベルが間違っているため、このアクションは拒否されています。一般的に表示されるパーミッションには、getattrreadwrite などが含まれます。
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 など、実行中のプロセスの特性を変更するシステムサービスを実行しようとする場合)。また、プロセスが通常の制限よりも多くのリソース (メモリーなど) を使用しようとすると、tcontextscontext に一致する可能性があります。その結果、そのプロセスがこれらの制限を破ることが許可されているかどうかを確認するためのセキュリティーチェックが行われます。
システムコール (SYSCALL) メッセージでは、以下の 2 つの項目が重要になります。
  • success=no: 拒否(AVC)が強制されたかどうかを示します。success=no はシステムコールが成功しなかった(SELinux がアクセスを拒否した)ことを示します。success=yes はシステムコールが成功したことを示します。これは、unconfined_service_tkernel_t など、Permissive ドメインまたは制限のないドメインで見ることができます。
  • exe="/usr/sbin/httpd": プロセスを開始した実行ファイルのフルパスです。この例ではexe="/usr/sbin/httpd" です。
ファイルタイプは、SELinux によるアクセスを拒否する一般的な原因です。トラブルシューティングを開始するには、ソースコンテキスト (scontext) をターゲットコンテキスト (tcontext) と比較します。プロセス (scontext) がこのようなオブジェクト (tcontext) にアクセスする必要がありますか ?たとえば、Apache HTTP Server(httpd_t) は、httpd_sys_content_tpublic_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 を使用してポリシーモジュールを作成する例を示しています。
  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)
    
    この例では、certwatchvar_t タイプのラベルが付けられたディレクトリーへの書き込みアクセスを拒否します。「sealert メッセージ」に従って拒否メッセージを分析します。ラベル変更やブール値によるアクセスが許可されていない場合は、aud2allow を使用してローカルポリシーモジュールを作成します。
  2. 以下のコマンドを入力して、アクセスが拒否された理由を人間が判読できるように説明します。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 ルールがないため、アクセスが拒否されました。
  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. また、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


[10] ausearch の詳細は、ausearch(8) の man ページを参照してください。
[11] aureport の詳細は、aureport(8) の man ページを参照してください。
[12] sealert の詳細は、sealert(8) man ページを参照してください。
[13] aud2allow の詳細は、audit2allow(1) man ページを参照してください。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.