アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
ファイルやデバイスなどの強制アクセス制御 (スコア:0)
何を意味しているのか不明瞭なので手を出す気にならないというか。
#「普通ならアクセスできないようなファイルやデバイスを強制的に制御できる」ってこと？
Re:ファイルやデバイスなどの強制アクセス制御 (スコア:5, 参考になる)
従来のパーミッションではログインしたユーザが、自身の所有するファイルをいい加減なパーミッションのままほったらかしにしていたり、ユーザが意図せず悪意あるプロセスを実行してしまった場合、それがセキリティ上の問題に直結する可能性がありました。
そこで強制アクセス制御ではシステム管理者が「セキリティポリシー」を定め、ユーザがそれに反するアクセス権を、たとえそのファイルの所有者がそのユーザ自身であっても適用することが出来ないようにします。
しかしこのセキリティポリシーは様々な条件に対してアクセス権限を指定出来る必要があり、Linuxの強制アクセス制御モジュールとして有名なSELinuxではセキリティポリシーの設定が複雑極まりないものであることが悩みのタネのようです。
# とかいいつつ使ってないので間違いとかあったら指摘よろしく
Re:ファイルやデバイスなどの強制アクセス制御 (スコア:5, 参考になる)
> 強制アクセス制御とは従来の任意アクセス制御(要するにパーミッション)に輪をかける形で権限を制限する機能のことです。
ここはちょっと微妙に違っていまして、アクセス制御の種類には
・強制アクセス制御(MAC)
・任意アクセス制御(DAC)
の二つの種類があると言う事です。理論上は、OSにMACだけの実装と言うのもありなわけですが、
一般的にはDAC+MACという実装方法がよくとられているので、Linux上ではDAC+MACという
形になっています。
あと、これはMACとかというよりはLinuxでのアクセス制御の実装方式(LSM)の話ですが、
Systemcall -> Linux Permission ->
security_XXX関数->SELinux or TOMOYO or AppArmor or LIDS or something...
みたいなチェック方式を取っていますので、最初にDAC部分がチェックされ、その後にLSMで
実装されているアクセス制御に基づくチェックが行われています。なので、
「DACにMACが覆いかぶさるような形」に見えます。2.4.X用のLIDSではMACチェック->DACチェック
の順で実装されていますので、MACで先にアクセスがはねられますので、覆いかぶさるような形
とはちょっと違います。
#横道にそれますが、LSMでDACを実装するというのもアリといえばアリです(uid=0なら絶対に1を返す、
#とか)。ただ、LSMで引き渡されている関数は、ほとんどの場合MACの実装(SELinuxとか)になっていると
#言う事です。
もちろん、既存のDACでのアクセス制御よりもシステムコール内に埋め込まれている数が
すごく多くなっていますので(無い物もあって、それが問題)、LSMでアクセス制御を実装した場合には
一般的なLinuxのアクセス制御よりも細かいレベルでアクセス制御を行う事が出来ます。
参考までに、2.6.20カーネルで、各システムコールでどの程度security_XX関数が呼ばれているかを
表にしてまとめて公開してあります。
http://www.selinux.gr.jp/LIDS-JP/systemcalls.html
Kazuki Omo "You can subdue, but never tame me..."