今日もセキュリティセミナー
2006年03月03日
今日もセキュリティセミナー
第 2 回 「David LeBlanc が語る .NET Framework におけるセキュリティ」
今日もマイクロソフトのセミナーに行ってきました。今日の話題は同じセキュリティでも、.net アセンブリのセキュリティのお話。感想は、「思ったよりちゃんとわかってるじゃん、俺」みたいな(笑
というのも、ライブラリ公開を考えて、アセンブリのパーミッションとかは結構msdnドキュメントを読んでいたし、コントロールを販売するにはどうしたら一番いいんだろう?とかVB.net や C# をスクリプトとして読み込む時(コンパイラを取得してコンパイルさせてアセンブリを取得する)や、プラグインとして使用するとき(アセンブリを実行時バインドする)とか、どうしておかないといけないのか?よく考えていたから、内容はよくわかった。で、結局、よくわからんけど全部まじめに自分でやらんといけないんだ、って感じていたのが、やっぱりそうか!というのがわかったから、こんなレベルでもそれなりにポイント押さえてよく理解してたんだなぁ、と思ったわけです。
自分で作ったアセンブリを他人に使わなれないようにするにはどうしたらいいか?って話ね。
そーなんだよね。以前、署名したアセンブリからのリンクに制限したコントロールを作ったら、デザイナ上にインスタンスを初期化出来なくて、「結局自分で細かいコードを書かないと、細かい制限は出来ないのか!属性で簡単に指定してやることは無理か!」と思ったんだけど、やっぱそうなんだよね!(標準の機能でそういう点までやってくれるのをつい期待しちゃったけど)アセンブリのロードと同じで、自分で管理するしかないよね。ポイントはゾーンとアプリケーションのドメインだと思う。
アセンブリのロードは出来るだけ避けるように。そのときはロードしたほうのパーミッションになる(んだったかな?)から。みたいな注意があったし、自分のアセンブリから自分のアセンブリが読めるようにしただけだと、自分のアセンブリに一つ穴があると、そこを介して全てのアセンブリを使用されてしまうかもしれない。アセンブリをロードする部分には、ドメインを分けたりするのかな?方法はまだ漠然としたイメージでしかないけど、とにかく、権限を落としてやるような処理がいるだろう。ロードしたスクリプトやプラグインから自分のアセンブリを全部呼ばれて、アプリが乗っ取られて、何でも出来てしまうんじゃ、そりゃセキュリティホールだよ(笑)、いやマジで!
そうか、そーゆーことか。なんとなく、感覚的にわかってきたぞ。
今年中に、スクリプトやプラグインを使用したアプリケーションを仕事でも趣味でも作成する予定だから、かなりタイムリーに注意すべき点を聞けてよかった!です。
それにしても、最近のマイクロソフトのドキュメントは(まだまだ読みづらいけど)結構ちゃんと書いてくれてるんだなぁ、と思いました。わかりづらいけどね。ここまでしかできない!って書き方はしないから、まだあるんじゃないか?と思っちゃう事がネックかな。意外にちゃんとわかってるみたいだから、自信を持って頑張ろう!
ところで最初に質問した人は本をもらってたよ!いいなぁ、なんか聞けばよかった(笑
(追記)
もう一つ。API や ActiveX コントロール を使用しているところ、ラッパークラスについては C++ 同様、バッファオーバーラン(かな?)とか考えないといけない、ってこと。
今日もマイクロソフトのセミナーに行ってきました。今日の話題は同じセキュリティでも、.net アセンブリのセキュリティのお話。感想は、「思ったよりちゃんとわかってるじゃん、俺」みたいな(笑
というのも、ライブラリ公開を考えて、アセンブリのパーミッションとかは結構msdnドキュメントを読んでいたし、コントロールを販売するにはどうしたら一番いいんだろう?とかVB.net や C# をスクリプトとして読み込む時(コンパイラを取得してコンパイルさせてアセンブリを取得する)や、プラグインとして使用するとき(アセンブリを実行時バインドする)とか、どうしておかないといけないのか?よく考えていたから、内容はよくわかった。で、結局、よくわからんけど全部まじめに自分でやらんといけないんだ、って感じていたのが、やっぱりそうか!というのがわかったから、こんなレベルでもそれなりにポイント押さえてよく理解してたんだなぁ、と思ったわけです。
自分で作ったアセンブリを他人に使わなれないようにするにはどうしたらいいか?って話ね。
そーなんだよね。以前、署名したアセンブリからのリンクに制限したコントロールを作ったら、デザイナ上にインスタンスを初期化出来なくて、「結局自分で細かいコードを書かないと、細かい制限は出来ないのか!属性で簡単に指定してやることは無理か!」と思ったんだけど、やっぱそうなんだよね!(標準の機能でそういう点までやってくれるのをつい期待しちゃったけど)アセンブリのロードと同じで、自分で管理するしかないよね。ポイントはゾーンとアプリケーションのドメインだと思う。
アセンブリのロードは出来るだけ避けるように。そのときはロードしたほうのパーミッションになる(んだったかな?)から。みたいな注意があったし、自分のアセンブリから自分のアセンブリが読めるようにしただけだと、自分のアセンブリに一つ穴があると、そこを介して全てのアセンブリを使用されてしまうかもしれない。アセンブリをロードする部分には、ドメインを分けたりするのかな?方法はまだ漠然としたイメージでしかないけど、とにかく、権限を落としてやるような処理がいるだろう。ロードしたスクリプトやプラグインから自分のアセンブリを全部呼ばれて、アプリが乗っ取られて、何でも出来てしまうんじゃ、そりゃセキュリティホールだよ(笑)、いやマジで!
そうか、そーゆーことか。なんとなく、感覚的にわかってきたぞ。
今年中に、スクリプトやプラグインを使用したアプリケーションを仕事でも趣味でも作成する予定だから、かなりタイムリーに注意すべき点を聞けてよかった!です。
それにしても、最近のマイクロソフトのドキュメントは(まだまだ読みづらいけど)結構ちゃんと書いてくれてるんだなぁ、と思いました。わかりづらいけどね。ここまでしかできない!って書き方はしないから、まだあるんじゃないか?と思っちゃう事がネックかな。意外にちゃんとわかってるみたいだから、自信を持って頑張ろう!
ところで最初に質問した人は本をもらってたよ!いいなぁ、なんか聞けばよかった(笑
(追記)
もう一つ。API や ActiveX コントロール を使用しているところ、ラッパークラスについては C++ 同様、バッファオーバーラン(かな?)とか考えないといけない、ってこと。