第2回 データベース強制アクセス制御をカスタマイズする

海外　浩平
日本SELinuxユーザ会
2007/9/4

セキュアOSの機能を利用し、ファイルやプロセスと同じようにデータベースのレコードにもアクセス制御ポリシーを適用できるSE-PostgreSQL。今回はType Enforcementを利用してアクセス制御をカスタマイズする方法を体験する（編集部）

---

　OSとデータベースのアクセス制御ポリシーを一元化する

　第1回では、SE-PostgreSQLのインストールとMCS（Multi Category Security）による行レベルアクセス制御についてご紹介しました。今回は、用途に応じたSE-PostgreSQLのカスタマイズ方法を中心に解説を進めていきたいと思います。

　「情報」をコンピュータに格納する方法の違い、すなわち、ファイルに保存するのか、データベースのレコードとして保持するのかという違いによって、アクセス制御ポリシーまで異なるのは望ましいことではない、というのがSE-PostgreSQLの設計思想でした。

　SE-PostgreSQLでは、OSとデータベースのアクセス制御ポリシーを一元化するため、データベースオブジェクトへのアクセス制御にSELinuxのセキュリティポリシーを適用しています。SELinuxではType Enforcement（TE）、Role Based Access Control（RBAC）、MLS／MCSという異なる方法でアクセス制御ルールを記述できますが、SE-PostgreSQLでもこれは同様です。

　第1回ではMCSを用いた行レベルアクセス制御を紹介しましたが、今回はSE-PostgreSQLをより効果的にカスタマイズするための方法として、TEに基づいたタイプの変更と、boolean（条件変数）の設定方法をご紹介します【注1】。

【注1】 なお、今回の記事では2007年9月にリリースされたSE-PostgreSQL 8.2.4-1.0の標準セキュリティポリシーを前提としています。今後のリリースで変更となる可能性もありますのでご了承ください。

　最も詳細なアクセス制御を実現するType Enforcement

　TEは、SELinuxでの中心的なアクセス制御方式で、最も詳細なアクセス制御を行うことができます。その一方で、その詳細さはしばしばSELinuxが複雑で難解だという評判の元凶にもなってきました。

　しかし、最近では標準のセキュリティポリシーにも改善が加えられ、スクラッチからセキュリティポリシーを作成するという場合を除けば、用途に応じて定義済みのタイプを付与することで必要なアクセス制御を実施することが可能です。

　SE-PostgreSQLでもこれは例外ではありません。標準セキュリティポリシーでは、データベースオブジェクトの種類に応じて何種類かのタイプがすでに定義済みで、データベース管理者がテーブルやカラムに適切なタイプを付与することで、一般ユーザーの「アクセス拒否」や「改ざん不可能」というアクセス制御の実施が可能です。

　「誰が」「何に」「何をする」――TEのアクセス制御方式

　まず、TEのアクセス制御方式を説明します。

　プログラムが何らかのリソースにアクセスを行う場合、そこにはすべて「誰が（Subject）」「何に（Object）」「何をする（Action）」という関係が存在します。例えば、httpdプロセスがHTML文書をディスクから読み出す場合、この操作を「httpdプロセス」が「HTML文書」に対して「read()システムコール」を呼び出す、と分解することができます。

　TEでは「誰が」「何に」「何をする」組み合わせのうち、許可するものだけを明示的にセキュリティポリシーに記述します。それ以外の組み合わせはすべて実行を拒否するホワイトリスト的な動作をします。

　論理的には、これは巨大なアクセスマトリックスの各要素を埋めていくのと同義です。

図1　アクセスマトリックスの概念図

　SELinuxでは、すべてのプロセスやリソースのセキュリティ属性は、セキュリティコンテキストという形式で抽象化されていたことを思い出してください。セキュリティコンテキストは“:”で4つのフィールドに分割することのできる文字列で、TEではタイプと呼ばれる3番目のフィールドを利用してプロセスやリソースを識別します【注2】。

【注2】 プロセスに付与されたタイプのことを、その論理的な意味合いから特別に「ドメイン」と呼びます。

プロセスのセキュリティコンテキストの表示例 [root@masu ~]# ps -Z LABEL                                                                PID     TTY   TIME      CMD root:system_r:unconfined_t:SystemLow-SystemHigh 10880 pts/3 00:00:00 bash root:system_r:unconfined_t:SystemLow-SystemHigh 10910 pts/3 00:00:00 ps ファイルのセキュリティコンテキストの表示例 [root@masu ~]# ls -Z /var/log/messages -rw------- root root system_u:object_r:var_log_t /var/log/messages

　上記の例では、bashシェルプロセスのドメインは「unconfined_t」であり、/var/log/messagesファイルのタイプは「var_log_t」ということが分かります。

　ドメイン遷移とは

　通常、プロセスのセキュリティコンテキストは親プロセスのそれを継承します。従って、bashなどのシェルから起動されたプログラムは、シェルと同一のセキュリティコンテキストを持ち、それはさらに孫プロセスにも継承されます。

　しかし、Linuxにおいては/sbin/initプロセスがすべての起点となっています。単純に親プロセスのセキュリティコンテキストを継承するだけでは、すべてのプロセスが同一のセキュリティコンテキストを持つことになり、意味のあるアクセス制御を行うことができません。

　ドメイン遷移はこれを回避する方法の1つで、execve()システムコールの実行時に、プロセスのドメイン（セキュリティコンテキストの一部）を変更するものです。新しいドメインは、元のドメインとプログラムのタイプの組み合わせによって一意に決定されます。

図2　ドメイン遷移の概念図

　図2はブートプロセスの過程を単純化したものですが、ドメイン遷移の繰り返しによってサーバプロセスが適切なドメインの下で動作していることが分かります。例えば、Webサーバはシステム初期化スクリプト（initrc_tドメイン）が/usr/sbin/httpd（httpd_exec_t）を実行することによって、httpd_tドメインで動作することになります。

　ドメイン遷移はプログラムの種類に応じた適切な権限の切り替えを可能にします。SE-PostgreSQLにおいては、Trusted Procedureという形でドメイン遷移を提供しており、局面に応じた柔軟な権限の切り替えが可能になります。

　SE-PostgreSQLとクライアントのドメイン

　SE-PostgreSQLの標準セキュリティポリシーでは、unconfined_tドメインを「管理ドメイン」として、少数の例外を除きすべての操作を許可しています。一方、それ以外のドメインは「一般ドメイン」として、詳細なアクセス制御を適用しています。

　以降の説明では、上記の意味で「管理ドメイン」「一般ドメイン」の用語を使用します。

　Fedora 7では、ユーザーのログインシェルはunconfined_tドメインで動作します。これを変更する方法は「参考情報：ログイン時のドメインを変更する」を参照してください。

1/3

Index
データベース強制アクセス制御をカスタマイズする
	Page1 OSとデータベースのアクセス制御ポリシーを一元化する 最も詳細なアクセス制御を実現するType Enforcement 「誰が」「何に」「何をする」――TEのアクセス制御方式 ドメイン遷移とは SE-PostgreSQLとクライアントのドメイン
	Page2 SE-PostgreSQLでTEを使ってみる テーブル／カラムに対するアクセス制御 SQL関数に対するアクセス制御
	Page3 Trusted Procedureの設定 条件変数booleanによるポリシーのカスタマイズ

SE-PostgreSQLによるセキュアDB構築 連載インデックス

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）