SELinuxの概要：サードパーティのWebアプリケーション向けのターゲットポリシーの変更

こんにちは同僚！

私たちの多くは、Webプロジェクトの運用サーバーのセットアップに関与しています。 ApacheやNginxの構成方法については説明しません。これについては、私よりもよく知っています。 ただし、フロントエンドサーバーを作成する際の重要な側面の1つは消灯しています。これらはセキュリティサブシステムの設定です。 「Disable SELinux」は、ほとんどのアマチュアガイドの標準的な推奨事項です。 ソフトポリシーモードでセキュリティサブシステムを設定するプロセスは、ほとんどの場合非常に簡単なので、これは急いで決定するように思えます。



今日は、オペレーティングシステムのRed Hat（CentOS）ファミリで使用されるSELinuxセキュリティサブシステムを調整するいくつかの方法について説明します。 例として、CentOSバージョン5.8でApache + mod_wsgi + Django + ZEO Webサーバーのバンドルを構成します。







Linuxセキュリティシステムを構成する場合、随意アクセス制御（DAC）システムのフレームワークに制約されます。 3つのレベル（所有者、グループ所有者など）およびPOSIX ACLのrwxの標準権限を自由に使用できます。 したがって、ユーザー権限を持つアプリケーションは、理論的には、対応するユーザーが利用できるすべてのリソースにアクセスできます。 アプリケーションが危険にさらされると、悲しい結果を招く可能性があります。



SELinux（Security-Enhanced Linux）は、Mandatory Access Control（MAC）を実装するセキュリティサブシステムであり、従来の裁量システムと並行して動作します。 アクセス権は、ポリシーを使用してシステムによって決定されます。 オペレーティングシステムのRed Hat（CentOS）ファミリでは、カーネルの一部としてすぐにSELinuxを入手できます。 タスクの最も簡単なソリューションには、ターゲットポリシー（「ターゲット」）が必要です。これは、一般的なアプリケーションの大部分のルールを記述しています。 特別な努力をせずに、基本的なサービスの基本的な保護を取得します。 ポリシールールは、そこに記載されていないすべてのアプリケーションが、DACのフレームワークでSELinuxからの制限なしに機能するようなものです。



「しかし、なぜ実際にこのSELinuxが必要なのですか？」 答えは非常に簡単です。場合によっては、セキュリティサブシステムは少なくとも不正アクセスを記録することを許可し、理想的にはそれを防ぐことができます。 いずれにせよ、違反者は特定のプロセスのために概説されたフレームワーク内で行動する必要があります。







独自の設定を追加するには、コンテキスト、ドメイン、アクセスベクトルを使用して操作します。 セキュリティ関連のイベントは、カーネルレベルでSELinuxによってインターセプトされます。 セキュリティエンジンのメカニズムは、DACルールの後に有効になります。 SELinuxは、RBAC（ロールベースのアクセス制御）、TE（タイプ強制）、およびオプションでMLS（マルチレベルセキュリティ）機能を提供します。 各システムオブジェクトには、特定のコンテキスト（タイプ）があります。 ポリシーのルールに基づいて、セキュリティサブシステムはこの操作の実行を許可またはブロックし、プロセスはエラーメッセージを受け取ります。 SELinuxによって行われたすべての決定は、Access Vector Cache（AVC）にキャッシュされます。



SELinuxコンテキストには、ユーザー、ロール、タイプ、およびレベルに関する情報が含まれています。 Type Enforcementの属性であるタイプを操作します。 プロセスのドメインとファイルのタイプによって定義されます。 SELinuxルールは、許可されるタイプの対話を記述します。 アクセスは、対応するルールがある場合にのみ許可されます。



それとは別に、ドメイン移行のテクノロジーに注目したいと思います。 SELinuxでは、ソースドメインのプロセスが、新しいドメインのエントリポイントタイプのファイルから開始するアプリケーションを実行する場合、アプリケーションをあるドメインから別のドメインに切り替えることができます。



標準のターゲットポリシーは、200を超えるアプリケーションのコンテキスト、ドメイン、およびアクセスルールを作成および説明します。 ポリシーを拡張し、提案されたコンテキストのフレームワーク内で行動する機会があります。 基本的なポリシーを開発する際、ほとんどすべての主要なユースケースが考慮されました。 標準ソリューションを作成するには、実質的に何も変更する必要はありません。



