2007年9月 1日

[selinux-users:01991] [SELinux開発watch]情報フローに関する議論

David Howell氏

やあ、スティーブン

AとBという二つのプロセスがあるとしよう。2つは異なるセキュリティコンテキストを持っていると考えて。
もし、Aがファイルをオープンし、Bにファイル記述子を渡したとしよう(AF_UNIX socketになるかなぁ)。
この時、Bは、そのファイル記述子を使って動作するときにどちらのセキュリティコンテキストを持つことになると思うかい?
Aのセキュリティコンテキストだろうか、それともB?

僕は、Aのセキュリティコンテキストじゃないかな、と思ったんだけどね。だって、ファイルをオープンしたのはAなんだからさ。これは、UID/GID/モード
情報(ファイル構造体に入っている)や、その他のFSに特異なアクセスコンテキストでもそうだし、NFSもそうだと思うよ。
でも、security/selinux/hooks.cを見た限りでは、SELinuxではいつもそうなっている訳ではないみたい。
例えばioctlでは、Bのセキュリティコンテキストが使われているね。read やwriteでもそうだ。
これって、どうなのさ?つまり、Aは自分の読めるけどBは読めないファイルをBに渡すことが出来る。
Bはそのファイルを読むことは出来ないって訳だけど、Aができるんだから、Bも出来なきゃおかしいんじゃないの?
すくなくとも、僕はコードを読んでそう解釈したんだけどね。
もし僕が正しくて、これがSELinuxの誤った振る舞いだとするのなら、認証を使いまわすパッチを用意しているよ。

Stephen Smalley氏

ああ、それはMACが正しく動作しているという証拠なのさ。そうじゃなければ、Aのセキュリティ上の傷が記述子をとおして漏れだし、セキュリティポリシを壊してしまうじゃないか。
カーネルやアプリケーション上のいくつかのバグも補足し、execをとおしてファイル記述子がうっかりと漏れ出してしまうのを防いでいるって言う訳さ。
だから、ファイルをオープンする時には、ローカルIPC(linux_file_receiveを参照)で渡されたものをもう一回検査しているのさ。そして、exec
をとおして渡された場合は、SIDを変えるんだ(selinux_bprm_post_apply_creds ->
flush_unauthorized_files を参照)。
そうすることによって、read/write の際に再度チェックする手間を省いているんだよ。
read/write の再アクセスチェックは、ファイルリラベルしたり、ポリシを変更したりする替わりに行っていることなんだ。
でも、実はそれはすべての場合を網羅している訳じゃないんだ。
(すなわち、mmp'd ファイルや実行中のものは、そのチェックを省いているんだよ)
revoke機能が使える状態になって、マージされたら、それを使うつもりだけどね。
でも、それが使えるようになるかどうかはわからないよ。
selinux_file_permissionをなくそうか、という議論も現在進んでいるんだ。
ある状態だけで再チェックするというね。(open-timeチェックがかかってからの、ポリシのシーケンシャルナンバーが増えた場合だけとか、あるプロセスSID、ファイルSIDの場合だけとか)

David Howell氏

ああ、でも傷を持てないようにするのは分かるけど、Bは、Aの替わりにアクセスできるようにしていいんじゃないのかい?だって、Bにファイル記述子を渡してやらなければ、Bはファイルに直接アクセスできないじゃないか。
ちょっとこう考えてみよう。ある特別なファイル記述子についてAの権限を渡すことを許すにはどうしたらいいかを。
ファイル構造体のセキュリティを実際に変えられないはずだけど。
execve()に関して言えば、プログラムA(シェルとしよう)が、stdout
としてプログラムBに使わせるためにファイルを開くとしよう。しかしながら、プロセスのセキュリティラベルが、exec実行中に替わってしまうので、Bは、stdoutに書くことができない。SELinuxがenforcingモードになっているかどうかで異なっているから、ただしい動作といえるのだろうか?flush_unauthorized_files()がこれを行っているみたいだから、SELinuxでどうにかできないのだろうか?
デバッグツールとして使うのは便利かもしれないけど、いいポリシといえるのだろうか。
ところで、selinux_file_receive()は冗長だと思うよ。Bがread/writeできるかどうか
後で又チェックするにもかかわらずチェックしているんだからね。逆に、冗長に見えるけれども、ファイルの使用をできる限り早く消していると思うんだが。

Stephen Smalley 氏

それこそ、MACのMACたる所以なのさ。プログラム(ユーザもそうだけど、)Aは、強制アクセス制御においては、アクセスを替わってあげることなんて出来ないということだよ。ある場合においてだけ、替わってやるというのは、恣意的な制御になるのさ。そんなことをしたら、セキュリティ上の傷や悪意のあるコードに対して脆弱だということさ。
そこが重要だ。
SELinuxは既に許可されないアクセスを記述しているファイル記述子をプロセスが受け継いだり受け取ったり出来ないようになっているだよ。
flush_unauthorized_filesは、記述子を閉じるようにしていて、うまく動いているよ。
AとBというプロセスがあるとしよう。A はBに送ることは出来るが、その逆はできない。
もし、B が、Aが送ってきたAの権限に基づいた記述子を使用できるのなら、そのファイル記述子を送受信する過程で、双方向のチャネルが構成され、インフォメーションフローが壊されてしまうだろう。
Aという、すべてのデータフローを仲介する、守られ、信頼済みのsubsystemがあるとしよう。
Aは、アクセスコントロール、暗号化、サニタイゼーション、その他何でも、を与えられたファイルに対して行うことが出来る。
Aだけがファイルに直接書くことが確実でなければいけないけど、BがAにチェックしてもらったりしてAにファイルに書き込んでもらうのは許す。もし、AがAによってのみ許されるファイル記述子をBにもらしたら、Bはバイパス回路を作ってしまって、そこには、何の保護機能もなくなってしまうじゃないか。
もし同じ事が、revokeに基づいたメカニズムで現在のメカニズムを置き換えて実現できるのなら、受け入れるのはやぶさかじゃないし、そういうパッチがあったら、投げてくれたまえ。

SELinux security and passwd filed descriptor 31/Aug(抄訳藤原)

投稿者 xml-rpc : 2007年9月 1日 11:43
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/63620
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。