[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[b-free: 2114] Re: Manifesto英語版少 し修正。
自分で補足しておきます。
何か、僕は、CPU の ring 機構と、OS としての ring 構造をゴッチャにしちゃ
っている見たいなんですが、OS としての ring 機構としては、外側の ring か
ら内側の ring に簡単に access できないと言う話になっています。
これは、Bell-La Padula Confidentiality Model に見られるように、ring 分け
に対応するような、security fence を決めて security sensitivity level を
考えた場合、fence の内側(より高い機密性を要求する)から外側(より低い機
密性を要求する)への書き込みによる情報の流出(転写)と、外側から内側への
情報の読み出しによる流出を禁止したりする物です。
「許容される情報流(機密維持/内部改変)」
内側(高い機密情報)←−書込−−外側(低い機密情報)
内側(高い機密情報)−−読込−→外側(低い機密情報)
「禁止される情報流(機密漏洩/内部保護)」
内側(高い機密情報)−−書込−→外側(低い機密情報)
内側(高い機密情報)←−読込−−外側(低い機密情報)
これは、同じ ring にある(例えば)process 間の保護よりもずっと強いもの
で、たとえば、同じ機密要求性をもつ二つの process は自由に情報を IPC など
で交換できますが、security fence をまたいだ、すなわち、ring を超えての情
報交換は非常に限定されると言うことになります。
# 別に security fence が ring 状である必要性は全くないけど。
OS での話ですと、うえの Bell-La Padula は "confidentiality model" であ
り、如何に機密漏洩を防ぐかに重点が置かれていますから、外から内への
parameter passing のための読み書きを認めていると解釈し、それ以外の fense
を超えたやり取りは不可能であると解釈するべきだと思います。
ちなみに、機密漏洩より内部改竄禁止に重点を置くと、Biba Integrity Model
を使うことになり、ちょうど矢印が逆(すなわち Bell-La Padula で禁止されて
いる事が許容され許容されることが禁止される)になります。これは、外へ結果
の返還をすると解釈できます。
この二つをどの様に組み合わせるかは、一つの現在の computer security 上で
解決されていない問題のようです。
まあ、考えられる一つの妥協策は、ある機密要求度の構成要素を二つに分けるこ
とです。
たとえば、
機密要求度1:(対機密漏洩1,対改竄1)
機密要求度2:(対機密漏洩2,対改竄2)
と言う具合です。
そこで、対機密漏洩部分同士では、Bell-La Padula をつかい、対改竄部同士で
は Biba を使うことでしょうか。
もちろん、対機密漏洩部と対改竄部がお互いに自由に情報交換すると、全く意味
がないので、そこを非常に厳格に制限することで両立をはかろうと言うもので
す。
-Aki.
Hideaki Suzuki wrote:
>
> もしくは、例えば、network のために「認証 manager」みたいなものを今後
> B-free が取り込んだとして、それが管理している機密情報を、ほかの user app
> が不当な手段を使って、crack する事が可能でしょうか? それを、ring によ
> る保護で、そういった情報への access を禁止する事は、どれくらい意味がある
> と考えられるでしょうか?(ring を使用しない<普通の app と同じ level の
> process>で認証 manager を作ったときとの危険性、すなわち paging での保護
> とはどのくらい違うのでしょう?)
>
> また、B-free にも多くの bug は予想されるでしょうが、そういう bug を駆使
> して System を crack しようとしたときに、ring 機構というのはどれぐらい、
> 有効な物なのでしょうか?
>
> うーむ。
> でも、これって、CPU (特に i386)の ring 機構と言うより、ring 状の保護機
> 構全般の話なのかなぁ。
> Software で emulation しちゃえば良いだけの話?
>
> -Aki.
>
> ps. 質問ばかりしてるな、、、。(^_^;;;