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

データベース管理者ロールを考える

OSS/Linux

あまり有効に活用されているとは言い難い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のインスパイアという事だがw

更に、将来的には JLS のセッションで紹介したシステムイメージを実現するような形にしたい。

これは "System-wide consistency in access control" の最も先鋭的な例で、要は、データベース管理者であってもユーザデータを自由に参照/更新させたくないのであれば、そのアクセス手段に関係なく防がなくちゃいけないよね?というモデルである。

このポリシーの下では、データベース管理者はSQLでのユーザデータへのアクセスは不可。ファイルの直接アクセスもSELinuxが防ぐ。
それだと、バックアップすら取得する事が不可能に思えるが、ポイントは、バックアップソフトを「起動する」事だけが可能。

起動されたバックアップソフトは、ドメイン遷移により、データベース全体をダンプするのに必要な権限を付与されて動作する。そして、管理者であっても中身を参照できないファイルに書き出しを行う。
したがって、確かにDBのバックアップは取得できるのだが、OSとDBの連携により、管理者だからといって任意にそれを参照する事はできない。

こういう事を実現したいと思っている。