What does a security pro need to know about Code Access Security (CAS)?
Onestamente, direi non molto; finché non hai bisogno di saperlo.
Why have these security features been removed from .NET 4.0?
Perché la sicurezza si stava complicando, portando a domande come questa. Era anche una soluzione incompleta poiché era solo applicazioni .NET con questa funzionalità. Prendiamo ad esempio che un'esecuzione eseguibile .NET su una condivisione di rete verrebbe eseguita in media fiducia. Il trust medio impedirebbe l'accesso a molte funzionalità, ma è stato fatto in nome della sicurezza. Tuttavia, ha avuto i suoi difetti.
-
I file EXE nativi non si comportano in questo modo. Se qualcuno stava per scrivere un eseguibile dannoso, probabilmente non opterebbe per farlo. NET. Un eseguibile nativo non si comporta diversamente quando viene eseguito su una condivisione di rete. Tuttavia, ha fermato un mezzo molto "economico e semplice" di applicazioni di rete che sono utili.
-
L'amministrazione era decisamente confusa. Tra gruppi di codici, zone, Nomi forti, Identità applicazione e set di autorizzazioni, era necessario conoscere molto per qualcosa che non offriva sufficiente sicurezza.
-
Il concetto nacque prima di UAC e AppLocker, dove le persone che erano Amministratori avevano sempre permessi amministrativi. UAC va molto più in profondità di un'applicazione .NET, è a livello di sistema operativo.
How do we secure .NET 4.0 apps?
Il tuo vero obiettivo non è "proteggere app .NET" ma "proteggere tutte le app". AppLocker o SRP sono più efficaci perché si applicano a qualsiasi applicazione. .NET, Java, nativo, ecc.
Inoltre, limitando il permesso dell'utente, non l'applicazione. La creazione di un'applicazione politica per applicazione richiede un grande sforzo e ancora più difficile quando è necessario iniziare a creare eccezioni per determinati utenti.
Questo non vuol dire che .NET 4.0 non abbia affatto un modello di sicurezza. La sostituzione di .NET 4.0 è la trasparenza di sicurezza e le applicazioni "ospitate" come Silverlight, ClickOnce, ecc hanno ancora dei set di autorizzazioni simili a CAS applicati.
La trasparenza della sicurezza si basa maggiormente su un set di sovvenzioni fornito da una sandbox. Prendi ad esempio Silverlight. Silverlight fornirà una serie di sovvenzioni diversa a seconda che l'applicazione sia in esecuzione nel browser (Medio attendibile) o fuori dal browser, che può avere una piena affidabilità. L'esaurimento del browser richiede l'approvazione di un utente per farlo, e anche in questo caso è limitato da cose a livello di sistema operativo.
Spetta allo sviluppatore sapere quali set di permessi ha a seconda di quale sandbox la sua applicazione è in esecuzione. In effetti, le applicazioni .NET 4 ottengono la stessa "sandbox" delle applicazioni native. Silverlight, ClickOnce e così via ottengono la propria sandbox con maggiori restrizioni.
