第1回 SELinuxのアクセス制御をデータベースでも
海外 浩平
日本SELinuxユーザ会
2007/8/3
各行のセキュリティコンテキストを確認
まず、SE-PostgreSQLに接続してみましょう。
| [kaigai@masu ~]$ psql postgres Welcome to psql 8.2.4, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit postgres=# |
クライアントのセキュリティコンテキストを確認するため、SQL関数の sepgsql_getcon()を実行します。ここで表示されるセキュリティコンテキストは“id -Z”コマンドの表示結果と一致します。
テスト用のテーブルを構築するのに必要ですので、必ず“c0”カテゴリを含むユーザーで接続してください。
| postgres=# SELECT sepgsql_getcon(); sepgsql_getcon ------------------------------------------- user_u:system_r:unconfined_t:s0-s0:c0.c31 (1 row) |
次に、テスト用のテーブルを作成します。以下のSQLを実行してdrinkテーブルを作成してください。
| CREATE TABLE drink ( id integer primary key, name varchar(20), price integer ); INSERT INTO drink VALUES(1, 'water', 100); INSERT INTO drink VALUES(2, 'coke', 120); INSERT INTO drink VALUES(3, 'juice', 120); INSERT INTO drink VALUES(4, 'coffee', 180); INSERT INTO drink VALUES(5, 'beer', 260); INSERT INTO drink VALUES(6, 'wine', 420); |
SE-PostgreSQLでは、各行がセキュリティコンテキストを持っていますが、“security_context”システム列を参照してこれを確認することができます。
| postgres=# SELECT security_context, * FROM drink; security_context | id | name | price ------------------------------------+----+--------+------- user_u:object_r:sepgsql_table_t:s0 | 1 | water | 100 user_u:object_r:sepgsql_table_t:s0 | 2 | coke | 120 user_u:object_r:sepgsql_table_t:s0 | 3 | juice | 120 user_u:object_r:sepgsql_table_t:s0 | 4 | coffee | 180 user_u:object_r:sepgsql_table_t:s0 | 5 | beer | 260 user_u:object_r:sepgsql_table_t:s0 | 6 | wine | 420 (6 rows) |
先ほど挿入した行にはカテゴリは付与されていません。従って、MCSのアクセス制御ではすべてのプロセスがこれらの行に対してアクセス可能となります。
システムのポリシーに従った行レベルアクセス制御
これでは面白くないので、明示的にカテゴリを付与して行レベルのアクセス制御を行ってみましょう。
各行のセキュリティコンテキストを変更するには、“security_context”システム列へのUPDATEやINSERTを実行します。例えばdrinkテーブルのアルコール類（‘beer’と‘wine’）に“c0”カテゴリを付与する場合、以下のようにUPDATE文を実行します。
| postgres=# UPDATE drink SET security_context postgres-# = 'user_u:object_r:sepgsql_table_t:s0:c0' WHERE id IN (5, 6); UPDATE 2 |
再度、“security_context”システム列を確認してみると、これらの行のセキュリティコンテキストが変更されていることを確認できます。
| postgres=# SELECT security_context, * FROM drink; security_context | id | name | price ------------------------------------+----+--------+------- user_u:object_r:sepgsql_table_t:s0 | 1 | water | 100 user_u:object_r:sepgsql_table_t:s0 | 2 | coke | 120 user_u:object_r:sepgsql_table_t:s0 | 3 | juice | 120 user_u:object_r:sepgsql_table_t:s0 | 4 | coffee | 180 user_u:object_r:sepgsql_table_t:s0:c0 | 5 | beer | 260 user_u:object_r:sepgsql_table_t:s0:c0 | 6 | wine | 420 (6 rows) |
では、権限が弱いプロセスからdrinkテーブルにアクセスした場合、どのように見えるのでしょうか。実際に試してみましょう。
いったん、ここでSE-PostgreSQLへのコネクションを切断し、以下のようにして接続を行ってください。
| [kaigai@masu ~]$ runcon -l s0 -- psql postgres Welcome to psql 8.2.4, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit postgres=# |
runconコマンドを用いて、ユーザーが指定した権限でプログラムを実行することができます。もちろん、好き勝手な権限で実行できるわけではなく、セキュリティポリシーで許可された範囲内に限られます。
“-l”オプションではカテゴリを指定することができ、上の例では、すべてのカテゴリを外した状態でpsqlコマンドを実行しています。標準のセキュリティポリシーでは、カテゴリを増加することは禁止されていますが、縮退させることは自由に行うことができます。
| postgres=# SELECT sepgsql_getcon(); sepgsql_getcon --------------------------------- user_u:system_r:unconfined_t:s0 (1 row) |
再びsepgsql_getcon()関数を実行してみると、カテゴリが外れていることが分かります。
この状態で、先ほどのdrinkテーブルを参照してみます。すると、以下のように存在しているはずの‘beer’と‘wine’の行が出力されません。本来はdrinkテーブルには6行が存在するにもかかわらず、クライアントがアクセス可能な4行のみが出力されています。
| postgres=# SELECT security_context, * FROM drink; security_context | id | name | price ------------------------------------+----+--------+------- user_u:object_r:sepgsql_table_t:s0 | 1 | water | 100 user_u:object_r:sepgsql_table_t:s0 | 2 | coke | 120 user_u:object_r:sepgsql_table_t:s0 | 3 | juice | 120 user_u:object_r:sepgsql_table_t:s0 | 4 | coffee | 180 (4 rows) |
これは最もシンプルなSE-PostgreSQLの行レベルアクセス制御の例ですが、もっと複雑な場合、例えばテーブルのJOINなどを含む場合であっても同様に、アクセス権のない行はすべて結果セットからフィルタリングされます。
 |
