Linux勧告ウォッチ - 2005年12月9日(金)
ポリシー開発環境を準備し、SELinuxポリシーをコンパイルできるようになったら、システムログの監査メッセージを修正したり、使用するアプリケーションで必要なアクセス許可を有効にしたりするようにポリシーを変更できる。
当該ローカルシステムのみに適用するセキュリティ・ポリシー・ステートメントを追加する場合、ソースファイルを作成する必要がある。既存のファイルにステートメントを追加したのでは、ポリシー更新時に上書きされてしまうからだ。ローカルファイルを作成するには、以下のコマンドを使用する。
touch /etc/selinux/engarde/src/policy/policy/modules/admin/local.fc
touch /etc/selinux/engarde/src/policy/policy/modules/admin/local.te
touch /etc/selinux/engarde/src/policy/policy/modules/admin/local.if
次に、/etc/selinux/engarde/src/policy/policy/modules.confファイルを編集してlocal = baseという行を追加し、ファイルを保存する。ポリシーを再コンパイルし、出力結果でlocal.*ファイルが含まれていることを確認する。
たとえば、WebサイトにインストールしたPHPスクリプトがpermissiveモードでは適切に動作するが、enforcingモードを有効にすると失敗し、その原因は、SELinuxで許可されていない操作をそのスクリプトが行おうとすることだとする。
この場合、まず、サーバのターミナルをオープンし、sysadm_rロールにログインしていることを確認してから、以下のコマンドを実行する。
# setenforce 0
# dmesg -c
# watch audit2allow -d
これによって、どのSELinuxアクセス許可が不足しているかをリアルタイムで確認できる。audit2allowコマンドは、SELinuxで発生する問題のトラブルシューティングでは最も有効な手段だ。-dスイッチを付けて実行すると、dmesg出力からSELinux監査エラーをモニタし、それらのエラーを自動的に適切なallowコマンドに変換する。これをポリシーに追加すると、拒否された操作が許可されるようになる。
これらのコマンドを実行した上でシステムをpermissiveモードで実行し、問題となっているアプリケーション操作を実行すると、audit2allowターミナルからallowステートメントの出力が開始される。出力されるステートメントをまず確認する。ファイルのラベル付けが不適切なせいで安全でないステートメントが出力されたり、また過剰な許可を与えるステートメントだったりする場合もあるので、チェックが必要だ。
たとえば、audit2allow出力が、etc_t typeへのフルの読み取り/書き込みアクセスをアプリケーションに与えることを提示する場合も考えられる。この場合、/etcディレクトリに含まれている多数の他のアプリケーション用ファイルへの書き込みが可能になってしまい、安全ではなくなる。ポリシーを正しくデザインするには、そのアプリケーションが実際に使用するファイルの種類を厳密な狭い範囲に変更し、その新しい種類のファイルに対してのみ書き込みアクセスを許可することが必要だ。
どのファイルがアクセスされるか不明の場合は、システムログで実際の拒否メッセージを確認してみる。拒否メッセージの体裁は以下の例のようになっている。
Oct 19 14:38:54 paxtest kernel: audit(1129747134.276:0): avc: denied { read } for name=messages dev=hda6 ino=2146393 scontext=root:staff_r:staff_t tcontext=system_u:object_r: var_log_t tclass=file
拒否メッセージ内のinoエントリは、この拒否メッセージの対象となるファイルのinodeを示している。このファイルは、以下のようなfindコマンドを使って見つけることができる。
# find / -inum 2146393
ファイルに異なるファイルコンテキストを割り当てる必要がある場合は、$policy/policy/modules/admin/local.fcを編集する。.fcファイルには、ファイルの完全パスに一致する正規表現のリストと、再ラベル付けのときにそのファイルに割り当てるセキュリティコンテキストが含まれる。.fcファイルがどのように使用されるかについては、他の既存の.fcファイルを参考にするとよい。新しいコンテキストをファイルに割り当てたら、再コンパイルと再ラベル付けを行ってから、アプリケーションテストを再度実行すると、新しいコンテキストを反映した新しいallowステートメントのリストが生成される。
記事全文:
http://www.linuxsecurity.com/content/view/120837/49/
Debian | ||
Debian:gdk-pixbufパッケージの複数の弱点の修正 | ||
2005年12月1日
|
||
Debian:horde2パッケージのクロスサイト・スクリプティングの修正 | ||
2005年12月1日
|
||
Debian:helix-playerパッケージの任意のコード実行に対する修正 | ||
2005年12月2日
|
||
Debian:Inkscapeパッケージの任意のコード実行に対する修正 | ||
2005年12月7日
|
||
Debian:courierパッケージの不正なアクセスの修正 | ||
2005年12月8日
|
||
Gentoo | ||
Gentoo:Perlのフォーマット文字列エラーに起因するコード実行 | ||
2005年12月7日
|
||
Gentoo:WebminとUserminのフォーマット文字列の弱点 | ||
2005年12月7日
|
||
Mandriva | ||
Mandriva:eagle-usbパッケージのファームウェア・ロード問題の修正 | ||
2005年12月2日
|
||
Mandriva:spamassassinパッケージの弱点の修正 | ||
2005年12月2日
|
||
Mandriva:mailmanパッケージの複数の弱点の修正 | ||
2005年12月2日
|
||
Mandriva:webminパッケージのフォーマット文字列の弱点の修正 | ||
2005年12月2日
|
||
Red Hat | ||
RedHat:重要:xpdfのセキュリティ更新 | ||
2005年12月6日
|
||
RedHat:中:libc-clientのセキュリティ更新 | ||
2005年12月6日
|
||
RedHat:中:imapのセキュリティ更新 | ||
2005年12月6日
|
||