- PR -

アセンブリの署名/遅延署名について

投稿者投稿内容
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2002-09-20 19:57
 こんにちは、お世話になります。

 少々ややこしい形態で開発をしています。

Server (Win2000Server + Oracle9i + IIS)
|
+Client1(Win2000Pro)
+Client2(WinXP Pro + IIS)

Client1では、ServerのIISを利用して、Server上にXML DataServiceを開発しています。
Client2では、リッチなWebアプリケーションを、Client2上で開発しています。ASP.NETを使えばいいのかもしれませんが、JavaもASPも知らない私が、プログラムを作ることさえ初めての人とともに短期間でそこそこボリュームがあるモノを作るため、私が経験的にわかりやすいリッチな画面を利用することにしました。ところが、Client2からServerのデータサービスにアクセスできない(セキュリティー例外が発生)ため、Client2上でコンパイルしたDLLファイルをServerのIISが公開しているディレクトリへコピーして動作させています。

 これまでの段階では問題がなかったのですが、Client2で開発中のリッチアプリケーションは、ローカルなファイルにアクセスしたい(ファイル名がとりたい)のです。しかし、.NETのセキュリティーによってアクセスできません(OpenFileDialog.FileNameにアクセスすると、セキュリティー例外が発生する。ファイルストリームはとれる)。アセンブリのセキュリティーチェックをしないようにさせるには厳密名をつけなければいけない、とどこかで読んだので、ここの記事を参考に、Serverで公開キーファイルを作成し、Client2へコピーし、Client2でコンパイルし、Client2で遅延署名の設定をし、Serverにコピーしました。すると、それまでは見えていた「リッチな」画面が表示されなくなってしまいました。試しに、AssemblyInfoから、公開キーを埋め込む指定をコメントアウトすると、画面が表示されるようになりました。

 どうもよくわからないのですが、遅延署名はどのようにして設定するのでしょう?

#「ASP.NETで作れぇ〜」は勘弁してください。内作なので納期はないに等しいですが、今月中なので。
NothingButXMLInfoSet
大ベテラン
会議室デビュー日: 2002/07/16
投稿数: 116
投稿日時: 2002-09-20 22:49
引用:

Jittaさんの書き込み (2002-09-20 19:57) より:
アセンブリのセキュリティーチェックをしないようにさせるには厳密名をつけなければいけない、とどこかで読んだので、


それは間違いです。厳密名によってコードアクセスセキュリティに自動的に風穴が開くような効果はありません(ただし、MicrosoftとECMAの厳密名だけは別ですが)。むしろ厳密名には、ちょうどJittaさんが経験されたような、CASをパワーアップする効果があります。

引用:

Client2で遅延署名の設定をし、Serverにコピーしました。すると、それまでは見えていた「リッチな」画面が表示されなくなってしまいました。試しに、AssemblyInfoから、公開キーを埋め込む指定をコメントアウトすると、画面が表示されるようになりました。


これは遅延署名とは関係ありません。CLRのデフォルト設定では、部分信頼コード(FullTrustを持たないコードはすべて部分信頼コード)から厳密名付きのアセンブリへの呼び出しを許可しないのです。だから、厳密名をつけるとアセンブリへアクセスできなくなり、厳密名をはずすとアクセスできるようになるのです。

厳密名付きのアセンブリに部分信頼コードからアクセスできるようにしたい場合は、AllowPartiallyTrustedCallers属性(APTC)をアセンブリに適用しなくてはなりません。詳細はこの文書を参照してください。このルールは.NET Framework 1.0の出荷直前に決められたので、ドキュメントには間に合わなかったようです。v1.1のドキュメントにはきっと反映されるでしょう。

で、ご希望の「ファイル名にアクセスする」という動作については、そのアプリケーションを実行するマシン上で、たとえばJittaさんのpublicKeyを持つアセンブリに対して、あるいはJittaさんのコードが置いてあるLAN上のサーバーから落ちてきたコードに対して、ファイルの情報に対するアクセスを許可するようなコードアクセスセキュリティの設定を行わなければなりません。

#このあたりの話はInsider .NETフォーラム上で連載中のインサイド.NET Frameworkで次回から取り上げる予定だ。。。と筆者が申しておりました。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2002-09-21 09:06
ども、いつもありがとうございます。
引用:

NothingBut.NETFXさんの書き込み (2002-09-20 22:49) より:
引用:

Jittaさんの書き込み (2002-09-20 19:57) より:
アセンブリのセキュリティーチェックをしないようにさせるには厳密名をつけなければいけない、とどこかで読んだので、


