2007年9月 2日

[selinux-users:01994] Re: read/write時のパーミッションチェック(Re:[SELinux開発watch]情報フローに関する議論

SELinux は、FLASK
というアーキテクチャに基づいており、revokeの際は、以下の事が確約されなければいけないようです。原理原則なので、これが崩れることは、激しく嫌うはずです。だからSmalley氏は、渋っているのだと思います。うーん、マンダム。

...
この原子性を達成する際に根本的に問題となるのは、以前に許可されたパミッションがポリシの変更に伴い取り消されることを確約することである。パミッションが取り消されようとするとき、そのパミッションが以後再び許可されることがない限り、そのパミッションによりコントロールされるサービスが許可されることはないであろう事を確約しなければならない。撤回は、一貫性を持たせるのが非常に難しい属性である。なぜなら、パミッションは一度認められると、システム全体に遷移しがちであるからである。撤回のメカニズムは、このような遷移済みのパミッションが確実に撤回されたという事を確約しなければならない。
...


07/09/01 に Yuichi Nakamura<himainu-ynakam@xxxxx> さんは書きました:
>
> 中村です。
>
> On Sat, 1 Sep 2007 11:43:39 +0900
> "Shintaro Fujiwara" wrote:
> Stephen Smalley氏
> > そうすることによって、read/write の際に再度チェックする手間を省いているんだよ。
> > read/write の再アクセスチェックは、ファイルリラベルしたり、ポリシを変更したりする替わりに行っていることなんだ。
> > でも、実はそれはすべての場合を網羅している訳じゃないんだ。
> > (すなわち、mmp'd ファイルや実行中のものは、そのチェックを省いているんだよ)
> > revoke機能が使える状態になって、マージされたら、それを使うつもりだけどね。
> > でも、それが使えるようになるかどうかはわからないよ。
> > selinux_file_permissionをなくそうか、という議論も現在進んでいるんだ。
> > ある状態だけで再チェックするというね。(open-timeチェックがかかってからの、ポリシのシーケンシャルナンバーが増えた場合だけとか、あるプロセスSID、ファイルSIDの場合だけとか)
>
> ここに出てる話ですが、今Stephen Smalley氏と↓で議論中のものです。
> http://marc.info/?t=118845343400001&r=1&w=2
>
> SELinuxは、
> ファイルを読み込みモードでopen→ファイルをreadシステムコールで読み込み
> という処理の際、
> open, read両方の時にアクセスチェックが発生します。
> open時のチェックだけで十分じゃないかという気もするのですが、
> 実はread時にダブルチェックすることには意義があります。
> 例えば、open後に、ポリシーの変更があった場合、
> read時にもチェックする意義があります。
> open時には許可だったのが、read時には拒否になってるのかもしれないので。
>
> ↑で出てる、
> selinux_file_permissionという関数は、readの時などに呼ばれるものです。
> この中でSELinuxのパーミッションチェックなどが行われるのですが、
> CPUによっては、結構重いことが発覚してしまいました。
> なので、selinux_file_permissionの処理を
> なるべく軽くしようと画策中です。
>
> Yuichi Nakamura
>
>

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




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