したがって、テンプレートソリューションを実装する場合、SELinux保護メカニズムの使用を拒否することは少なくとも正当化されません。 追加のソフトウェアをインストールする場合、その使用にはいくつかの困難が生じます。 タスクのコンテキストでは、それらはモジュールmod_wsgiとZEOです。 SELinuxの動作を維持するには、設定を変更する必要があります。



私の例では、CentOS 5.8（カーネル2.6.18-308.1.1.el5）とApache Webサーバー（httpd-2.2.3-63.el5.centos.1）を使用しています。 Python（2.7.2）、Django（1.4）、mod_wsgi（3.3）、およびZope（3.4.0）が追加でインストールされます。 （このソフトウェアの平凡なインストールプロセスは、個別の説明に値しません。）



まず、httpdのSELinuxポリシーを拡張する必要があります。 デフォルト設定は、プロセスが侵害された場合にプロセスを確実に分離することを目的としています。 ただし、プロジェクトへのhttpdアクセスには、いくつかの変更が必要です。 ポリシーの作成者は、コンテキストに制限を加えてアプリケーションの完全なロジックを作成しました。 簡単なコマンドを使用すると、システム上のファイルのマークアップに慣れるのに役立ちます。

semanage fcontext -l | grep httpd

ポリシーは、提示された各タイプへのアクセスを管理します。 コンテキストの完全なリストは、対応するマニュアルページ（ man httpd_selinux ）にあります。 デーモンとスクリプトがファイルにアクセスできるhttpd_sys_content_tタイプに興味があります。 したがって、標準のDAC権限に加えて、プロジェクトのディレクトリとファイルのコンテキストを指定する必要があります。 これは、 chconコマンドを使用して一度に実行できます。

chcon -R -t "httpd_sys_content_t" / your /プロジェクト

ただし、ルールを使用してタイプを設定することをお勧めします。 これにより、新しいファイルを追加するときに後続の自動タイプ割り当てが保証されます。

semanage fcontext -a -t httpd_sys_content_t "/your/project(/.*）？"

restorecon -R / your /プロジェクト

私のデモプロジェクトでは、ZoDBデータベースでDjangoを使用しています。 データベースとの通信手段として、ZEOが使用されます。 これはスタンドアロンソフトウェアであるため、SELinux内で機能するようにする必要があります。 分離を確実にするために、 httpd_tドメインのApacheユーザー権限でZEOを起動することをお勧めします。 これを行うには、デーモンモードで起動開始スクリプトを定義します。 ここでは、スクリプトのサイズが大きいため、スクリプト全体のリストは提供しません。 主なもので十分です。

/ usr / local / bin / zeoctl -d -s / var / run / zeo / zsock -C / etc / zeo / zeoctl.conf start

SELinuxへの後続のタイプ移行中の問題を回避するために、初期化スクリプトを適切なコンテキストに移動する必要があることを忘れないでください。

chcon –t "initrc_exec_t" / etc / init.d / your_init_script

構成ファイルで、必要なユーザーを指定する必要があります。

<ランナー>

プログラム/ usr / local / bin / runzeo -a / var / run / zeo / zeo.socket -f / var / your_db_path / db.fs

デーモン真

ユーザーApache

</ランナー>

ソケットは、ZEOとDjangoの間のリンクとして使用されます。 httpdはhttpd_tドメインで機能するため、アプリケーションが接続できるように、タイプとDAC権限をネゴシエートする必要があります。 これを行うには、ディレクトリ/ var / run / zeoを準備し、それに必要なコンテキストを設定します。 -f -sスイッチを使用してコンテキストの自動割り当てをソケットのみに制限し、-f -dを使用してコンテキストをディレクトリに設定します。

semanage fcontext -a -f -d -t 'httpd_sys_script_rw_t' '/var/run/zeo(/.*）？'

semanage fcontext -a -f -s -t 'httpd_sys_script_rw_t' '/var/run/zeo(/.*）？'

restorecon –R / var /実行

ZEO構成ファイルでは、通信ソケットの強制的な場所を指定する必要があります。

<ゼオ>

アドレス/ var / run / zeo / zeo.socket

</ zeo >

Apacheユーザーの代わりにアプリケーションを実行する予定なので、型の推移性を考慮する必要があります。 タイプhttpd_tを取得するには、実行中のプロセスが必要です。 デフォルトでは、ファイル/ usr / local / bin / zeoctlおよび/ usr / local / bin / runzeoにはbin_tコンテキストがあります。 それらはunconfined_tドメインから呼び出されるため、コンテキスト遷移のチェーンをトレースする必要があります。 まず、 /etc/init.d/からスクリプトが呼び出されます。このスクリプトには、タイプinitrc_exec_tが割り当てられています。 この状況の移行チェーンを見つけます。

