Tweet

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

　SE-PostgreSQLでTEを使ってみる

　それでは、TEを使ったアクセス制御を試してみましょう。まず、テーブルをセットアップするためにunconfined_tドメインでSE-PostgreSQLに接続し、以下のSQL文を実行してください。

　各行のセキュリティコンテキストを確認すると、「sepgsql_table_t」というタイプが付与されていることが分かります。

　「sepgsql_table_t」は、SE-PostgreSQL標準セキュリティポリシーで定義済みのタイプで、管理ドメイン、一般ドメインの両方からすべての操作を許可されています。このタイプは新しいテーブル、カラム、行に対して自動的に付与されますが、SE-PostgreSQL標準セキュリティポリシーでは、ほかにも以下の定義済みタイプが提供されています。

　それでは、各行のタイプを変更して、一般ドメインからアクセスが不可能であることを確認してみましょう。

　以下のSQL文を実行し、‘juice’と‘coffee’に「sepgsql_ro_table_t」タイプを、‘beer’と‘wine’に「sepgsql_secret_table_t」タイプを付与します。

　このSQL文を実行すると、以下のようにタイプが更新されていることが確認できます。

　ここでいったん、SE-PostgreSQLへのコネクションを閉じて、一般ドメインで再接続することにします。一般ドメイン用に設定したアカウントでSELinuxにログインし、以下のようにunconfined_t以外のドメインであることを確認してください。

　先ほどのdrinkテーブルを参照すると、「sepgsql_secret_table_t」タイプの行が結果セットからフィルタリングされていることが分かります。

　続いて、drinkテーブルを更新してみます。

　このように、一般ドメインは「sepgsql_ro_table_t」タイプの行を更新することはできません。「sepgsql_table_t」タイプを付与された‘water’と‘coke’の行だけが更新の対象となっています。

　テーブル／カラムに対するアクセス制御

　テーブルやカラムに対するアクセス制御は、SQLクエリーの実行前に実施されます。SQLクエリーで用いられるテーブルやカラムに対して必要な権限を持っていない場合、SE-PostgreSQLはトランザクションをアボートしてSQLの実行を即座に中止します。

　それでは、実際に試してみましょう。まず、テーブルをセットアップするため、管理ドメインから以下のSQL文を実行してください。

　customerテーブルや、id、name、creditの各カラムにはデフォルトの「sepgsql_table_t」タイプが付与されており、参照や更新などすべての操作が許可されています。ここで、creditカラムに「sepgsql_secret_table_t」タイプを付与して、一般ドメインのcreditカラムへのアクセスを禁止してみましょう。

　以下のように、SE-PostgreSQLの拡張ALTER TABLE構文を用いてテーブルやカラムのセキュリティコンテキストを変更することができます。

　セキュリティコンテキストの変更に成功したら、一般ドメインからSE-PostgreSQLに接続し、customerテーブルにアクセスを試してみましょう。

　このようにSE-PostgreSQLは、適切な権限のないカラムを参照するSQLクエリーの実行を中断してエラーメッセージを出力します。

　なお、この場合でもcreditカラムへの参照を含まないSQLクエリーの実行は可能です。

　SQL関数に対するアクセス制御

　テーブルやカラムと同様に、SQL関数の呼び出しに対してもアクセス制御が実施されます。

　SQL関数には表2にあるタイプを付与することができますが、新しく定義したSQL関数に付与されるタイプはドメインによって異なることに気を付けてください。

　管理ドメインがSQL関数を定義すると「sepgsql_proc_t」タイプが付与され、このSQL関数は誰でも実行することが可能です。一方、一般ドメインがSQL関数を定義すると「sepgsql_user_proc_t」タイプが付与されますが、管理ドメインはこのSQL関数を実行することができません（タイプを変更することは可能です）。

　このような振る舞いがSE-PostgreSQL標準セキュリティポリシーで定義されている理由は、一般ドメインは必ずしも信頼できるドメインではないため、誤って管理ドメインが高い権限でそれを実行することを避けるためです。管理ドメインが一般ドメインで定義されたSQL関数を実行するには、それが無害であることを確認し、明示的に「sepgsql_proc_t」にタイプを変更する必要があります。

　では、実際の例を見てみましょう。

　以下のSQL関数は、integer型の引数2つを加算して返却するもので、もちろん無害です。

　一般ドメインでこのSQL関数を定義し、自身が呼び出すことは可能です。

　しかし、管理ドメインがこの関数を実行しようとしても拒否されます。

　管理ドメインは、このSQL関数が無害であり、高い権限の下で実行しても問題ないと判断すれば、SQL関数のタイプを「sepgsql_proc_t」に変更することが可能です。SQL関数のセキュリティコンテキストを変更するには、SE-PostgreSQLの拡張ALTER FUNCTION構文を利用します。

　これによって、管理ドメインがinteger_plus関数を実行することが可能になります。

2/3

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

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

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

RSSフィード