第1回 SELinuxのアクセス制御をデータベースでも
海外 浩平
日本SELinuxユーザ会
2007/8/3
セキュアOSを実務で使うことに食指が動かない理由は、もしかしたら「キラーアプリの不在」なのではないだろうか。本連載では「日本のセキュアOSを支える5つのプロジェクト」でも取り上げられている、セキュアOSのキラーアプリになりうる可能性を秘めた日本発の拡張機能「SE-PostgreSQL」を紹介する。（編集部）
SE-PostgreSQLが目指すもの
情報システムのセキュリティを確保するうえで、アクセス制御はその中核となる技術です。
身近なところでは、ファイルの所有者とパーミッションによるアクセス制御はその典型例ですし、データベースに対してはSQLのGRANT／REVOKE構文を用いてアクセス制御リスト（ACL）を設定することができます。
しかし、これらの機能は各コンポーネントが独立に提供しているために、互いのアクセス制御ポリシーの一貫性を保証することができません。例えば、OS上のユーザー権限と、そのユーザーがデータベースにログインした際のデータベースユーザー権限には、一般的には何の関係もありません。
システムに格納されている「情報」を不正なアクセスから保護するという視点で考えると、アクセス制御ポリシーが「情報」の格納方法、すなわちファイルシステム上に保持されているのか、それともデータベース上に保持されているのかという違いに影響されるのは好ましいことではありません。
 |
| 図1 システム全体を統括するアクセス制御 |
本連載でご紹介する「SE-PostgreSQL」は、OS（SELinux）の機能を利用してデータベースにアクセス制御を行う、PostgreSQLのセキュリティ拡張機能です。
SE-PostgreSQLは、SELinuxがファイルやソケットなどOS管理下のリソースに対して実施しているのと同様に、テーブルやカラムなどのデータベースオブジェクトに対してSELinuxセキュリティポリシーに基づいたアクセス制御を行っています。
このアクセス制御は既存のPostgreSQLのものとは独立に実施され、双方の許可がなければクライアントはデータベースオブジェクトにアクセスすることはできません。この関係は、ファイルシステム上での伝統的UNIXアクセス制御とSELinuxの強制アクセス制御の関係に類似しています。
加えてSE-PostgreSQLは、行レベル／列レベルを含む「細粒度アクセス制御」と、データベースの特権ユーザーであっても回避不可能な「強制アクセス制御」という特長も有しています。
リファレンスモニタの考え方をデータベースにも適用する
SE-PostgreSQLの説明の前に、そのベースとなっているSELinuxのアクセス制御方式について触れておきたいと思います。
一言でいえばSELinuxとは、Linuxカーネルに対するリファレンスモニタの実装です。リファレンスモニタとは、システム管理下のリソースに対する外部のソフトウェアからのアクセス要求を許可すべきか、それとも禁止すべきかの意思決定を行うモジュールで、セキュリティ分野では長い歴史のある概念です。このモジュールは回避不可能（always-invoked）、改ざん不可能（tamperproof）、検証可能（small enough）という3つの条件を満たしている必要があります。
Linuxカーネルに対する唯一のアクセス要求の方法は、システムコールの発行です。そして、SELinuxはシステムコールの実行をフックし、セキュリティポリシーがそれを許可しているかどうか検証を行います。これはすべてのユーザーにとって回避不可能で、root権限を持つユーザーに対しても例外なく実施されます。
また、カーネルの一部として静的にビルドされたSELinuxは改ざん不可能であり、そのコード規模は1万行程度ですが、全部で800万行の規模があるLinuxカーネルと比較すると、十分に小さく検証可能なレベルであるといえるでしょう。
SE-PostgreSQLは、リファレンスモニタの考え方をデータベース管理システム（PostgreSQL）に適用したものです。
外部のソフトウェアがテーブルやカラムなど、データベース管理システムの管理下のリソースにアクセスするにはSQLを使用します。そして、SE-PostgreSQLはすべてのSQLの実行をフックし、カーネルのSELinuxに問い合わせてセキュリティポリシーがそれを許可しているか否か検証を行います。
このプロセスは、SELinuxがシステムコールに対して行っているものと同じです。アプリケーション自身がリファレンスモニタの機能を実装することで、SELinuxの適用範囲はカーネルだけでなく、ユーザー空間にも広がりつつあります。
SE-PostgreSQL以外の実装としては、ウィンドウなどX Windowのオブジェクトに対するアクセス制御を行うXACE／SELinuxがあり、これはすでにXorgの正式な機能として統合されています。
 |
