Wie Assert mit CAS zu verweigern?

Question

In diesem Code würde ich die ReadFileSystem Methode mag verboten werden, um eine Berechtigung für das Dateisystem zu behaupten.

Ich erwartete dies bei fileIo.Assert werfen (), aber es funktioniert nicht. Warum?

using System.Security.Permissions;
static void Main(string[] args)
{
    var fileIo = new FileIOPermission(PermissionState.Unrestricted);
    var secuPerm = new SecurityPermission(SecurityPermissionFlag.Assertion);
    PermissionSet set = new PermissionSet(PermissionState.Unrestricted);
    set.AddPermission(fileIo);
    set.AddPermission(secuPerm);
    set.Deny();
    ReadFileSystem();
    Console.Read();
}

private static void ReadFileSystem()
{
    var fileIo = newFileIOPermission(PermissionState.Unrestricted);
    fileIo.Assert();

    DirectoryInfo dir = new DirectoryInfo("C:/");
    dir.GetDirectories();
}

Update

Großer Link hier auf CAS: http: // blogs .msdn.com / shawnfa / Archiv / 2004/08/25 / 220458.aspx

Answer 1

Die anschließende Assert negiert die Auswirkungen der Verweigern.

Die Fähigkeit FileIOPermission hauptsächlich geltend zu machen, hängt davon ab, ob die Assembly vertrauenswürdig ist. Es ist nicht betroffen durch eine vorherige von FileIOPermission verweigern. Es stellt sich heraus, dass es auch nicht durch die vorherige des Assertion Security Deny betroffen ist. Das ist, weil SecurityPermissionFlag.Assertion als Link Zeitbedarf geprüft Dies ist nicht klar dokumentiert. Ich fand es hier .

, um die CLR zu zwingen, nicht die Assembly für FileIOPermission zu vertrauen, können Sie Folgendes an der Spitze Ihrer Datei im Anschluss an die Verwendung von Anweisungen verwenden. Wenn Sie dies zu Ihrer Datei hinzufügen, wird die Assertion nicht wirksam. Dies wirkt sich auf die gesamte Baugruppe. Es gibt keine feinere Granularität.

[assembly:FileIOPermission(SecurityAction.RequestRefuse, Unrestricted=true)]

Answer 2

Ich denke, man kann den Zweck der Geltendmachung Berechtigungen falsch verstehen. Wenn Sie einen Berechtigungssatz in CAS Behaupten, sagen Sie effektiv „Ich weiß, was ich tue ... ist mir egal, was die Berechtigungen in dem Stapel tiefer sind.“ Das ist fast nie , was Sie wollen. Sie wollen in der Regel einen Berechtigungssatz verlangen. Das führt zu einem Stapel zu Fuß, die auf dem Stapel das Verweigern finden würden und dann eine Sicherheitsausnahme verursachen.

Da jedoch .NET alle hat praktisch die notwendigen Anforderungen eingebaut, gibt es selten eine Notwendigkeit, tatsächlich etwas zu fordern, es sei denn du tust Asserts (wieder, das ist selten) oder Sie haben Ihre eigene benutzerdefinierte Berechtigungsklasse geschrieben.

Answer 3

Gute Frage sicher. Ich lief den Code und bin ein bisschen zu mystifiziert. Ich gebe nur eine Stunde oder 2 die Dokumentation studieren und googeln, aber ohne Erfolg. Beachten Sie, dass MSDN Cops heraus durch eine Nachfrage auf der Assertion Erlaubnis zu tun.

Edit: binarycoder Antwort wies mich in die richtige Richtung

.

Die Asserion Rechte sind einfach nicht effektiv in einer Vollschubanordnung. Nur wenn Sie Folgendes an dem Anfang der Datei hinzufügen:

[assembly: SecurityPermissionAttribute(SecurityAction.RequestRefuse, Assertion = true)] 

der Aufruf an fileIo.Assert () fehl.

Aber ansonsten versuchen, die Assertion Erlaubnis zu verweigern () und das folgende Attribut ist völlig wirkungslos (es sei denn, Sie explizit die Assertion Rechte einfordern ()).

[SecurityPermissionAttribute(SecurityAction.Deny, Assertion = true)]
private static void ReadFileSystem() {}

In der Dokumentation wird das Assert () ‚einige Sicherheitsprobleme hat‘ und die Empfehlung ist immer die Nachfrage-vor-Assertion:

fileIo.Demand();
fileIo.Assert();

, aber ich muss noch meine Einstellung nachjustieren über das Prinzip der geringst möglichen Privilegien angewendet wird.