問題タブ [code-access-security]

シェル アプリケーションでは、実行時に他の .NET アセンブリを読み込んで実行できる必要がありますが、それらに完全な信頼を与えることはできません。基本的に、それら (ロードされたアセンブリ) がシステム リソース (スレッド、ネットワークなど) に触れないように制限したいと考えています。 ただし、分離ストレージは例外です。ただし、「自分」からのアセンブリは、完全な信頼で実行する必要があります。

Code Access Security を検討していますが、それを使用すべきかどうかはよくわかりません。

これについてどう思いますか？

ハンドオフ パッケージの msi の隣にあるいくつかのファイルを展開するために使用しているカスタム アクションがあります。私のカスタム アクションは、OriginalDatabase パラメーターを介して msi パスを渡され、その横にフォルダーがあるかどうかを確認しています。クレイジーなことは何もありませんが、理解するのは大変でした。

ローカルにコピーされたファイルから単一または複数のユーザーをインストールすることは、チャンピオンのように機能します。ネットワーク共有から setup.exe を実行しているときに単一ユーザーをインストールすると問題なく動作しますが、ネットワーク共有からすべてのユーザーをインストールすると、セキュリティ例外が発生します。

問題の行は次のとおりです。

カスタム アクションは で実行されるSecurityAction.Demandため、必要なすべてのアクセス権が必要です。

誰でも提供できる情報は大歓迎です。

ありがとう、ケーシー

.NET 2.0 の Code Access Security について勉強しています。私の現在の理解は次のとおりです。

CAS の基本的なメカニズムは、CLR がアセンブリから特定の証拠を収集し、証拠とポリシーを使用してアセンブリのコードのアクセス許可セットを作成することです。そして、アセンブリのコードは、そのアクセス許可セットを超えて何もできません。

エビデンスは、特定のアセンブリを特定のコード グループに分類するために使用され、コード グループの粒度で許可セットが与えられます。

実行時に CLR によって収集できる証拠には、いくつかの種類があります。

Application Directory、GAC、Hash、Strong Nameなどの証拠を簡単に特定できます。

しかし、発行元、サイト、ゾーン、URLなどの証拠を特定するにはどうすればよいでしょうか。これらの証拠データはどこに保存されますか? それらはアセンブリのメタデータの一部ですか? Zone や Site などの証拠をメタデータの一部にする必要はないと思います。

どうもありがとう。

CAS をテストするために、次のコードを作成しました。

.NET 2.0 構成では、上記のアセンブリの厳密な名前を使用してコード グループを作成し、そのグループにNothing権限セットを付与します。そのため、アセンブリは期待どおりに開始できませんでした。

しかし、次の属性を削除すると、次のことに気付きました。

プログラムはまだ開始できませんでした。では、属性を使用したこのいわゆる宣言型セキュリティのポイントは何でしょうか?

CAS に関するいくつかのチュートリアルを読みましたが、それらは命令型/宣言型セキュリティを使用して CAS を使用しています。しかし、上記のサンプルから、それは必要ではないようです。

命令型/宣言型セキュリティを使用せずに意図的にコードを記述し、アセンブリの証拠を提供しない場合、CAS はセキュリティ ポリシーを強制できなくなりますか?

または、CAS の使用方法を誤解していますか?

ありがとう。

使用例:

複数の ASP.Net アプリケーションがホストされているホスティング プラットフォーム (サーバー) があります。アプリケーションがサーバー上の証明書にプログラムでアクセスできるようにしたくありません。プラットフォームの所有者によって開発されたコンポーネント/ライブラリのみが、これらの証明書にアクセスできる必要があります。

アプリケーションが証明書関連の操作を行うためにプラットフォーム コンポーネントのみを使用することを制限する方法はありますか。

参考までに、すべての証明書は固定フォルダーにファイルとして保存されます。

プラットフォーム ライブラリにそれらの証明書へのアクセスを許可し、他のライブラリ/コンポーネント/アプリケーションが証明書にアクセスするのを拒否できるコード アクセス許可を実装できますか?