sesearch -T -s unconfined_t -t initrc_exec_t | grep "initrc_exec_t"

見つかった遷移チェーンは、 unconfined_t initrc_exec_t：プロセスinitrc_tのように見えます 。 プロセスがinitrc_tコンテキストを受け取ることがわかります。 したがって、今度は必要なタイプのhttpd_tにつながる移行チェーンを見つける必要があります 。

sesearch -T -s initrc_t | grep "プロセスhttpd_t"

検索の結果は、 initrc_t httpd_exec_t：process httpd_t linkになります。 この移行を行うには、 httpd_exec_tコンテキストを実行可能ファイルに設定する必要があります。

semanage fcontext -a -t httpd_exec_t "/ usr / local / bin / zeoctl"

semanage fcontext -a -t httpd_exec_t "/ usr / local / bin / runzeo"

restorecon -R / usr / local / bin

ここで、SELinuxポリシーのhttpdのソケットにソケット許可を追加する必要があります。 これを行うにはいくつかの方法があります。 ユーザーの観点から最も簡単なのは、システムログからのAVCメッセージに基づいてポリシーモジュールを生成できるaudit2allowユーティリティです。 特定のアクションの許可のみを作成するため、ユーティリティは慎重に使用してください-ただし、 詳細なガイドは開発者のWebサイトで提供されています。



2番目の方法は、モジュールを手動で作成し、コンパイルして、現在のポリシーにインストールすることです。 この方法によりプロセスの視覚化が向上するため、この方法でZEO用のモジュールを製造します。 タイプhttpd_sys_script_rw_tのソケットを作成および操作する権限をhttpd_tに付与します。 これを行うには、次の内容のファイル/tmp/httpdAllowDjangoZEO.teを作成します。

モジュールhttpdAllowDjangoZEO 1.0;



require {

タイプhttpd_t;

タイプhttpd_sys_script_rw_t;

クラスsock_fileリンク。

クラスsock_file setattr;

class sock_file create;

class sock_file unlink;

class sock_file write;

}

＃============== httpd_t ===============

httpd_tを許可するhttpd_sys_script_rw_t：sock_fileリンク。

httpd_tを許可httpd_sys_script_rw_t：sock_file setattr;

httpd_tを許可httpd_sys_script_rw_t：sock_file create;

httpd_tを許可httpd_sys_script_rw_t：sock_file unlink;

httpd_tを許可httpd_sys_script_rw_t：sock_file write;

次に、モジュールを作成してコンパイルする必要があります。 これを行うには、 checkmoduleおよびsemodule_packageコマンドを使用します 。 現在のポリシーにモジュールをインストールするには、 semoduleユーティリティが必要です。

checkmodule -M -m -o / tmp / httpdAllowDjangoZEO.mod / tmp / httpdAllowDjangoZEO.te

semodule_package --outfile / tmp / httpdAllowDjangoZEO.pp --module / tmp / httpdAllowDjangoZEO.mod

semodule -i httpdAllowDjangoZEO.pp

最後のアクションは、ZoDBデータベースの保管場所のコンテキストとZEO構成ファイルを構成することです。 その過程で、技術的な.lockファイルを作成する必要があります。 したがって、データベースの保存場所は、ファイルの作成を許可する適切なコンテキストでマークする必要があります。 「 Httpd_sys_script_rw_t 」はこれに適しています。

semanage fcontext –a –t“ httpd_sys_script_rw_t”“ / var / your_db_path （ /。* ） ？”

構成ファイルには特殊なタイプ「httpd_config_t」があります。

semanage fcontext –a –t“ httpd_config_t”“ / etc / zeo （ /。* ） ？”

次に、サービスを再起動して、構成プロセスを完了します。



弊社が作成したルールにより、バンドル全体が問題なく機能します。 同時に、サーバーとそのサービスに追加のSELinux保護を提供します。 DjangoまたはZEOコンポーネントのいずれかが侵害された場合、攻撃者はhttpd_tドメイン内で行動するため、制限され、システムにアクセスできなくなります。



そのため、SELinuxを無効にすることなく、httpdのユーザー設定を機能させることができました。 同様に、アプリケーションの規制ポリシーを作成できます。 これには時間がかかりませんし、深刻な理論的トレーニングも必要ありません。 したがって、SELinuxを無効にしないでください。



SELinuxテクノロジーをより包括的に理解するために、Fedora 13用のSELinuxのロシア語の説明をよく理解することをお勧めします。