最終回 SE-PostgreSQLの実運用に向けて
海外 浩平
日本SELinuxユーザ会
2007/11/27
Labeled IPsecの動きを確認する
Labeled IPsecの設定が終わったら、クライアント側からサーバ側のSE-PostgreSQLに接続してみましょう。psqlコマンドの-hオプションで接続先のホストを指定します。
| [kaigai@masu ~]$ psql -h 192.168.1.10 postgres |
racoonデーモンの鍵交換プロセスが介在する分、若干接続のレスポンスが低下すると思います。接続できなかった場合は、IPsecの設定とPostgreSQLのクライアント認証の設定を見直してください【注2】。
| 【注2】 SE-PostgreSQL／PostgreSQLともに、デフォルト設定ではネットワーク経由の接続をすべて拒否するようになっています。 外部からの接続を受け付けるには、データベースクラスタ直下のpg_hba.confファイルを編集する必要があります。通常は/var/lib/sepgsql/data/pg_hba.confに配置されています。 例えば192.168.1.0/24ネットワークからの接続に対してパスワード認証を要求する場合には、以下の1行を追加します。
より詳しい情報は、PostgreSQL 8.2.5文書「第20章 クライアント認証」を参照してください。 |
SE-PostgreSQLへの接続が確立したら、SQL関数sepgsql_getcon()を用いて、自分自身のセキュリティコンテキストを確認してみましょう。
| [kaigai@fedora8 ~]$ id -Z system_u:system_r:unconfined_t [kaigai@fedora8 ~]$ psql -q -h 192.168.1.10 postgres Password: postgres=# SELECT sepgsql_getcon(); sepgsql_getcon -------------------------------- system_u:system_r:unconfined_t (1 row) postgres=# |
| リスト4 sepgsql_getcon()でセキュリティコンテキストを確認する |
シェル上でid -Zを実行したのと同様のセキュリティコンテキストが表示されるはずです。ログインシェルのセキュリティコンテキストを標準設定から変更していないにもかかわらず「user_u:user_r:user_t」が表示される場合には、SE-PostgreSQLがクライアント側のセキュリティコンテキストを取得できていません。
Fallback Context の設定
さて、先ほどSE-PostgreSQLがクライアント側のセキュリティコンテキストを取得できないケースに言及しました。これは、Labeled IPsecの設定が正しく行われていない、あるいは設定が行われていない場合です。この場合にクライアントのセキュリティコンテキストとして適用されるのは、Fallback Contextと呼ばれるセキュリティコンテキストで、デフォルトでは「user_u:user_r:user_t」に設定されています。
これを変更するには、設定ファイル/etc/sysconfig/sepostgresqlを作成し、シェル変数SEPGSQL_FALLBACK_CONTEXTにFallback Contextを設定します。
このファイルは起動スクリプトによって参照され、SE-PostgreSQLの起動パラメータとして渡されます。
| SEPGSQL_FALLBACK_CONTEXT="system_u:system_r:unconfined_t" |
| リスト5 /etc/sysconfig/sepostgresqlの内容例 |
SELinux開発者コミュニティでは、Labeled IPsecが設定されていない通信経路からの接続に対して、どのようなセキュリティコンテキストを割り当てるかが議論されました。その中では、接続元のIPアドレスや、接続に利用されているNICごとに、代替のセキュリティコンテキストを付与するということで大まかな方向性が決まったようですが、残念ながら、本稿執筆時点ではまだ利用可能な状態にはなっていません。
ラベル情報付きバックアップ＆リストア
定期的なデータベースのバックアップは、ディスク故障などに対する有効な対処策です。SE-PostgreSQLでもこれは同様ですが、SE-PostgreSQLはテーブル／カラム／行などのデータベースオブジェクトに対してセキュリティコンテキストを関連付けており、バックアップ＆リストアを行った後でも、これが正しく元の状態に復元できていなければ、正しくバックアップ＆リストアが可能であるとはいえません。
オリジナルのPostgreSQLには、pg_dump／pg_dumpallコマンドが同梱されており、ユーザーはこれを利用してデータベースのバックアップを行うことが可能です。しかしながら、この中にはセキュリティコンテキストの情報が含まれていないため、SE-PostgreSQLのデータベースのバックアップにpg_dump／pg_dumpallコマンドをそのまま適用することはできません。
SE-PostgreSQLではpg_dump／pg_dumpallの各コマンドを拡張し、セキュリティコンテキスト付きバックアップの生成を可能にしています。これらのコマンドは/usr/bin/sepgdumpと/usr/bin/sepgdump_allとしてインストールされ、--enable-selinuxオプションによって有効化されます。
 |
