SELinux - syagi's blog

SELinuxの概要を軽くまとめ。

SELinuxとは

カーネル2.6において新たに実装されたLSM(Linux Security Module)に対応した拡張モジュール。カーネル2.6に標準実装され、従来のシステムの問題点をうまく克服したセキュアOSとなっている。
　

SELinuxの特徴的な機能

TE (Type Enfocement)

従来の、プロセスを実行するユーザーの権限に依存したアクセスコントロールではなく、プロセス毎に権限を設定してアクセスコントロールを行う機能。これにより、各プロセスは必要最低限の権限でしか動作しなくなるため、"本来意図していないファイルを書き換えてしまう"などの脆弱性をOSレベルで回避できる。
　
内部的には、プロセスに対して「ドメイン」、（ファイルなどの）リソースに対して「タイプ」という属性（ラベル）がそれぞれ与えられる。また、リソースの種類に応じて「オブジェクトタイプ」という属性も存在し、それぞれに対応した「アクセスベクトル（アクセスベクタ）」が割り当てられる。
SELinuxはこれらの属性を利用し、ドメイン毎に各タイプに対し許可するアクセスベクタを設定できる。つまり、プロセス単位でアクセスできるファイルを制限することが可能。　
具体例：

HttpデーモンであるApacheはドメイン"Httpd"に所属
HTMLファイルであるindex.htmlはタイプ "httpd_content"、オブジェクトタイプ "file"に所属
オブジェクトタイプ "file" に対応したアクセスベクトルは "read" , "write" , "lock"の３つ
ドメイン "Httpd" がタイプ "httpd_content" に対して許可されているアクセスベクトルは "read" のみ

以上で、apacheがindex.htmlを書き換えることを禁止できる。（厳密には、読むことしか許可しなくなる）
　
また、子プロセスに対して異なるドメインを付加する「ドメイン遷移」も実装されており、子プロセスが親プロセスのドメインを継承して不必要な権限を持つことが回避されている。

RBAC Role Based Access Control

こちらはユーザがリソースへアクセスするときの権限を設定するモノ。ユーザ毎に "ロール" という属性が設定され、このロールの範囲内でしかリソースにアクセスできない。これはrootであっても同様で、アクセスコントロールを越えて全権的にあらゆるリソースへアクセス出来るユーザを作らないことを意味する。つまりrootを奪取された場合にも被害が限定的になるということ。
具体的には、httpdの管理はhttpd管理専用のユーザーを、ユーザー管理にはユーザー管理専用のユーザーを、という風に権限を分担することになる。
（まあそれでも、ロールを管理する権限が奪取されれば最終的には全て可能になってしまうわけだが・・・）

MAC Mandatory Access Control:強制アクセス制御

従来のユーザグループとパーミッションによる管理手法「DAC(Discretionary Access Control : 任意アクセス制御)」に対する新たな管理手法。
DACが、ユーザーが自分の所有するファイルならば任意に権限を変化させること（ex 実行権限付加なら$ chmod +xなど）が出来たのに対し、MACはポリシーに基づき全てのユーザーにTEやRBAC等のアクセス制御を強制する。つまり許可されていないロールやアクセスベクトルをユーザーが勝手に付加することが出来ない。よりセキュアな（そして、時にはより不便な）管理手法といえる。
　

所感と考察

よく言われることとして、SELinuxは「従来のrootに依存した管理手法」の弱点を克服し、よりセキュアなシステムを実現するOSというのがある。確かに今回勉強したコトを乱暴に要約すると、「rootの権限を制限する機構を実装した」と言えなくもない。
実際バイトなどでLinuxを触っていると、"何でも出来る神様"なrootにゾッとさせられることもある。rootでログインできれば後は何でもアリ。どんなに堅牢な設定がなされたサーバーでも関係なし。それどころかその堅牢な設定すら自由に変えられてしまう。
ついでに、別のユーザーにrootと同等な権限を与えることだって可能。まさに最強のバックドア。
　
どんな難攻不落の要塞も、その要塞司令を懐柔すれば容易に落とせる。
全能の神は、非力な罪人を全能にすることも出来る。
・・・恐ろしや。
　
でも一方で、利便性ということを考えるとちょっと首をかしげざるを得ない。
rootは何でも出来るからrootなのであって、出来ることに制限のある管理者ほど窮屈なモノはない。困ったらとりあえずrootで応急処置。適切かどうかは不明だが、少なくとも解決策の一つとしてバイト先でよく採用する選択肢。これが無くなるのは正直痛い。
何でもお上にお伺いを立てなければ出来ないのはある種組織における最悪のパターン。それにポリシーが適切なら安全として、そのポリシーは誰が設定するのか。先ほど挙げただけでもドメイン、タイプ、オブジェクトタイプ、アクセスベクトル、ロール、５つの属性がたくさんのプロセスたくさんのリソースたくさんのユーザーに個別に振り分けられている。これだけでデータベースが作れるんじゃないかと言うぐらい。ああ考えるだけでにやけてくる・・・。
ポリシーが適切に決まったとして、管理者は何度もsuを繰り返すのだろうか？
中央集権が危険だから分権てのは悪くない発想でも、その権利を行使するプロセスがいささか冗長過ぎやしないか。
　
窮屈な規則は円滑な運用の足枷。
非常時には何でも出来るほうが状況は改善しやすい。
複雑すぎるプロセスは誰もが嫌い、抜け道を作りたがる。

バランスって難しいよね。
　