ちゃっぴの監禁部屋

セキュリティ効果については、既存のセキュリティの盲点を埋められるとボクは考えたピヨ。
既存のセキュリティ技術では、大まかに言うと、ネットワーク・データベース・OSなどの単位で行われています。
さらに.NETではコードセキュリティの可能性は少し示されました。
.NETでは信頼できないコードに対して制限はありますし、バッファオーバーフローも基本的には防げます。
でも.NETの方法でも完璧だとはとても思えません。
この技術は内部セキュリティを意識していないものと思われます。
ACLに頼ったやり方では、内部セキュリティ的にはNGであり、ACLを破った後のクラッカーの脅威に対して無力です。
具体的な方法を書いてしまうと、モラル的にNGなので概要を書くと、アプリケーションのDLLを新しくリンクした管理者権限のソフトを作れば、クラック出来てしまいます。
それにこういった事は開発者のヒューマンエラーからもおきてしまいます。
どれほど堅牢にDLLを作ってもそれを継承したクラスのセキュリティがお留守ですと、簡単にクラックされてしまいます。
そういった最後の水際防御を実現するためには、さらなるメタデータや言語の拡張が必要だとボクは考えております。
でもだからといって、この方法も完璧だとは主張しません。
ちょっと困らせる程度のものでしょう。
OSをクラックできる人達にしてみれば、コードセキュリティは時間稼ぎにしかなりません。
CPUやHDDにバイナリイメージがある限り、どうやってもクラック出来るでしょう。
かといって、水際セキュリティの進化を促すのを止めてしまえば、クラッカーたちの思う壺です。
総論すると「実施して直ぐの状態ではセキュリティ効果は薄いものの、既存の別層セキュリティ技術の進化を促す意義は大きい。」という事です。


最後に私の発言の意図するところを書きます。
アクセス指向なこの考えは、セキュリティ効果も狙っていますがどちらかというと、開発生産性の方を私は重視しております。
コンパイラにより多くの情報を与える事により、開発環境は進化する事は間違いありません。
もう既にハッカーレベルにまで到達している人にとっては開発環境の進化の恩恵は薄いと思いますが、平均的なプログラマが激化するお客様の要望やハードウェアの劇的な進化についていくことを可能にすると私は考えます。

もしかして、ちゃっぴさんはもしかしてユーザーのアクセス制御リストによるセキュリティを考えていますか？
ボクが言っているのはそんな流動的なデータではなくて、オブジェクト（コード）に基づく違うセキュリティです。
その辺の認識の違いが誤解を生んでいるような気がしました。
もし違ったらごめんね。

セキュリティの専門家にこういう事を書くと鬱陶しく感じられるかもしれませんが、違う人も見ているので念のために書いておきます。
※考えもせずに非難する非わんくまな方々がいるもので（笑）
オブジェクト（コード）に基づくセキュリティとは、コードのメタデータや動きを判定する形のセキュリティです。
オブジェクトやそのメッセージのアクセスの概念は深く、まだその全てを考えていないのでこれはまだ上辺だけども一応具体例を書きます。

まず前提として開発環境自身がセキュリティ意識を持って作ります。
リンクする際にもセキュリティチェックを行います。
アクセスに関するメタデータを精査し、予め開発元が想定したセキュリティ基準を満たさないコードはリンクを拒否されます。
でもこれは静的なチェックにしか過ぎません。
次に動作した時も常にオブジェクトはチェックされます。
オブジェクト指向では全てのものはオブジェクトですので、何らかの動きをするにはオブジェクトを生成したりアクセスしなければなりません。
このオブジェクトメッセージ送信時にもセキュリティチェックが入ります。
例えば、想定した以外の動きをするコードからのアクセスを拒みます。
そうすれば、クラックコードは実行できません。

一応念を押しますが、これは「概要程度」の技術です。
全てのオブジェクトのメタデータをより深く得られるのならばこんな誰にでも数分で思いつくようなセキュリティよりももっと凄いセキュリティは考えられるはずです。

> アプリケーションのDLLを新しくリンクした管理者権限のソフトを作れば、クラック出来てしまいます。

管理者権限を利用している自体ですでに攻略されていると思いますが。そのための最小権限の原則でしょう。
Code access security を厳密にすることにより解消される問題では無いでしょう。

> オブジェクト指向では全てのものはオブジェクトですので、何らかの動きをするにはオブジェクトを生成したりアクセスしなければなりません。
> このオブジェクトメッセージ送信時にもセキュリティチェックが入ります。

外部 resource については Windows ではとっくの昔に実現されていますね。内部 resource については一部の例外を除きありませんけど。

> アクセスに関するメタデータを精査し、予め開発元が想定したセキュリティ基準を満たさないコードはリンクを拒否されます。

これを行う制御の基準は何ですか？ 誰が？ では無いんですか？

具体的な方法は現状では思いつかないけど、将来はなんとかなりそうだと踏んでいるだけですか？

セキュリティは全然詳しくないのですが、「セキュリティ」という言葉は広すぎると思うのです。
そもそも「誰にどんなリスクが存在して、それを軽減するために多層防御を必要としているのか？」の情報が共有できないと、話が発散してしまうように思えます。
# 極端な例で恐縮なのですが、バッファオーバーランを防げます、というのは良く分かりません。防げても、ExceptionでService/Applicationが落ちるor回復に時間がかかるのなら DoS は可能だと思うのです。
# そもそも実行系が良く分からないのですけど、内部からの攻撃を恐れるのなら、全て WebApplication にしてサーバに置くのも手だと思うのです。

