Comment nier Assert avec CAS?

Question

Dans ce code, j'aimerais que la méthode ReadFileSystem soit interdite pour asserter une autorisation sur le système de fichiers.

Je pensais que cela lancerait fileIo.Assert (), mais ce n’est pas le cas. Pourquoi?

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();
}

Mise à jour

Excellent lien ici sur CAS: http: // blogs .msdn.com / shawnfa / archive / 2004/08/25 / 220458.aspx

Answer 1

L'assertion suivante annule les effets du refus.

La possibilité d'affirmer FileIOPermission dépend principalement du fait que votre assembly est approuvé ou non. Il n'est pas affecté par un précédent refus de FileIOPermission. Il s'avère également que le précédent refus d'assertion SecurityPermission ne l'a pas affecté. Cela est dû au fait que SecurityPermissionFlag.Assertion est coché en tant que demande de temps de liaison. Ceci n'est pas clairement documenté. Je l’ai trouvé ici .

Pour forcer le CLR à ne pas faire confiance à votre assembly pour FileIOPermission, vous pouvez utiliser les éléments suivants en haut de votre fichier après les instructions using. Lorsque vous ajoutez ceci à votre fichier, l'assertion ne prendra pas effet. Cela affecte l'ensemble de l'assemblée. Il n’ya pas de granularité plus fine.

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

Answer 2

Je pense que vous pouvez mal comprendre le but de l’affirmation des autorisations. Lorsque vous affirmez un jeu d'autorisations dans CAS, vous dites en réalité "Je sais ce que je fais ... Je me fiche de ce que les autorisations sont plus profondes dans la pile". C'est presque jamais ce que vous voulez. Vous souhaitez généralement demander un ensemble d'autorisations. Cela provoque une marche de la pile, qui trouve le refus sur la pile, puis une exception de sécurité.

Cependant, étant donné que .NET a pratiquement toutes les demandes nécessaires intégrées, il est rarement nécessaire d'exiger quoi que ce soit à moins que vous ne fassiez Asserts (là encore, c'est rare) ou que vous ayez écrit votre propre classe Permission personnalisée.

Answer 3

Bonne question à coup sûr. J'ai couru le code et je suis un peu mystifié aussi. Je viens de passer une heure ou deux à étudier la documentation et la recherche sur Google, mais en vain. Notez que MSDN échappe en faisant une autorisation Demander sur l'assertion.

Edit: la réponse du codeur binaire m'a orienté dans la bonne direction.

Les droits Asserion ne sont tout simplement pas effectifs dans un ensemble complet. Seulement si vous ajoutez les éléments suivants en haut du fichier:

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

l'appel à fileIo.Assert () échouera.

Mais sinon, essayer de refuser à Deny () l'autorisation d'assertion et l'attribut suivant est totalement inefficace (sauf si vous demandez explicitement les droits d'assertion).

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

La documentation indique qu'Assert () "a des problèmes de sécurité" et la recommandation est de toujours demander avant l'assert:

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

mais je dois encore réajuster mon état d'esprit concernant l'application du principe du moindre privilège.