読者です 読者をやめる 読者になる 読者になる

2 security models, 2 security attributes

OSS/Linux

v8.4に向けた最後のCommitFestでSE-PostgreSQLに関する議論もボチボチ進んでいる。その中で、インターフェースに関する修正もいくつか行った。正直な所、この手の自明なリクエストなら何でもっと早い段階で言わないんだ!と言いたくもなるが、非生産的なのでそれは言わない事にして、コードを修正する。

従来は、SE-PostgreSQLを有効にしてビルドした時にsecurity_contextシステム列が出現するという形になっていたが、『ビルド時に特定機能のon/offを切り替えるのはまかりならん』という事で、SE-PostgreSQL機能のビルドとは別に、ランタイムでPGACE上に乗っかるセキュリティ機能を選択するオプションを付けることに。

SE-PostgreSQLの場合は、データベースクラスタの初期化(initdb)時に既に有効化されている必要があるので、initdbにオプションを追加。

$ initdb --pgace-feature=selinux

で、SE-PostgreSQLを有効にしてデータベースを構築できるようになる。



もう一つ、大きな修正として、SE-PostgreSQLのMACと、既存のDatabase ACL(DAC)を双方同時に行レベルで適用したいという要求があった。アクセス制御の粒度というものは、セキュリティデザインに内包されるべきものなので、行レベルか否かという一点を取り出して議論するのは間違っているのだが、圧力に屈する。orz

(何に対してアクセス制御を提供すべきか、ISO/IEC15408ではアクセス制御ポリシーの記述の一部として列挙するよう求めている事に留意)

結局、行レベルに関しては、固定のDACと、選択可能なMACという組み合わせを提供する事になった。

しかし、異なるセキュリティ機能が同時に有効化されるには、セキュリティ属性も各々に必要という事で、ACLITEM[]型の"security_acl"と、TEXT型の"security_label"型を追加する事となった。

行レベルのACLに関しては、CREATE TABLE時にテーブルオプション row_level_acl=on を指定すれば有効になる。逆に、指定しなければ従来通り。余計なストレージを食う事もないので、行ACLなんてキワモノは利用しない事をお勧め(と、作者が言うww)



で、こんな感じでセキュリティ関係のシステム列が2つ追加。

postgres=# SELECT security_acl, security_label, * FROM drink;
    security_acl     |              security_label              | id |  name  | price
---------------------+------------------------------------------+----+--------+-------
 {kaigai=rwd/kaigai} | system_u:object_r:sepgsql_table_t        |  1 | water  |   100
 {kaigai=rwd/kaigai} | system_u:object_r:sepgsql_table_t        |  2 | coke   |   120
 {=r/kaigai}         | system_u:object_r:sepgsql_table_t        |  3 | juice  |   130
 {=r/kaigai}         | system_u:object_r:sepgsql_table_t        |  4 | coffee |   180
 {=r/kaigai}         | system_u:object_r:sepgsql_table_t:Secret |  5 | beer   |   240
 {ymj=rw/kaigai}     | system_u:object_r:sepgsql_table_t:Secret |  6 | sake   |   320
(6 rows)