4

現在、プロジェクト用のカスタム コード アクセス セキュリティ ソリューションを構築しようとしています。

したがって、次のように使用する必要がある CustomPermissionAttribute を作成しました。

[CustomPermissionAttribute(SecurityAction.Demand, Permission="PermMethodABC")]
public void MethodABC() 
{ 
}

AttributeのCreatePermission()メソッドは、新しい CustomPermission インスタンスを作成して返します。

CustomPermission クラスの Demand メソッドは、Thread.Current.CurrentPrincipial のカスタム IPrincipial 実装に対してセキュリティをチェックする必要があります。

public sealed class CustomPermission : IPermission
{
    private string _RequiredPermission;
    ...
    public void Demand()
    {
        ICustomPrincipial _pr = Thread.Current.CurrentPrincipial as ICustomPrincipial;
        if (_pr == null) throw...
        if (!_pr.HasPermission(_RequiredPermission)) throw...
    }
}

public interface ICustomPrincipial : IPrincipial
{
    bool HasPermission(string RequiredPermission);
}

上記はすべて、署名済みの「アセンブリ A」にあります。

署名されていないアセンブリ B には、アセンブリ A の ICustomPrincipial を実装する次の CustomPrincipial 実装が含まれています。

public sealed class CustomPrincipial : ICustomPrincipial
{
    User _User;
    ...
    public bool HasPermission(string RequiredPermission)
    {
        if (_User has permission defined with "PermMethodABC") ...
        return true/false;
    }
    ...
}

(ここで、アセンブリ A はユーザー型について何かを知る必要があります。CustomPrincipial クラスをアセンブリ A に配置すると、ユーザーのものを含むすべてのアセンブリも署名する必要があります...そうしないと、アセンブリ A をコンパイルできません)

アプリケーションの起動時に、CustomPrincipial の新しいインスタンスが Thread.Current.CurrentPrincipial に割り当てられます。

2 つの質問:

  • アセンブリ A のパブリック ICustomPermission インターフェイスによって安全上の問題が発生する可能性はありますか?

  • すべての IPermission メンバーを完全に実装することは絶対に必要ですか? 特に ToXML および FromXML メソッド... CreatePermission() メソッドは、実行時に MethodABC() にアクセスするたびに呼び出されます。

編集: 広告 1: 次の状況を考えています:「アセンブリ C」には、CustomPermissionAttribute で保護されている MethodXY が含まれています。この保護されたメソッドにアクセスするために、攻撃者は新しいアプリケーションを作成し、アセンブリ A とアセンブリ C を参照し、アセンブリ A のパブリック ICustomPrincipial インターフェイスの独自の実装を作成する可能性があります (-> HasPermission() は常に true を返します)。彼は自分の実装のインスタンスを自分の Thread.Current.CurrentPrincipial に割り当てることができました。アセンブリ A の Demand() メソッドが Thread.Current.CurrentPrincipial をチェックすると、攻撃者が MethodXY にアクセスできるようになります。そんな可能性も…!?

4

1 に答える 1

1

アセンブリ A のパブリック ICustomPermission インターフェイスによって安全上の問題が発生する可能性はありますか?

アクセス許可に注意していると仮定すると、Thread.Current.CurrentPrincipalは他のほとんどのプログラムに対して読み取り専用であり、バイパスが不可能になります。(少なくとも、MSDN ページを一目見ただけでは)

ただし、セキュリティの問題と同様に、自分でテストするのがおそらく最善です。環境で実行され、独自のバイパス方法を実装するコードを書いてみてくださいCurrentPrincipal。

すべての IPermission メンバーを完全に実装することは絶対に必要ですか? 特に ToXML および FromXML メソッド... CreatePermission() メソッドは、実行時に MethodABC() にアクセスするたびに呼び出されます。

msdnページに完全な実装の例があります。実行するのはそれほど面倒ではありませんNotImplementedException。

IPermissionただし、通常の操作中にどのメソッドが呼び出されるかを知るのに十分な実験を行っていません。

編集：これはコメントですが、少し長いです。

覚えておくべき重要なことの 1 つは、コードにプリンシパルを変更するアクセス許可がある場合、そのコードがアクセス許可をバイパスするのを止めるためにできることはあまりないということです。要求SecurityPermissionFlag.ControlPrincipalを設定する許可です。CurrentPrincipalCaspol.exe などのツールを使用しない限り、実行可能ファイルは既定で完全な信頼の下で実行されると思います。

要約すると、既定では、.NET フレームワークはカスタム コードが完全に信頼されていると見なします。信頼していないコードを呼び出している場合、コードがより低いセキュリティ資格情報で実行されることを保証するメカニズムがあります。または、信頼していない実行可能ファイルがある場合は、そのセキュリティ資格情報を低くすることができます。ただし、マシンの管理者には、実装するコードアクセスセキュリティをバイパスするのに十分な力があります（IPrincipalオーバーライドでコメントしたように）。

これで十分に説明できない場合はお知らせください。詳細を追加できます。

于 2012-05-31T21:02:55.423 に答える