| 図2 全てのSQLクエリーがセキュリティポリシーによる検査を受ける |
SE-PostgreSQLを使ってみよう
それでは、実際にSE-PostgreSQLをインストールして使ってみましょう。
| 【注】 本記事の執筆時点ではsepostgresql-8.2.4-0.407.betaが最新版で、このバージョンをFedora 7システムへ導入することを前提にして解説します。 |
SE-PostgreSQLのインストールに必要なのは、SE-PostgreSQL自身のRPMパッケージと、SE-PostgreSQL対応のセキュリティポリシーです。SE-PostgreSQL開発チームはFedora 7／Fedora core 6システム用のRPMパッケージを提供しており、これらはSE-PostgreSQLプロジェクトのサイトからすべてダウンロードすることができます。
最初に、インストールに必要な以下の3つのRPMパッケージの最新版を入手してください。
- sepostgresql
- selinux-policy
- selinux-policy-targeted
続いて、この3つのRPMパッケージをインストールします。SE-PostgreSQL対応版のselinux-policyおよびselinux-policy-targetedは、標準のものを置き換えることになるため、rpm -U（アップデート）を使用します。
|
[root@masu ~]# rpm -Uvh selinux-policy-2.6.4-29.sepgsql.fc7.noarch.rpm \ selinux-policy-targeted-2.6.4-29.sepgsql.fc7.noarch.rpm \ sepostgresql-8.2.4-0.407.beta.fc7.i386.rpm Preparing... ################################# [100%] 1:selinux-policy ################################# [ 33%] 2:selinux-policy-targeted################################# [ 67%] 3:sepostgresql ################################# [100%] |
| 【注】 Fedora標準のpostgresqlおよびpostgresql-libsパッケージも必要です。 未導入であれば、これらのパッケージをFedoraのミラーなどから取得してインストールしてください。これらのパッケージには、psqlコマンドやlibpq.so.5ライブラリが含まれています。 |
インストールしたSE-PostgreSQL対応版のセキュリティポリシーが、パッケージの自動更新によって標準のセキュリティポリシーに置き換えられることを避けるため、yumの設定ファイル（/etc/yum.conf）に以下の1行を追加します。「exclude=＜パッケージ名＞」の設定は、指定したパッケージを自動更新の対象から除外します。
| exclude=selinux-policy* |
次に、SE-PostgreSQLの初期設定を行います。
SE-PostgreSQLは/var/lib/sepgsql以下にデータベースを配置しますので、このディレクトリを初期化する必要があります。以下のとおり「initdb」オプションでSE-PostgreSQLの起動スクリプトを実行してください。
なお、SE-PostgreSQLはデータベースオブジェクトのセキュリティ属性を格納するために、ディスク上のデータベースフォーマットを変更しています。従って、PostgreSQLのデータベースファイルとは互換性がないことに注意してください。
| [root@masu ~]# /etc/init.d/sepostgresql initdb Initializing database: [ OK ] |
/var/lib/sepgsqlディレクトリの初期化が完了すると、SE-PostgreSQLサーバプロセスを起動することができます。ブート時の自動立ち上げを有効にする場合、chkconfigの実行も忘れないようにしてください。
|
[root@masu ~]# /etc/init.d/sepostgresql start Starting sepostgresql service: [ OK ] [root@masu ~]# chkconfig sepostgresql on |
これでSE-PostgreSQLを起動できましたが、データベースを操作できるようにするにはもう少し作業が必要です。
SE-PostgreSQLの初期化プロセスはデータベースの特権ユーザー“sepgsql”を作成します。これ以外のデータベースユーザーを作成するためには、一度sepgsqlユーザーになってcreateuserコマンドを利用するのがよいでしょう。
|
[root@masu ~]# su - sepgsql [sepgsql@masu ~]$ createuser kaigai Shall the new role be a superuser? (y/n) y CREATE ROLE |
| 【注】 SE-PostgreSQLのデータベースユーザーの概念やデータベース認証の方法はPostgreSQLと変わりません。より詳しい情報についてはPostgreSQLのドキュメントを参照してください。日本PostgreSQLユーザ会が翻訳版を公開しています。 |
1/3 |
 |
| Index | |
| SELinuxのアクセス制御をデータベースでも | |
 |
Page1 SE-PostgreSQLが目指すもの リファレンスモニタの考え方をデータベースにも適用する SE-PostgreSQLを使ってみよう |
| Page2 SE-PostgreSQLのアクセス制御を試してみる MCSによるアクセス制御とは semanageコマンドで権限を修正する |
|
| Page3 各行のセキュリティコンテキストを確認 システムのポリシーに従った行レベルアクセス制御 |
|
 |
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）対策の観点から考える。
 |
|
|
|
|
