Code Access Security è uno scherzo?

Question

Ho appena letto su questo article su Code Access Security. Ha un tale esempio in esso:

using System.Security.Permissions; 
public class MyFileAccessor 
{ 
    public MyFileAccessor(String path, bool readOnly) 
    { 
    path = MakeFullPath(path); // helper fcn 
    FileIOPermissionAccess desiredAccess = readOnly 
     ? FileIOPermissionAccess.Read 
     : FileIOPermissionAccess.AllAccess; 
    FileIOPermission p = new FileIOPermission(desiredAccess, path); 
    p.Demand(); 
    // 
    ••• 
    open the file 
    } 
    // ••• 
} 

Che cosa succede se non ho usato il tipo FileIOPermissionAccess e mai INCLUD codice come p.Demand() nel mio codice a tutti? In altre parole, se voglio fare qualcosa di male, perché dovrei preoccuparmi di chiedere il permesso per questo? Non è uno scherzo? O ho sbagliato?

Answer 1

Beh, sì, l'esempio è un po 'uno scherzo, non scriverei mai qualcosa di simile. Quello che manca è la parte veramente importante, il codice che // apre il file. Una versione realistica di esso sarebbe, diciamo, pinvoke CreateFile().

Il punto è che Windows non sa nulla di CAS.Quindi se fornisci una funzione di utilità come questa e vuoi applicare le regole CAS, devi verificare che il tuo codice abbia il permesso richiesto. Naturalmente, questo tipo di codice appartiene solo al framework .NET. Dai un'occhiata a FileStream.Init() e nota che FileIOPermission viene richiesto lì prima della chiamata a CreateFile.

Answer 2

L'accesso ai file (ad esempio utilizzando FileStream) richiederà automaticamente FileIOPermission. E questo è così per tutte le classi standard, quando eseguono un'azione che richiede il permesso, la richiederanno automaticamente. Guarda in Sicurezza .NET Framework here. Quindi il codice di esempio è inutile, nessuno richiederà esplicitamente le autorizzazioni per i file. È ragionevole che tu sviluppi alcune API e che il tuo codice sia firmato in modo che nessuno possa cambiarlo.

Lettura ulteriormente, ecco citazione da tale articolo:

Ora, nel mondo reale, non sarà in corsi di scrittura come MyFileAccessor per accedere ai file. Invece, userete le classi fornite dal sistema come System.IO.FileStream, che sono già state progettate per eseguire i controlli di sicurezza appropriati per voi. Spesso sono fatti nel costruttore con tutte le implicazioni sulla sicurezza e sulle prestazioni che ho discusso in precedenza.

Answer 3

All'interno delle API java.io, è possibile assicurarsi che i controlli siano effettuati. Se si desidera controllare l'accesso (ignorando un arresto anomalo prima che si verifichi), è necessario eseguire i controlli appropriati PRIMA dei controlli interni effettuati dalle chiamate API.

Il codice Java viene eseguito spesso su computer controllati, ma spesso viene eseguito anche su computer non controllati. Pensa alle applet Java. Dovrebbero chiedere il permesso di accedere al file system in quanto all'autore del programma non dovrebbe essere consentito l'accesso non controllato al file system di tutti gli altri.

Se è necessario impedire a un gruppo di persone di fare qualcosa di malevolo, è necessario impedire a tutti di fare qualcosa di malevolo perché la sicurezza sia reale. Altrimenti, i malvagi diranno semplicemente che fanno parte del gruppo non controllato di fiducia.

L'eseguibile della riga di comando Java viene eseguito per impostazione predefinita con autorizzazioni che consentono di toccare il proprio file system. L'ipotesi è che se avvii il programma localmente, potresti aver incasinato le porzioni del tuo file system a cui avevi accesso in ogni caso. Le applet vengono avviate con tutte queste autorizzazioni predefinite rimosse. In questo modo la persona che naviga nella pagina web in cui risiede l'applet deve concedere manualmente le autorizzazioni per un programma remoto (applet) a toccare il proprio file system.

Che si vede questo è la prova che non c'è una porta sul retro speciale che aggira la sicurezza per alcuni utenti (o in alcune condizioni).