Come negare Assert con CAS?

Question

In questo codice, vorrei che il metodo ReadFileSystem fosse vietato per richiedere un'autorizzazione sul filesystem.

Mi aspettavo che questo potesse essere lanciato su fileIo.Assert (), ma non lo è. Perché?

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

Aggiorna

Ottimo link qui su CAS: http: // blogs .msdn.com / shawnfa / archive / 2004/08/25 / 220458.aspx

Answer 1

Il successivo Assert annulla gli effetti del Nega.

La capacità di affermare FileIOPermission dipende principalmente dall'affidabilità dell'assembly. Non è interessato da un precedente Deny of FileIOPermission. Si scopre che non è influenzato dal precedente Deny of the Assertion SecurityPermission. Questo perché SecurityPermissionFlag.Assertion è controllato come richiesta di tempo di collegamento. Questo non è chiaramente documentato; L'ho trovato qui .

Per forzare il CLR a non fidarsi dell'assembly per FileIOPermission, è possibile utilizzare quanto segue nella parte superiore del file seguendo le istruzioni using. Quando aggiungi questo al tuo file, l'asserzione non avrà effetto. Ciò riguarda l'intero assieme. Non esiste una granularità più fine.

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

Answer 2

Penso che potresti fraintendere lo scopo dell'asserzione delle autorizzazioni. Quando asserisci un set di autorizzazioni in CAS, stai effettivamente dicendo " So cosa sto facendo ... Non mi interessa quali autorizzazioni sono più profonde nello stack. & Quot; È quasi mai quello che vuoi. In genere si desidera richiedere un set di autorizzazioni. Ciò provoca uno stack walk, che trova il Nega nello stack e quindi causa un'eccezione di sicurezza.

Tuttavia, poiché .NET ha praticamente tutte le richieste necessarie integrate, raramente è necessario richiedere effettivamente qualcosa a meno che non si eseguano Assert (di nuovo, è raro) o non si sia scritta la propria classe di autorizzazione personalizzata.

Answer 3

Buona domanda di sicuro. Ho eseguito il codice e sono anche un po 'sconcertato. Trascorro solo un'ora o 2 a studiare i documenti e a cercare su Google ma senza risultati. Si noti che MSDN fa i conti facendo una richiesta sull'autorizzazione di asserzione.

Modifica: la risposta di binarycoder mi ha indicato la giusta direzione.

I diritti di Asserion sono semplicemente non efficaci in un assieme a piena spinta. Solo se aggiungi quanto segue all'inizio del file:

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

la chiamata a fileIo.Assert () fallirà.

Ma per il resto, tentare di Negare () l'autorizzazione di Asserzione e il seguente attributo sono totalmente inefficaci (a meno che non si richieda esplicitamente () i diritti di Asserzione).

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

La documentazione afferma che Assert () "presenta alcuni problemi di sicurezza" e la raccomandazione è di richiedere sempre prima dell'asserzione:

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

ma devo ancora modificare la mia mentalità sull'applicazione del principio del privilegio minimo.