2007年9月 1日

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


中村です。

この話は、私も興味があるところです。
さらに、要約すると、以下でしょうか?
(合ってますかね???)

プロセスA(foo_tドメインで動いている)

プロセスB(bar_tドメイン)
があって、
プロセスAが、ファイルを開いて、そのファイル識別子(F)を
プロセスBに渡すとする。
この時、
BがFを使って、何かアクセスする場合、
アクセスチェックの場合のドメインは何になるか?
という話ですかね。
例えば、Fを使ってfile_tタイプのファイルにreadアクセスする場合、
アクセスチェックのドメインは、foo_tなのかbar_tなのか?
今のSELinuxだとbar_tドメインになる。

が、Davidさんは、
Aが開いたファイルなんだから、foo_tになるべきなのではないか?
と言ってます。

Stephenさんは、SELinux振る舞いこそが、
まさに強制アクセス制御なのだ、と言ってますね。
プロセスA -> Bへの情報の流れが許可されてて、逆が許可されないとする。
もし、Davidさんの案が採用されると、
Bー>Aの流れが発生してしまい、情報フロー制御がパーになるとのこと。

ちなみに、A->Bにファイル識別子を渡したとしても、
Bは、foo_tに対して、fd useというパーミッションがないと、
ファイル識別子を使うことができないようになってます。

うーん。要約になってるのか不明だ。。

On Sat, 1 Sep 2007 11:43:39 +0900
"Shintaro Fujiwara" wrote:

> 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日 23:27
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/63618
トラックバック
コメント
コメントする




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