| 図3 SE-PostgreSQLの行レベルアクセス制御 |
連載第2回では、Type Enforcement（TE）の効果的な利用を中心に、行レベルアクセス制御や監査ログの出力を含む、SE-PostgreSQLのカスタマイズ方法についてご紹介したいと思います。
 |
3/3 |
| Index | |
| SELinuxのアクセス制御をデータベースでも | |
| Page1 SE-PostgreSQLが目指すもの リファレンスモニタの考え方をデータベースにも適用する SE-PostgreSQLを使ってみよう |
|
| Page2 SE-PostgreSQLのアクセス制御を試してみる MCSによるアクセス制御とは semanageコマンドで権限を修正する |
|
 |
Page3 各行のセキュリティコンテキストを確認 システムのポリシーに従った行レベルアクセス制御 |
| Profile |
| 海外 浩平（かいがい こうへい） 日本SELinuxユーザ会 某社でLinuxカーネルの開発・サポートを行うかたわら、SELinux並列実行性能の改善や、組み込み向けファイルシステムのSELinux対応などを行っている。 現在は本業に加えて、IPA未踏ソフトウェア創造事業の支援を受けて、SE-PostgreSQL開発という二足のわらじを履いている日々。 「アンチ事なかれ主義」がモットー、好きな言葉は「前代未聞」。 |
 |
SE-PostgreSQLによるセキュアDB構築 連載インデックス |
- Windows起動前後にデバイスを守る工夫、ルートキットを防ぐ （2017/7/24）
Windows 10が備える多彩なセキュリティ対策機能を丸ごと理解するには、5つのスタックに分けて順に押さえていくことが早道だ。連載第1回は、Windows起動前の「デバイスの保護」とHyper-Vを用いたセキュリティ構成について紹介する。 - WannaCryがホンダやマクドにも。中学3年生が作ったランサムウェアの正体も話題に （2017/7/11）
2017年6月のセキュリティクラスタでは、「WannaCry」の残り火にやられたホンダや亜種に感染したマクドナルドに注目が集まった他、ランサムウェアを作成して配布した中学3年生、ランサムウェアに降伏してしまった韓国のホスティング企業など、5月に引き続きランサムウェアの話題が席巻していました。 - Recruit-CSIRTがマルウェアの「培養」用に内製した動的解析環境、その目的と工夫とは （2017/7/10）
代表的なマルウェア解析方法を紹介し、自社のみに影響があるマルウェアを「培養」するために構築した動的解析環境について解説する - 侵入されることを前提に考える――内部対策はログ管理から （2017/7/5）
人員リソースや予算の限られた中堅・中小企業にとって、大企業で導入されがちな、過剰に高機能で管理負荷の高いセキュリティ対策を施すのは現実的ではない。本連載では、中堅・中小企業が目指すべきセキュリティ対策の“現実解“を、特に標的型攻撃（APT：Advanced Persistent Threat）対策の観点から考える。
 |
|
|
|
|