C#でウィンドウアプリケーションを開発しています。この Windows アプリケーションで 1 つのインストーラーを作成しました。ほぼすべてのコンピューターで問題なく動作しています。ウィンドウ アプリケーションはプロセッサの ID を取得し、その ID に基づいて 1 つの一意のキーを生成します。1 台のコンピューターで、「Windows インストーラーはキーを生成できませんでした。管理者に連絡してください」というエラーが表示されます。.net コードをデバッグしたところ、プロセッサ ID にアクセスするための適切な権限がないことがわかりました。私は何をする必要がありますか？特定のコンピュータのプロセッサ ID にアクセスするには、.net (ウィンドウ アプリケーション) で信頼レベルを設定する方法を教えてください。上記の問題を解決できるコード、リンク、または手順を教えてください。

さて、皆さんのほとんどは wspbuilder を使用して wsp ソリューションを構築し、展開していると思います。だからここに私の問題があります。

私は、豊富な経験のためにサードパーティの dll (Telerik for Asp.Net Ajax - Telerik.Web.UI.dll) を利用する SharePoint ソリューションに取り組んでいます。Telerik dll は一般的なアセンブリであるため、GAC ではなく Web アプリケーションの bin フォルダーにデプロイする必要があります。ここで問題が発生します。

dll が GAC フォルダーに存在する場合、WSPBuilder は自動的に dll を gac にデプロイします。bin に telerik dll をデプロイするために、フォルダー 80\bin を作成し、そこに dll をコピーしました。wsp を再度ビルドしようとした後、作成された manifest.xml を確認しました。偉大な。dll の展開先を WebApplication に変更し、wspbuilder は cas ポリシー自体を作成するのが賢明でした。

しかし、Wspbuilder は、SharePointPermission IPermission クラスの 4 部構成の名前を付けるほどスマートではありませんでした。しかし、CAS には実際には 4 つの部分からなる名前が必要であることを知りました。そこで、wspbuilder.exe の -CustomCAS コマンド ライン オプションを使用して、カスタム cas ポリシー ファイルを渡すことにしました。

これが私のカスタム ポリシー ファイルです。

したがって、wsp をビルドした後、manifest.xml の cas セクションはこれを読み取ります -

wspをデプロイした後、確認しました

しかし、ページを実行すると、次のエラーが発生します-

スクリーンショット -

エラー -

実行権限が拒否されました

スタックトレース -

スタック トレースが必要かどうか教えてください。迷惑なくらい大きいです。

dll のアセンブリ参照がないか、アプリケーション全体をチェックしました。しかし、私はそれを見つけることができませんでした。何か案は？

コードアクセスセキュリティに関するこの記事について読んだばかりです。その中にそのような例があります：

FileIOPermissionAccessタイプを使用せず、コードにp.Demand（）のようなコードをまったく含めなかった場合はどうなりますか？言い換えれば、私が何か悪いことをしたいのなら、なぜ私はそれについて許可を求める必要があるのですか？ 冗談じゃないですか？または私はそれを間違えましたか？

私はいくつかの (wordpress) プラグインを開発しており、それを使用したい人にはライセンス料を支払う予定です。

そのため、このプラグインが、誰でもダウンロードして無料で使用できるサーバーにアップロードされないようにする方法が必要です。

そこで、API キーを使用することを考えていました。有効な API キー = ユーザーはプラグインを使用できます。無効 = プラグインは機能しません。

この投稿PHP API Key Generatorを見てきましたが、あまり賢くはありません。

PHPなので、誰でもコードにアクセスしてAPIチェックを無効にできることも知っています（推測です）

プラグインを保護する最善の方法は何ですか? APIキー? 他の方法？このテーマに関する優れたチュートリアルへのリンクを持っている人はいますか?

開発中にコードを保護して、開発者が会社を辞めた場合にプロジェクト内のファイルにアクセスできないようにする方法はありますか？

これは、プロジェクトがローカルにダウンロードされ、キャッシュされ、オフラインで使用できるTFSでは特に重要です。理想的には、有効なActive DirectoryユーザーIDがない場合、コードは読み取れません。

このアイデアが不可能な場合でも、私はあなたが考えることができる実用的な抑止力について学びたいと思います...