今日、某氏に話してみたアイデアだけれども、私自身は全く実装する時間がとれないので、誰か以下のような拡張をしてみませんか？ということで。
(レビューはできますよ)
SELinuxには、LinuxのCapabilityサポートのためにsecondary_opsという機能がある。これは、一部のLSMフックの延長で別のLSMモジュールを呼び出すためのもので、基本的にはCapabilityサポートのために用いる。
(CapabilityチェックはLSMフックの延長で行われるのだ。)
で、このsecondary_opsがコールされる場所を見てみると、capable()の延長だけでなく、inode_permission()とか、結構いろんな箇所で呼び出されるので、実はSELinuxと共存可能な形で俺Capabilityモジュールを作って、ファイルのアクセス制御強化に使えそうな気がする。
例えば、今のcapabilityシステムではそんなに細かく出来ないが、readに関してのみファイルパーミッションを無視とか、APPENDオープンのみ可能なcapabilityとか、あるいは逆に、自分のファイルであってもchmodを不可能にするとか色々使い道がありそう。
要するに、Capabilityの数を増やしてもっと細かくできるようにしましょうというアイデア。
ここで問題となるのは、タスクにどうやってcapabilityを保持させるかという点。task->security は SELinux が使っているので、他の方法を考えないといけない。
で、その候補となるのが keyring である。これは、任意のバイナリデータをプロセスやセッション(一連の親プロセスから派生した子プロセスの群)に関連付けることができる。
ここに、俺capabilityの情報を埋め込めば、例えばユーザkaigaiでログインした場合にxxxxのケーパビリティを、グループsysadmのユーザでログインした場合にxxxxのケーパビリティをという使い方ができる。
この方法で一番嬉しいのは、俺capabilityモジュールでDAC制御を強化しつつ、MACをSELinuxに任せられること。
これによって、既に膨大な蓄積のあるユーザ空間アプリのSELinux対応を無駄にすることなく、独自のアクセス制御メカニズムを実装することができる。ここをスクラッチから起こそうとすると、やはり作業量が膨大になってしまうのじゃないだろうか。
このアイデアのキーコンセプトは以下の３つ。さて、手を挙げてくれる人はいないかなぁ〜
・SELinuxのsecondary_opsに乗っかるLSMモジュール
・kernel keyringを利用してタスク/セッション毎のデータを保持
・SELinuxとの共存
