まあ、様々な記事や映像を探してみました。彼らはすべて同じ基本を言います。つまり、デフォルトポリシーで始まり、許可モードで実行して変更する必要があることを確認します。次に、戦略を修正して潜在的な問題を解決します。その後、再び厳格な施行を開始します。
ausearchこの参照では、彼らはより単純化されたバージョンのaudit.logを得るために実行を提案しました。だから私は次のレポートを試しました。
type=PROCTITLE msg=audit(03/27/2015 02:58:34.764:439) : proctitle=/bin/sh
type=SYSCALL msg=audit(03/27/2015 02:58:34.764:439) : arch=x86_64 syscall=getxattr success=no exit=-61(No data available) a0=0x1fef030 a1=0x7fc0dbf2ef9f a2=0x7fff6aaa1da0 a3=0x84 items=0 ppid=1 pid=3861 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=systemd-logind exe=/lib/systemd/systemd-logind subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(03/27/2015 02:58:34.764:439) : avc: denied { getattr } for pid=3861 comm=systemd-logind name=kvm dev="devtmpfs" ino=11755 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:kvm_device_t:s0 tclass=chr_file permissive=1
特に何百ものメッセージに触れると、このメッセージが何を言っているのかを知ることは困難です。
結果ausearchをaudit2allow。これは、確認ボックスが表示されるたびに受け入れボタンを押すのと同じです。また、メッセージが侵入しようとするハッカーではなくバグが原因であると仮定します。
それでは、SELinux許可モードの「出力」を分析する合理的な方法を提案できる人はいますか？
ベストアンサー1
何度も何らかの情報を受け取り、あなたの目的に関連する情報を選ぶ必要があります。たとえば、straceプログラムを作成するときに大量の出力があり、出力を表示する理由に関連する部分にのみ焦点を当てますstrace。
監査ログは同様の原則に従います。あなたのものを見てみましょう：
タイプ=PROCTITLE msg=audit(2015/03/27 02:58:34.764:439): proctitle=/bin/sh
それほど面白くないです。これはタイムスタンプと実行可能ファイルの値proctitle（通常はプロセス名）を提供します。しかし、logindこれがなぜプログラムのタイトルなのかはわかりません。
type=AVC msg=audit(03/27/2015 02:58:34.764:439) : avc: pid=3861 comm=systemd-logind name=kvm dev="devtmpfs" ino=11755 scontext=system_u の { getat拒否 :system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:kvm_device_t:s0 tclass=chr_file権限=1
これは実際のSELinuxエラーメッセージであり、最も心配する必要があるものです。それがtype=AVCまさにそれです。AVC代表するaccess vector cache これはSELinuxコンポーネントです。。
注目すべき重要な部分は、deniedそのセクション（この場合getattr）の内容であり、プログラムが拒否されるために具体的に行われたことを示します。次に、scontextアイデアを提供するソースコンテキスト（別名）を調べます。一般カテゴリこの場合、コンテキスト全体はsystem_u:system_r:system_dbusd_t実質的な部分（99％）に短縮されますsystem_dbusd_t。私たちが得たターゲットコンテキストに対して同じことをしますkvm_device_t。commフィールドはpid非常に重要で明確です。systemd-logindPID 3861を使用して実行されているプログラムで例外が発生します。
だから一緒に集めてください。systemd-logindcontextがあるファイルに対してsystem_dbusd_tいくつかのタスクを実行して実行しようとしています。getattrkvm_device_t
管理者は、これが何を意味するのか、何をすべきかを知っています。 SELinuxは、そのポリシーがそのようなことを許可しないことを知っているので、ユーザーが直接呼び出すことができるように詳細を提供します。
type=SYSCALL msg=audit(03/27/2015 02:58:34.764:439) : arch=x86_64 syscall=getxattr 成功=no exit=-61 (利用可能なデータなし) a0=0x1fef030 a1=0x7af = 0x84エントリ=0 ppid=1 pid=3861 auid=設定解除 uid=ルート gid=ルート euid=ルート suid=ルート fsuid=ルート egid=ルート sgid=ルート fsgid=ルート tty=(なし) ses=設定解除 comm= systemd-logind exe=/lib/systemd/systemd-logind subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null)
表現方式がちょっとずれていましたが、どのように読まなければならないのか理解しやすいので後で入れます。これはtype=AVC重要な部分ですが、通常失敗した実際のシステムコールを記録するので、詳細を得ることができます。
たとえば、プログラム名が与えられたら、systemd-logindそれが何であるかを知ることができますが、名前がより曖昧である場合、exe=/lib/systemd/systemd-logindどのプログラムがエラーを引き起こすかを確認できます。auid（loginuidプロセスの）または（プロセスの）などの情報は、問題の実行可能ファイルが起動された理由がわからない場合でも便利な情報になる可能性があります。uid
お役に立てば幸いです。質問がある場合は、回答を更新します。
編集する：最後のポイントについてもう一つ。一般に、audit2allowポリシーが作成する内容を調べて、ポリシーに応じた変更を理解できます。ポリシーモジュールを挿入するまで、実際に変更は適用されません。したがって、これを生成してからテキストエディタで表示し、それが発生することを許可したいことを確認できます。直接読むよりも詳細を追跡する方が速いかもしれませんaudit.log。