それは間違いです。厳密名によってコードアクセスセキュリティに自動的に風穴が開くような効果はありません(ただし、MicrosoftとECMAの厳密名だけは別ですが)。むしろ厳密名には、ちょうどJittaさんが経験されたような、CASをパワーアップする効果があります。


 えっと、「風穴があく」とは思っていません。クライアントPCのユーザが設定したアクセス限界まで引き上げることが可能、と理解していますが、よろしいでしょうか。

引用:

これは遅延署名とは関係ありません。CLRのデフォルト設定では、部分信頼コード(FullTrustを持たないコードはすべて部分信頼コード)から厳密名付きのアセンブリへの呼び出しを許可しないのです。だから、厳密名をつけるとアセンブリへアクセスできなくなり、厳密名をはずすとアクセスできるようになるのです。


 htmlで、{OBJECT CLASSID="http:foo.dll#barClass" VIEWASTEXT}と埋め込んでいます。ということは、HTMLが「部分信頼コード」というわけですか?HTMLをおいてあるサーバは、「信頼するサイト」に登録し、「信頼するサイト」のセキュリティーは「低」にしてあります(IE側)。
<追記>
 それから、「そのアセンブリに対しては署名の検証を行わない」ようにするのは、「アセンブリ」に対してではなく、アセンブリを実行したリコンパイル(リンク)を行う「コンピュータ(またはユーザ)」に対して、ですね?Client2で作成した、公開キーのみ埋め込んだアセンブリをサーバにコピーし、サーバ上で「sn -Vr」を実行しましたが、Client2では表示できませんでした。
</追記>

引用:

で、ご希望の「ファイル名にアクセスする」という動作については、そのアプリケーションを実行するマシン上で、たとえばJittaさんのpublicKeyを持つアセンブリに対して、あるいはJittaさんのコードが置いてあるLAN上のサーバーから落ちてきたコードに対して、ファイルの情報に対するアクセスを許可するようなコードアクセスセキュリティの設定を行わなければなりません。


 内作ツールですが、エンドユーザ(課員ですね)には何の設定もさせたくないのです。フレームワークは、{OBJECT}{A HREF=FRAMEWORKへのパス}IE6を使用するか、ここをクリック{/A}{/OBJECT}というようなことをして、フレームワークのインストールを意識させないようにしたいと思っています。ポスト後、管理ツールのフレームワークウイザードで「信頼するサイト」を「フルトラスト」にすれば可能であることはわかりました(するなら「イントラネット」ですね:-p)。が、できれば、それもさせたくないのです。そんなことって、.netで可能なのでしょうか?

引用:

#このあたりの話はInsider .NETフォーラム上で連載中のインサイド.NET Frameworkで次回から取り上げる予定だ。。。と筆者が申しておりました。


 期待しています。よろしくお伝えください。

[ メッセージ編集済み 編集者: Jitta 編集日時 2002-09-21 12:20 ]
NothingButXMLInfoSet
大ベテラン
会議室デビュー日: 2002/07/16
投稿数: 116
投稿日時: 2002-09-21 16:03
引用:

Jittaさんの書き込み (2002-09-21 09:06) より:
えっと、「風穴があく」とは思っていません。クライアントPCのユーザが設定したアクセス限界まで引き上げることが可能、と理解していますが、よろしいでしょうか。


いいえ。厳密名を付けたか付けないか、ということは「ユーザが設定したアクセス限界まで引き上げること」と何の関係もありません。

引用:

htmlで、{OBJECT CLASSID="http:foo.dll#barClass" VIEWASTEXT}と埋め込んでいます。ということは、HTMLが「部分信頼コード」というわけですか?


いいえ。このOBJECTを実行しているコードが、部分信頼コードです。つまり、この場合はiehost.dllが作成したAppDomainが、コードをダウンロードしてきたWebサイトのゾーン(信頼済みサイト)に割り当てられているコードグループのパーミッションセットで作成されているので、そのAppDomainそのものが(ある意味)部分信頼コードになり、そのAppDomainに読み込まれるfoo.dllは部分信頼コードから呼ばれたことになるわけです。

.NET Frameworkのセキュリティに関しては、

引用:

HTMLをおいてあるサーバは、「信頼するサイト」に登録し、


これは関係してきますが、

引用:

「信頼するサイト」のセキュリティーは「低」にしてあります(IE側)。


これは関係ありません。


引用:

「そのアセンブリに対しては署名の検証を行わない」ようにするのは、「アセンブリ」に対してではなく、アセンブリを実行したリコンパイル(リンク)を行う「コンピュータ(またはユーザ)」に対して、ですね?


そうです。sn -Vrを実行したマシン上で稼動するCLRは、そのアセンブリに対しては署名の検証を行わなくなります。

引用:

内作ツールですが、エンドユーザ(課員ですね)には何の設定もさせたくないのです。フレームワークは、{OBJECT}{A HREF=FRAMEWORKへのパス}IE6を使用するか、ここをクリック{/A}{/OBJECT}というようなことをして、フレームワークのインストールを意識させないようにしたいと思っています。


Active Directoryドメインを組んでいれば、ソフトウェア配布機能で実現できるかもしれませんが、そうでない場合は、ユーザーにexeを「実行」してもらわない限り.NET Frameworkはインストールされませんから、インストールを意識させないことは不可能だと思いますが。。。またはWindows Update(SUS?)ってことになると思いますけど。

各クライアントに.NET Frameworkがインストールされていれば、.NET Framework Configurationで行う作業、つまり特定のアセンブリのアイデンティティに対してより高いパーミッションセットを与えるようなポリシーを作成するコードを書くことは可能です。そして、それをWindows Installerベースのインストーラに組み込み、そのmsiファイルをどうにかして実行してもらえば、各ユーザーのマシンにポリシーを配布することができます。このとき、ポリシーを配布する最良の手段は、やはりActive Directoryを活用することです。

というわけで、クライアント達がActive Directoryドメインに参加していれば、.NET Frameworkとポリシーをドメイン内の全クライアントに配布するのは簡単です。ですが、ADを組んでいない場合は、やはりユーザーの意思でexeやmsiファイルを実行してもらわなければなりません。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2002-09-24 13:22
いつもお世話になります。

引用:

NothingBut.NETFXさんの書き込み (2002-09-21 16:03) より:
いいえ。厳密名を付けたか付けないか、ということは「ユーザが設定したアクセス限界まで引き上げること」と何の関係もありません。


 勘違いしてました。もう一度記事を読み、記事中の「セキュリティーチェック」が「コード改変チェック」の意味だと書いてあることに気づきました。

引用:

.NET Frameworkのセキュリティに関しては、

引用:

HTMLをおいてあるサーバは、「信頼するサイト」に登録し、


これは関係してきますが、

引用:

「信頼するサイト」のセキュリティーは「低」にしてあります(IE側)。


これは関係ありません。


 Windows2000以降なら「管理ツール」にできる「.Net Framework ??」のツールの方が関係しますね。連動していると思ったのですが、「サイト」は連動しているが、そのサイトに対するセキュリティーレベルは、連動していないんですね。これは22日、いろいろとやってみてわかりました。また、どんなポリシーがあってどう設定すると何がOKになるのかも、少しわかってきました。

引用:

Active Directoryドメインを組んでいれば、ソフトウェア配布機能で実現できるかもしれませんが、そうでない場合は、ユーザーにexeを「実行」してもらわない限り.NET Frameworkはインストールされませんから、インストールを意識させないことは不可能だと思いますが。。。またはWindows Update(SUS?)ってことになると思いますけど。


 えっと、プロジェクトリーダがどこで線を引いているのか、私が理解し切れていないのですが、作成するアプリケーションのバージョンアップをするごとにインストーラを実行する、ことは絶対にできません。最悪、「最初の1回だけ、実行ファイルを起動させる」としたいと思っています。
引用:

各クライアントに.NET Frameworkがインストールされていれば、.NET Framework Configurationで行う作業、つまり特定のアセンブリのアイデンティティに対してより高いパーミッションセットを与えるようなポリシーを作成するコードを書くことは可能です。


このポリシーを作成するコードとは、実行したクライアントでポリシーを作成して登録する、ととらえてよろしいですか?このコードを、ActiveDirectoryを使用せずに、.NET Frameworkのランタイムとともに配布して適用させることは可能ですか?
 「最良の方法はActiveDirectory」というのは、ADだと管理者の方で一括管理できるから、ですよね。しかし、CALなどの問題から、少なくとも今年度では無理だと思います。
NothingButXMLInfoSet
大ベテラン
会議室デビュー日: 2002/07/16
投稿数: 116
投稿日時: 2002-09-25 00:31
引用:

Jittaさんの書き込み (2002-09-24 13:22) より:
このポリシーを作成するコードとは、実行したクライアントでポリシーを作成して登録する、ととらえてよろしいですか?このコードを、ActiveDirectoryを使用せずに、.NET Frameworkのランタイムとともに配布して適用させることは可能ですか?


えと、Windows InstallerのMSIファイルを作成するということです。で、.NET Framework Configuration管理ツールの範囲で作成できるポリシーで、マシンに単純に適用すればそれでいいという場合は、.NET Framework Configuration管理ツールでMSIファイルを作成する機能がありますので、それを使えばいいと思います。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2002-09-26 08:52
いつも世話になります。

引用:

NothingBut.NETFXさんの書き込み (2002-09-21 16:03) より:
いいえ。厳密名を付けたか付けないか、ということは「ユーザが設定したアクセス限界まで引き上げること」と何の関係もありません。


 .NET Framework Configurationをいろいろさわってみました。設定の仕方によっては、厳密名が必要ですね。「ランタイムセキュリティーポリシー→コンピュータ→コードグループ」で新規作成しましたが、信頼の仕方が
1.すべてのアセンブリ
2.アプリケーションディレクトリ(アプリケーションが起動したディレクトリ)
3.ハッシュ(特定のアセンブリに限定)
4.発行者(アセンブリに証明機関から発行された証明書を添付した場合)
5.サイト(特定のサイトにあるすべてのアセンブリ)
6.厳密名(公開キー、アプリケーション名、バージョンを指定して限定)
7.URL(特定のURLの下にあるアセンブリすべて)
8.ゾーン(IEのセキュリティータブにあるゾーン)
とありました。このうち、3,6(おそらく4も)を指定すると、厳密名がなければならないようです。


引用:

NothingBut.NETFXさんの書き込み (2002-09-25 00:31) より:
えと、Windows InstallerのMSIファイルを作成するということです。で、.NET Framework Configuration管理ツールの範囲で作成できるポリシーで、マシンに単純に適用すればそれでいいという場合は、.NET Framework Configuration管理ツールでMSIファイルを作成する機能がありますので、それを使えばいいと思います。


 とりあえず、.NET Framework Runtimeを配布するための、セットアッププロジェクトを作成しました。それの「カスタム動作」で、ポリシーを記したMSIファイルを実行させるようにすればよいようですね。

 長々と、どうもありがとうございました。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2002-10-03 18:34
 「これだけ教えてもらえれば、後は自分でできるだろう」と思ったのですが、やっぱりわかりません。

引用:

NothingBut.NETFXさんの書き込み (2002-09-25 00:31) より:
えと、Windows InstallerのMSIファイルを作成するということです。で、.NET Framework Configuration管理ツールの範囲で作成できるポリシーで、マシンに単純に適用すればそれでいいという場合は、.NET Framework Configuration管理ツールでMSIファイルを作成する機能がありますので、それを使えばいいと思います。



 .NET Framework Configration管理ツールで、「名前付きアクセス許可セット」と「コードグループ」を追加しました。これで望み通りに動作できるだけの「許可」を与えられたので、そのポリシーを配布しようと思いました。

 そこで管理ツールを起動したのですが・・・管理ツールの右側のツリービューが表示されているペインで「ランタイムセキュリティーポリシー」を右クリックすると「配置パッケージの作成」というメニューがありました。しかし、これだと必要以上のポリシー、つまりこのコマンドを実行したマシンに設定されているポリシーのすべてが配置パッケージに入ってしまいませんか?
#Active Directory で配置可能なファイル?

 F1を押したり「操作→ヘルプ」をしてみたのですが、MMCのヘルプが表示されるのです。かといって、MSDNだと探しきれないし・・・(いや、いろいろ試したんですよ)

 そう、こう、しているうちに「コードアクセスセキュリティーポリシーツール」なるモノに行き当たり、これでバッチファイルを組んでポリシーを設定できることがわかりました。ところが、肝心の「アクセス許可セット」をXMLで記述する方法に行き当たりません。GUIで作成してからsecurity.configをコピーし、追加したアクセス許可セットだけを抜き出してみましたが、「?>タグが理解できない」、という理解不可能なエラーが出たり・・・
#だって、xmlファイルであることを宣言している箇所ですよ。「xmlで」と指定しておきながら、そして自分で作ったモノなのに、どうして理解できないの?

 申し訳ありませんが、『つまり特定のアセンブリのアイデンティティに対してより高いパーミッョンセットを与えるようなポリシーを 作成するコードを書く』方法をお教えください。

スキルアップ/キャリアアップ(JOB@IT)