none
コードアクセスセキュリティについて RRS feed

  • 質問

  • お世話になっております。

     

    VS2005を使用してコードアクセスセキュリティを勉強しているのですが、

    教科書通りの動きをせず悩んでおります。

     

    c:\boot.iniファイルを読み込む(コンソール上に表示する)DLLアセンブリと

    そのDLLアセンブリを利用するEXEを作成して、動作の確認をしているのですが、

     

    ①まずこれらのモジュールを、c:\tempフォルダに配置して実行する

      c:\temp\test.exeを実行→(記述内容)問題なくファイルが読み込まれる

      →実際の結果:読み込まれた

      記述内容:起動時のゾーンが「My_Computer_Zone」であり、アクセス許可セットが「FullTrust」であるため

             問題なくアクセスができる。

     

    ②c:\tempフォルダを共有フォルダにし、UNC名で実行する

      \\machine\shared\test.exe→((記述内容))例外エラーがでる

      →実際の結果:読み込まれた(例外エラーがでない・・・)

      記述内容:起動時のゾーンは「LocalIntranet_Zone」で、アクセス許可セットが「LocalIntranet」であるため

             無制限のファイルI/Oは許されていない。

     

      なぜかアクセスしおります。

     

    MMCを利用してマシンポリシーを見たのですが、教科書通りの設定となっておりました。

     

     

    この場合、どこに原因があるのでしょうか?

    ご教授ください。

     

     

     

    2008年9月4日 4:22

回答

  •  TAKAKUN さんからの引用

    確かに「Visual Studio 2008 Service Pack 1」をインストールしています。

    ゾーンのエビデンスを決めるのは、誰(どこ)なんでしょうか?

    .NET FrameworkのCLRあたりでしょうか?

    この辺はあまり詳しくないので確たることは言えません。

     

     TAKAKUN さんからの引用

    Microsoft .NET Framework 3.5をインストールしない限り、

    共有フォルダはイントラネットゾーンとなり、インストールするとマイコンピュータゾーン

    のエビデンスをもつことになるのでしょうか?

    先の回答で.NET Framework 3.5 Service Pack 1と言いました。

    .NET Framework 3.5自体にはその変更が含まれていません。

     

     TAKAKUN さんからの引用

    これってセキュリティ的に問題ないのでしょうか?

    ユーザー(管理者)が今までは、共有フォルダのアプリケーション実行は、

    イントラネットゾーンのエビデンスをもつことになるので、

    与えるパーミッションをいろいろ設定したのに、いつのまにかフルアクセスとなっている

    なんてことありなんでしょうか?

    そのセキュリティリスクよりも、利便性を重視したと言うことでしょう。

    変更点リストには明記されているので、細かく設定するユーザはこの辺を意識してもらえると期待しているのではないでしょうか。

     

    http://www.microsoft.com/downloads/details.aspx?FamilyID=AB99342F-5D1A-413D-8319-81DA479AB0D7&displaylang=ja

    また、ネットワーク共有から開かれているマネージ アプリケーションは、完全信頼で実行されることによって、ネイティブ アプリケーションと同じように動作します。

     

    なお、.NET 3.5 SP1適用前の動作に戻すレジストリーキーの設定があります。

    詳細については下記の記事を参照して下さい。

    http://blogs.msdn.com/shawnfa/archive/2008/05/12/fulltrust-on-the-localintranet.aspx

    2008年9月5日 16:19
    モデレータ
  •  

    ご返事ありがとうございました。

     

    大変為になりました。

    理解も進みそうです。

     

     

    2008年9月9日 0:11