| 図3 バックアップ＆リストアにおけるpg_dumpコマンドとsepg_dumpコマンドの比較 |
図3は、オリジナルのpg_dumpコマンドと、SE-PostgreSQLのsepg_dumpコマンドを利用した場合の比較図です。
pg_dumpで生成したバックアップにはセキュリティコンテキストが含まれていないため、リストア時にはすべて新しいテーブルや行にデフォルトのセキュリティコンテキストが付与されます。
一方、sepg_dumpで生成したバックアップにはセキュリティコンテキスト情報が含まれています。これをSE-PostgreSQLにリストアすることは、明示的にセキュリティコンテキストを指定したテーブルの作成や行の挿入と同じ意味を持ちます。従って、セキュリティコンテキスト付きのバックアップをリストアする際には、これらの操作を実行するために十分な権限が必要になることに留意してください。
また、pg_dumpコマンド、sepg_dumpコマンドのどちらを使った場合でも、コマンドを実行したユーザーが読み出すことのできるデータベースオブジェクトだけがバックアップイメージとして出力されます。バックアップといえども、アクセス制御の例外にはなりません。そのため、バックアップ作業はデータベース全体を参照できるだけの権限を持ったユーザーが実行する必要があります。
| [kaigai@masu ~]$ sepg_dump postgres --enable-selinux ： （中略） ： -- -- Name: drink; Type: TABLE; Schema: public; Owner: kaigai; Tablespace: -- CREATE TABLE drink ( id integer NOT NULL CONTEXT = 'system_u:object_r:sepgsql_table_t', name text CONTEXT = 'system_u:object_r:sepgsql_table_t', price integer CONTEXT = 'system_u:object_r:sepgsql_table_t', alcohol boolean CONTEXT = 'system_u:object_r:sepgsql_table_t' ) CONTEXT = 'system_u:object_r:sepgsql_table_t'; ALTER TABLE public.drink OWNER TO kaigai; ： （中略） ： -- -- Data for Name: drink; Type: TABLE DATA; Schema: public; Owner: kaigai -- COPY drink (security_context, id, name, price, alcohol) FROM stdin; system_u:object_r:sepgsql_table_t 1 coke 110 f system_u:object_r:sepgsql_table_t 2 tea 120 f system_u:object_r:sepgsql_table_t 3 juice 150 f system_u:object_r:sepgsql_table_t 4 water 120 f user_u:object_r:sepgsql_table_t:s0:c0 5 wine 340 t user_u:object_r:sepgsql_table_t:s0:c0 6 beer 240 t user_u:object_r:sepgsql_table_t:s0:c0 7 coffee 240 f \. ： |
| リスト6 sepg_dumpによるデータベースダンプの結果 |
上記の出力結果は、sepg_dumpコマンドに--enable-selinuxオプションを付けてデータベースをダンプしたものの一部です。テーブルや各行のセキュリティコンテキストがデータとともに出力されていることが分かります。
| 【関連記事】 スイッチ・オン！ SELinux 第2回 SELinuxでいろいろバックアップ／リストアしてみた http://www.atmarkit.co.jp/fsecurity/rensai/selinux202/selinux01.html |
 |
2/3 |
 |
| Index | |
| SE-PostgreSQLの実運用に向けて | |
| Page1 ネットワーク越しのSE-PostgreSQL接続 Labeled IPsecの設定 |
|
 |
Page2 Labeled IPsecの動きを確認する Fallback Context の設定 ラベル情報付きバックアップ＆リストア |
| Page3 気になるSE-PostgreSQLのパフォーマンス ユーザーの声が、次の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）対策の観点から考える。
 |
|
|
|
|