>外部 resource については Windows ではとっくの昔に実現されていますね。内部 resource については一部の例外を除きありませんけど。

先ほど挙げた例はあくまでも基礎的な部分でなので、似たような概念はやはりあります。基礎的な例であまりにも想像できない事を書いたら、επιστημη さんへ「現在の技術で実現可能です」と書いた事と矛盾してしまいます。


>具体的な方法は現状では思いつかないけど、将来はなんとかなりそうだと踏んでいるだけですか？

いいえ。方法は【全てのオブジェクトメッセージを管理する】という事です。オブジェクト指向に於いて、オブジェクトメッセージを制御できると言う事は無限の可能性を意味します。
始めは新しい概念に慣れなくて「必要なメタデータ」が思いつかずとも、どんどんノウハウが蓄積されて、新しいメタデータを追加していけばどんどんセキュリティは向上します。
誰がでは無くて「どのオブジェクトが」に注目するのがポイントです。
何故誰がを私は重視しないかと言うと、「コード階層でのセキュリティ」だからです。
多層と同じセキュリティ技術を用いても意味がありません。
というのも、管理者権限で実行されても「水際で食い止める」のが目的なのです。
私が言っているセキュリティとは、どんな管理権限があったとしても製作者に意向により動きを止められる「コードベース」なセキュリティなのです。
それを踏まえて、コードレベルのセキュリティ技術の発展を狙っています。
似たような概念は.NETでも既にあるのでイメージが湧くと思います。
※.NETの方法ではまだオブジェクト指向さがまだ足りません。

>新たなものを導入するためには、現状では不十分である理由を示さなければなりません。

>ぶっちゃけた話、一部の例外を除き interface ましてや method で access 制御を行う必要性が思い浮かばないんですよ。

今ひとつどこに論点があるのかよく分からないのですが，.NET は実際 private をセキュリティ境界の一種として扱っていますよ．
CLI 的な意味での型安全性の定義のところに，正当な権限無しに非公開メンバを読み書き (あと呼出しもかな) できないことってのを含めていたような．
確かに Windows のプロセス境界というのは強固なセキュリティ境界ですが，一方で今後は Windows Azure (これは CAS を使うようですね) のようなアプリケーションホスティングも重要になってくるわけで，プロセス境界だけに頼る時代から徐々に変わってくるのかなとも思っています．

ノータッチデプロイメントでリフレクションが使えなかったとかは懐かしい話ですね．
http://www.atmarkit.co.jp/fdotnet/special/ntdeploy/ntdeploy_03.html

また，非公開メンバへのアクセスをどう扱うかという点は色々議論が続いていたらしく，.NET 2.0 以降も少しずつ変更が行われています．
http://msdn.microsoft.com/en-us/library/bb397858.aspx
http://msdn.microsoft.com/en-us/magazine/cc163700.aspx#S8
http://msdn.microsoft.com/ja-jp/magazine/cc721609.aspx#id0070011

SecurityTreatAsSafeAttribute あたりを使うと，同一アセンブリ内のコードからすら不用意に非公開メンバが呼び出せなくできるようですね．
http://blogs.msdn.com/shawnfa/archive/2005/09/21/472396.aspx
http://msdn.microsoft.com/en-us/library/system.security.securitytreatassafeattribute.aspx

> セキュリティは全然詳しくないのですが、「セキュリティ」という言葉は広すぎると思うのです。
> そもそも「誰にどんなリスクが存在して、それを軽減するために多層防御を必要としているのか？」の情報が共有できないと、話が発散してしまうように思えます。

ごもっとも。

> 極端な例で恐縮なのですが、バッファオーバーランを防げます、というのは良く分かりません。

どの書き込みを基に書いたのかがわかりませんが、

> 防げても、ExceptionでService/Applicationが落ちるor回復に時間がかかるのなら DoS は可能だと思うのです。

例外で application (process) が落ちるというのは coding が悪いとしか言いようがないと思います。

> そもそも実行系が良く分からないのですけど、内部からの攻撃を恐れるのなら、全て WebApplication にしてサーバに置くのも手だと思うのです。

Web application というか、server side で実行させるのはものすごく有効な対策です。ただし、server side で実行させたからといって、それで終わる話ではありませんね。

> 誰がでは無くて「どのオブジェクトが」に注目するのがポイントです。

あんまりこういうことしたくないんですが。。。以前書いていときと意見が変わったということでよいですよね？

> というのも、管理者権限で実行されても「水際で食い止める」のが目的なのです。
> 私が言っているセキュリティとは、どんな管理権限があったとしても製作者に意向により動きを止められる「コードベース」なセキュリティなのです。

これは完全性を求めると不可能なことは理解していますよね？

> それを踏まえて、コードレベルのセキュリティ技術の発展を狙っています。
> 似たような概念は.NETでも既にあるのでイメージが湧くと思います。

理解した上で (補助的に) 利用するなら問題ありませんが、勘違いされると問題になりますね。

> .NET は実際 private をセキュリティ境界の一種として扱っていますよ．

Processor, OS の上に framework という皮を持たせたことからできる芸当ですね。Managed な領域にとどまっている限り、framework 自体に脆弱性が無ければ保障されることですから。それはそれで否定はしません。実際効果はありますし。

ただ、だからといってその下の level の問題を軽視してはいけないと思うんですよ。

その問題点を理解して使うならともかく、理解しないであ～制限できるならこれでいいや～ってなることを非常に危惧しています。