すべての返信

  • 自己レスです。

    まだ解決はしてはおりませんが、UNCパスで実行時の

    DLLアセンブリがロードされたときのエビデンスが収集されたときの

    値を確認してみました。

     

    System.Security.Policy.Zone→「Zone:MyComputer」

     

    ???

     

    モジュール自体を、別PCに配置して、自分PCからUNCで実行しても

     

    System.Security.Policy.Zone→「Zone:MyComputer」

     

    イントラネットゾーンで実行する方法って??

     

     

     

    2008年9月4日 4:50
  •  TAKAKUN さんからの引用

    モジュール自体を、別PCに配置して、自分PCからUNCで実行しても

    System.Security.Policy.Zone→「Zone:MyComputer」

    イントラネットゾーンで実行する方法って??

    .NET Framework 3.5 Service Pack 1かVisual Studio 2008 Service Pack 1をインストールしていませんか?

    .NET Framework 3.5 Service Pack 1から仕様が変更され、共有フォルダのファイルを実行してもMyComputer扱い(FullTrust)になりました。

     

    インストールしているかどうかを知るには、プログラムの追加と削除で「Microsoft .NET Framework 3.5 Service Pack 1」が一覧にあるかどうかで分かります。

    2008年9月4日 14:48
    モデレータ
  • ご返事ありがとうございます。

     

    確かに「Visual Studio 2008 Service Pack 1」をインストールしています。

    ゾーンのエビデンスを決めるのは、誰(どこ)なんでしょうか?

     

    Microsoft .NET Framework 3.5をインストールしない限り、

    共有フォルダはイントラネットゾーンとなり、インストールするとマイコンピュータゾーン

    のエビデンスをもつことになるのでしょうか?

     

    これってセキュリティ的に問題ないのでしょうか?

    ユーザー(管理者)が今までは、共有フォルダのアプリケーション実行は、

    イントラネットゾーンのエビデンスをもつことになるので、

    与えるパーミッションをいろいろ設定したのに、いつのまにかフルアクセスとなっている

    なんてことありなんでしょうか?

    2008年9月5日 5:23
  •  TAKAKUN さんからの引用

    確かに「Visual Studio 2008 Service Pack 1」をインストールしています。

    ゾーンのエビデンスを決めるのは、誰(どこ)なんでしょうか?

    .NET FrameworkのCLRあたりでしょうか?

    この辺はあまり詳しくないので確たることは言えません。

     

     TAKAKUN さんからの引用

    Microsoft .NET Framework 3.5をインストールしない限り、

    共有フォルダはイントラネットゾーンとなり、インストールするとマイコンピュータゾーン

    のエビデンスをもつことになるのでしょうか?

    先の回答で.NET Framework 3.5 Service Pack 1と言いました。

    .NET Framework 3.5自体にはその変更が含まれていません。

     

     TAKAKUN さんからの引用

    これってセキュリティ的に問題ないのでしょうか?

    ユーザー(管理者)が今までは、共有フォルダのアプリケーション実行は、

    イントラネットゾーンのエビデンスをもつことになるので、

    与えるパーミッションをいろいろ設定したのに、いつのまにかフルアクセスとなっている

    なんてことありなんでしょうか?

    そのセキュリティリスクよりも、利便性を重視したと言うことでしょう。

    変更点リストには明記されているので、細かく設定するユーザはこの辺を意識してもらえると期待しているのではないでしょうか。

     

    http://www.microsoft.com/downloads/details.aspx?FamilyID=AB99342F-5D1A-413D-8319-81DA479AB0D7&displaylang=ja

    また、ネットワーク共有から開かれているマネージ アプリケーションは、完全信頼で実行されることによって、ネイティブ アプリケーションと同じように動作します。

     

    なお、.NET 3.5 SP1適用前の動作に戻すレジストリーキーの設定があります。

    詳細については下記の記事を参照して下さい。

    http://blogs.msdn.com/shawnfa/archive/2008/05/12/fulltrust-on-the-localintranet.aspx

    2008年9月5日 16:19
    モデレータ
  •  

    ご返事ありがとうございました。

     

    調べたところエビデンスを決めるのは、CLRみたいなのですが、

    「.NET Framework 3.5 Service Pack 1」を入れることで、CLRの仕様が変更され

    .NETFramework2.0以降で作成した.NETアプリケーションすべてが

    アクセスセキュリティが変更されるということですね。

     

    .NETFramework1.1で作成すると、いままでのようにイントラネットのゾーンエビデンスが与えられるかを

    見てみたのですが、エビデンス自体取れなかったです。

     

     

     

     

     

     

     

    2008年9月8日 3:30
  •  TAKAKUN さんからの引用

    .NETFramework1.1で作成すると、いままでのようにイントラネットのゾーンエビデンスが与えられるかを

    見てみたのですが、エビデンス自体取れなかったです。

    .NET Framework 1.1には影響を与えていないので、多分権限の問題で実行できないのでしょう。

    .NET Framework 3.5のService Pack 1を当てていない環境では、(ネットワーク上のフォルダから)エビデンス取得のアプリは実行できません。(権限がない)

    2008年9月8日 13:43
    モデレータ
  •  

    ご返事ありがとうございました。

     

    大変為になりました。

    理解も進みそうです。

     

     

    2008年9月9日 0:11