7
LSM Leaks 名前ベースのアクセス制御の意味 LSMに隠された抜け道 1 TOMOYO Linux プロジェクト 半田 哲夫

LSM Leaks

Embed Size (px)

DESCRIPTION

TOMOYO LinuxとAkariの開発者であり、LSMに精通する半田さんによる講演資料。 ・名前ベースのアクセス制御の意味 ・LSMに隠された抜け道 第51回コンピュータセキュリティ研究発表会 http://www.ipsj.or.jp/09sig/kaikoku/2010/CSEC51.html

Citation preview

Page 1: LSM Leaks

LSM Leaks

名前ベースのアクセス制御の意味

LSMに隠された抜け道

1

TOMOYO Linux プロジェクト

半田 哲夫

Page 2: LSM Leaks

メインラインカーネルに含まれている アクセス制御モジュール

SELinux/Smack 出発点:情報の隔離と伝達経路の制御

TOMOYO/AppArmor 出発点:バッファオーバーフロー対策

現在の状況 SELinux は設定内容が適切であるかどうかを確認することが困難で

あることから、 Google suggest に「 SELinux disable 」が登場するほどのアレルギー反応を引き起こし、現在も続いている。

さらに、最近では「 AppArmor disable 」も登場しており、ユーザに設定内容を意識させないまま使ってもらうことの難しさを感じている。

TOMOYO は徹底的にユーザに設定内容を意識させているが、利用者が少なく、しかもデフォルトで有効になっていないため、まだ「 TOMOYO disable 」は登場していないようである。

Page 3: LSM Leaks

ラベル対パス名論争(2006年)

ラベル ファイルがどこに存在していてもアクセス可否が変わらないことが

重要。

パス名を持たない資源についてもアクセス制御できることが重要。

パス名(などのパラメータ) あるべき場所にあるべき名前でファイルが存在していなければ、

ファイルに到達できなかったりファイルの内容が想定外の用途で使われたりする。

パス名やコマンドライン引数などのパラメータを制限することにより、想定外の動作や使われ方が発生しないようにすることも重要。

TOMOYO ではファイルの読み書き実行だけでなく、ファイルのリネームやコマンドライン引数なども制限することができる。

Page 4: LSM Leaks

ラベルに基づくアクセス制御だけでは 解決できない問題の例

# mv /etc/shadow /etc/my_shadow ラベルであれば /etc/my_shadow に対するアクセス可否は変わらな

いが、ユーザがログインできなくなっては意味が無い。

# mv /var/www/html/index.txt /var/www/html/.htaccess ラベルであれば /var/www/html/.htaccess に対するアクセス可否

は変わらないが、Webコンテンツとして使われるべきファイルの内容がWebクライアントに対するアクセス制御情報として使われてしまっては意味が無い。

# /usr/sbin/sshd -o 'Banner /etc/shadow' ( SELinux の targeted ポリシーの場合) /etc/shadow に対する

アクセス可否は変わらないが、パスワード情報が認証前のSSHクライアントに対して開示されてしまっては意味が無い。

Page 5: LSM Leaks

ラベル&パス名論争(ひそかに展開中)

ラベルに基づくアクセス制御は機密性と完全性の確保が得意。 しかし、アクセスを許可することにより発生する副作用を扱うこと

は苦手。

パス名(などのパラメータ)に基づくアクセス制御は可用性の確保が得意。 しかし、オブジェクトの視点からアクセスを制限することは苦手。

ラベルとパス名は補完しあうものであり、同時に使用できるべき。 LSMの制約により、複数のアクセス制御モジュールを同時に有効

にできない。

LSMを用いない TOMOYO 1.x であれば同時に有効にできる。

Page 6: LSM Leaks

LSMの遷移(閉鎖的/排他的なコミュニティ)

主な出来事 2.6.0(2003/12) メインラインに含まれているのは SELinux だけ 2.6.24(2008/1) LKMとして実装することが不可能に 2.6.25(2008/4) Smack がメインライン化成功 2.6.29(2009/3) スレッド単位での変数管理が不可能に 2.6.30(2009/6) TOMOYO がメインライン化成功 2.6.35(2010/8) 起動後に登録することが不可能に 2.6.36(2010/10) AppArmor がメインライン化成功/ Yama は失敗

全てのアクセス制御モジュールのためのインフラとして提供されていた筈が、メインラインに含まれているアクセス制御モジュールの主張だけで動くように。

アクセス制御モジュールはメインラインへの追加が困難で、カーネルコンパイル時に組み込まれなかったアクセス制御モジュールはカーネル本体の置き換えをしないと使えないという巨大な障壁に阻まれている。

Page 7: LSM Leaks

AKARI(灯?灯里?)

LSMで実装可能な範囲をLKMとして実装した TOMOYO TOMOYO 2.x よりも簡単に導入でき、 TOMOYO 1.x に近い機能を利

用可能 アクセス解析用ツールとしても有用 TOMOYO 1.x と同様に SELinux/SMACK/AppArmorなどとの同時利用が

可能

2.6.3 ~ 2.6.37-rc5 のLSMが有効なカーネルで利用可能 2.6.24/2.6.29/2.6.35 におけるLSMの仕様変更の影響を巧みに

回避 RHEL6 (2.6.32) や Fedora14 (2.6.35) などでも利用可能

単機能LSMモジュールを開発する際のテンプレートとしても利用可能 何か作りたいものはありませんか?