あまり有効に活用されているとは言い難いSELinuxのRBACだが、最近は地味にロールの種類が増えてきているようだ。
Reference Policy の policy/modules/roles 以下を見てみると、こんな感じで結構盛りだくさん。
$ ls *.te
[kaigai@ayu roles]$ ls *.te
auditadm.te
guest.te
logadm.te
secadm.te
staff.te
sysadm.te
unprivuser.te
webadm.te
xguest.te
WebやAuditなど、特定用途に特化したROLEが定義されている。
つまり、この人たちはWeb関連のファイルや、Audit関連のファイルしか
アクセスできない。たとえ sudo を使って root の権限を取得したとしてもだ。
データベース管理に特化したROLEというのは定義されていなかった…というか、多分それは俺の仕事なので、dbadm というロールを追加するパッチを投稿した。
http://oss.tresys.com/pipermail/refpolicy/2009-December/001804.html
今のところ、PostgreSQL関連のファイルとMySQL関連のファイル（動作未確認）を操作する事ができ、suやsudoを実行する事ができる。
加えて、SE-PostgreSQLの場合には CREATE TABLE などの DDL 文を実行して
スキーマ定義を行う事ができる。但し、SELECTやUPDATEなどのDML文の実行は、sepgsql_unconfined_admin条件変数によって制御する。
つまり、スキーマ定義はできるけども、ユーザデータの参照/更新は不可というデータベース管理者を作りたい。○racleのインスパイアという事だがｗ
更に、将来的には JLS のセッションで紹介したシステムイメージを実現するような形にしたい。
これは "System-wide consistency in access control" の最も先鋭的な例で、要は、データベース管理者であってもユーザデータを自由に参照/更新させたくないのであれば、そのアクセス手段に関係なく防がなくちゃいけないよね？というモデルである。
このポリシーの下では、データベース管理者はＳＱＬでのユーザデータへのアクセスは不可。ファイルの直接アクセスもSELinuxが防ぐ。
それだと、バックアップすら取得する事が不可能に思えるが、ポイントは、バックアップソフトを「起動する」事だけが可能。
起動されたバックアップソフトは、ドメイン遷移により、データベース全体をダンプするのに必要な権限を付与されて動作する。そして、管理者であっても中身を参照できないファイルに書き出しを行う。
したがって、確かにＤＢのバックアップは取得できるのだが、ＯＳとＤＢの連携により、管理者だからといって任意にそれを参照する事はできない。
こういう事を実現したいと思っている。
