同僚、SElinuxに関する記事の
最初の部分で 、SELinuxシステムを操作する主な機能を調べました。 約束どおり、ポリシーの設定に焦点を当てた第2部を公開しています。 さあ、始めましょう。
SELinuxポリシーのカスタマイズ
ポリシー自体を完全に変更することなく、SELinuxポリシーに若干の変更を加えることができます。 これを行うには、ポリシーで定義されている追加機能に関連付けられた論理値を変更するだけで十分です。 これらの機能により、たとえば、Sambaを使用してユーザーのホームディレクトリへのアクセスを提供したり、Apacheがホームディレクトリにあるファイルを使用したりできます。
デフォルトでは、これらの機能は無効になっています。 これらの機能のリストは事前定義されており、システム管理者が直面する最も頻繁に使用されるタスクで構成されています。
システムで使用可能なすべての機能を表示するには、次のコマンドを実行します。
パラメーターを変更するには、setseboolコマンドを使用する必要があります。 たとえば、HTTPDサービスモジュールとスクリプトがネットワークに接続できるようにするには、コンソールに次のように入力します。
audit2allowを使用してカスタムポリシーを作成する
事前定義された機能が十分にない場合、既存のポリシーに新しいモジュールを追加し、何かへのアクセスを提供する特定の条件を手動で書き留める必要がある場合に、状況が発生することがあります。 たとえば、SMTPメールサーバーにPostgreyアドオンをインストールします。 私たちのサーバーはUnixソケットを介してPostgreyと対話する必要がありますが、メールサーバーの標準SELinuxポリシーはこれを許可せず、ソケットを介した通信の試行をブロックします。
そのような状況では、ファイルのコンテキストを変更しても役に立たず、追加の機能はありません。これにより、状況を修正できます。 もちろん、「問題のある」サービスに対してはいつでもSELinuxを無効にすることができますが、メールサーバーがいつかハッキングされる可能性はゼロではないため、このソリューションはもちろん理想とはほど遠いものです。
そのため、SELinuxをPermissiveモードにして、メールサーバーを起動します。 しばらくすると、AVCメッセージがSELinuxログに表示され、サーバーのすべての無効なアクションが記録されます。
type=AVC msg=audit(1218128130.653:334): avc: denied { connectto } for pid=9111 comm="smtpd" path="/var/spool/postfix/postgrey/socket" scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1218128130.653:334): avc: denied { write } for pid=9111 comm="smtpd" name="socket" dev=sda6 ino=39977017 scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=system_u:object_r:postfix_spool_t:s0 tclass=sock_file
これで、audit2allowユーティリティを使用して、必要なすべてのPostgreyアクションを許可するローカルポリシーの一連のルールを生成できます。
そのため、audit.logファイルがフィルタリングされ、現在のSELinuxポリシーの観点から、Postgreyによって実行されたすべての無効なアクションが抽出されていることがわかります。 これらの手順を確認した後、SMTPサーバーがUnixソケットを使用して接続を作成しようとしており、Postgreyがこのソケットをリッスンしようとしていることがわかります。 この情報を取得し、これらのアクションを許可するSELinuxポリシー用のユーザーモジュールをベースに作成することは非常に論理的なようです。
次に、このモジュールをロードし、semoduleコマンドを使用して、既に含まれているポリシーでそれらを補完する必要があります。
その後、モジュールは/etc/selinux/targeted/modules/active/modules/postgreylocal.ppに移動されます。
モジュールが正しくロードされているかどうかを確認するには、「semodule -l」コマンドを使用して、ロードされているすべてのモジュールのリストを表示できます。
その後、SELinuxを引き続き監視して、新しく作成されたポリシーがPostgreyを制限しないことを確認できます。 ポリシーの正しい操作に満足し、自信が持てたらすぐに、強制モードを再度アクティブにできます。これにより、メールサーバーが確実に保護され、同時に完全に機能するようになります。
SELinuxポリシーのモジュールの手動構成。
Adit2allowは、間違いなく、特定の問題を解決するポリシーのモデルの作成に対応しています。 ただし、このユーティリティが正しく機能しない場合があるため、モジュールを手動で構成する必要があります。 たとえば、SELinux AVCログエントリを考えます。
Summary: SELinux is preventing postdrop (postfix_postdrop_t) "getattr" to /var/log/httpd/error_log (httpd_log_t). Detailed Description: SELinux denied access requested by postdrop. It is not expected that this access is required by postdrop and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /var/log/httpd/error_log, restorecon -v '/var/log/httpd/error_log' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/
audit2allowを実行し、結果のpostfixlocal.teポリシーを確認すると、次のように表示されます。
質問がすぐに発生します。PostDropが/ var / log / httpd / error_logにアクセスしようとするのはなぜですか？ これはこのプログラムに期待できるアクションではないため、このアクションを許可するかどうかを判断するのは私たち次第です。
この問題を解決する方法はいくつかあります。
-このエラーを無視して、SELinuxがファイルへのアクセスをブロックできるようにすることができます。
-audit2allowを使用して適切なポリシーモジュールを作成することにより、このアクションを有効にできます。
-このモジュールのファイルを手動で編集して、ファイルへのアクセス試行に対する望ましいSELinux応答を決定できます。 たとえば、アクセスをブロックしている間、このイベントの監査を禁止できます。 これを行うには、対応する行の「allow」値を「dontaudit」に変更する必要があります。
編集したポリシーモジュールを手動でコンパイルしてロードする必要があります。
したがって、ファイル/ var / log / httpd / error_logへのアクセスはブロックされますが、SELinuxからこれに関する一定の警告を受け取りません。
実際、SELinuxについてはこれですべてです。以降の記事では、rpmディストリビューションのLinuxでのディスククォータなど、興味深い（そして、できれば便利な）トピックを検討します。 新しい記事は月曜日に公開されます。