in

DotNetSide

Dot Net South Italy Developers User Group

Articoli

Articoli pubblicati dagli iscritti a .netSide

.Net Framework 4.0 - Il nuovo modello di security

Autore: Andrea Colaci

Il nuovo modello di security del .net Framework 4, eredita molto dall’esperienza accumulata nello sviluppo del modello di sicurezza “trasparente” di Silverlight. Le novità di questa revisione trattate da questo articolo sono:
-    CAS policy (ora disabilitata di default)
-    Miglioramento delle API utilizzate per l’hosting ed il sandboxing di codice partial-trust
-    Level 2 Security Transparency

La disabilitazione delle policy della Code Access Security, favorisce una più semplice gestione dell’hosting di codice partially trusted (sandboxing) e dell’esposizione  flessibile, ed allo stesso tempo sicura, di servizi e librerie.

Le caratteristiche della CAS, rendono difficile la configurazione delle policy, con il risultato che il funzionamento ottenuto, risulta spesso differente da quello desiderato.  Inoltre la CAS non ha subito particolari evoluzioni nel corso delle diverse versioni del .Net Framework, almeno fino alla versione 4.0, versione in cui il modello di sicurezza ha invece subito una notevole revisione.
Nel .Net Framework 4.0, la CAS policy è disabilitata di default, ma può essere riattivata per migrare codice basato su framework precedenti, garantendone la retro-compatibilità semplicemente impostando nell’app.config:

image

In assenza di questo switch, il codice migrato che utilizza esplicitamente o implicitamente la CAS genererà la seguente NotSupportedException:

“This method implicitly uses CAS policy, which has been obsoleted by the .NET Framework. In

order to enable CAS policy for compatibility reasons, please use the NetFx40_LegacySecurityPolicy configuration switch”

 

Code Access Security

Parlando di codice managed, la CAS opera indipendentemente dalla sicurezza del sistema operativo, il suo scopo è di assegnare un opportuno permission set ad codice così detto “untrusted”, in modo da impedirne eventuali azioni non autorizzate. imageIl codice managed, nello specifico ogni assembly non Full-Trust, viene processato dalla CAS e ricondotto ad uno specifico CodeGroup (es. Internet_Zone) sulla base di una o più Evidence fornite dal .Net Framework runtime, come ad esempio la cartella in cui l’assembly risiede, il suo strong name, il publisher etc.

Una volta identificato il CodeGroup di appartenenza, la CAS assegna all’assembly il permission set previsto per il CodeGroup a cui viene associato, accordando un insieme di permission come ad esempio:  L’accesso al registry, la stampa, l’accesso ai siti, la possibilità di controllare un Windows service etc.

La configurazione della CAS policy si ottiene in tre modi:
-    mediante lo strumento grafico “.Net Framework Configuration Tool”
-    tramite riga di comando, utilizzando Caspol.exe
-    in maniera programmatica utilizzando la classe SecurityManager

Le API che utilizzano esplicitamente la CAS, in particolare la classe SecurityManager, sono state deprecate a partire dalla versione 4.0 del framework, mentre quelle che utilizzano implicitamente la CAS, ad esempio per creare un appDomain “sandboxed”, sono state sottoposte a revisione in quanto consentivano la creazione di appDomain eterogenei sotto il profilo dei permission set.

La configurazione della CAS, può avvenire a tre livelli differenti denominati Security Policy ovvero: Enterprise, Machine e User. Ciò consente una maggiore granularità, ma anche una maggiore complessità di gestione, in quanto eventuali “conflitti” sono risolti partendo nell’ordine dalla policy Enterprise quindi, Machine ed infine User, imageapplicando alla il livello più restrittivo, esito dell’intersezione delle permission appartenenti alle diverse security policy. Non vi è sempre certezza, almeno dal punto di vista dello sviluppatore, di quale sarà l’effettivo permission set calcolato.

Con il nuovo modello di security, un eseguibile managed viene trattato come un eseguibile nativo, demandando al codice di hosting la creazione di una sandbox e la gestione dei relativi permessi.

 

Sandboxing

Una delle più importanti possibili applicazioni della CAS è il “sandboxing”, ovvero la tecnica di creazione di un application domain con limitati privilegi, in cui caricare ed eseguire uno o più assembly, attenuando così eventuali rischi derivanti dall’esecuzione di codice non sicuro o di provenienza sconosciuta, ma anche nel caso di un’applicazione estendibile, mediante plug-in che possono essere scritti da terze parti.
Con i framework precedenti, la CAS veniva chiamata in causa per calcolare il permission set di un assembly, prima che questo venisse eseguito.  Con il nuovo modello di security un assembly viene eseguito come un qualsiasi altro eseguibile nativo (unmanaged), quindi potenzialmente in Full Trust (pur essendo sempre soggetto alle policy di sicurezza del sistema operativo ad es. il controllo della provenienza, del publisher e la role-based security). Questo consente di aggirare completamente tutte le CAS Policy impostate nei diversi livelli (Enterprise, Machine ed User), demandando al codice di hosting la creazione di una sandbox e l’assegnazione programmatica dei permessi. Lo sviluppatore è quindi in condizioni di caricare un assembly (ed quindi istanziare tipi ivi contenuti) in un appDomain il cui permission set è personalizzabile, certo e non influenzabile dalla configurazione della CAS.


Il Sandboxing con persmission set personalizzato, era comunque ottenibile sin dalla versione 2.0 del .Net Framework. Le API sono state migliorate, in quanto permettevano la creazione di appDomain eterogenei, con all’interno assembly con permission set differenti. Con le nuove e rivisitate API, questa possibilità è stata deprecata imponendo per in ogni appDomain l’esistenza di un solo permission set, che non viene calcolato in automatico dalla CAS. Di seguito un esempio di creazione di una sandbox secondo il metodo obsoleto:

image

Mentre con la CAS attiva, il permission set è calcolato sulla base di Evidence, quindi ricondotto ad un CodeGroup ed infine al relativo permission set (sempre ammesso che non vi siano intersezioni con altre Security Policy), il permission set ora viene direttamente passato come parametro, in fase di creazione della sandbox.

image

Il metodo ufficialmente supportato per creare un appDomain “sandboxed” è AppDomain.CreateDomain(), di seguito un esempio:

image

Immaginiamo ora di aver sviluppato un componente aggiuntivo per un applicativo, diciamo un plug-in, e di volerlo caricare in un appDomain sandboxed, in modo che non possa eseguire operazioni potenzialmente dannose. Poniamo ora che il plug-in utilizzi una libreria full-trust presente nella GAC, che effettua una scrittura su file system. Come è possibile consentire al plug-in l’utilizzo di tale libreria? Occorre innanzitutto osservare, che è necessaria una certa coesione tra lo sviluppo del codice di Hosting e quello della libreria fruibile dal codice partial-trust. Infatti nell’assemblyInfo della libreria è necessario impostare l’attributo AllowPartiallyTrustedCallers (APTCA), che tramite il parametro PartialTrustVisibilityLevel consente di rendere visibile la libreria dal codice partial trust (VisibleToAllHosts), oppure richiedere l’inclusione esplicita della stessa in fase di creazione della sandbox (NotVisibleByDefault):

image 

Nel secondo caso, quando si crea la sandbox, occorrerà utilizzare la proprietà PartialTrustVisibleAssemblies  (utilizzata anche nell’esempio di creazione della sandbox, vedi sopra), che specifica quali assembly saranno visibili dal codice partial trust:  image

L’attributo appena descritto, fa parte del nuovo modello di sicurezza del .Net Framework 4.0 denominato Level 2 Security Transparency. Sebbene i framework precedenti si basino sul modello precedente (Level 1), è tuttora possibile migrare il codice esistente mantenendo la retro-compatibilità, semplicemente decorando l’assembly con l’attributo: 

image

 

Level 2 Security Transparency

Il nuovo meccanismo di sicurezza,introdotto dalle versione 4.0 del framework e denominato “Level 2 Security Transparency”, classifica il codice in termini di sicurezza in tre tipologie principali: Transparent, SafeCritical e Critical. Questo consente di separare, in modo esplicito, il codice partial trus dal codice che effettua operazioni con privilegi elevati.
Già dalla versione 2.0 del .Net Framework, è possibile proteggere dall’esecuzione di metodi contenenti codice potenzialmente pericoloso da parte di assembly partial trust, di seguito un esempio di utilizzo di un SecurityPermission Attribute:

image

Questo codice, allineato al precedente Level 1 RuleSet, richiede che il chiamante diretto sia in possesso della permission dichiarata nell’attributo. Con il nuovo modello di security, in scenari partial trust e sandboxed, il codice è considerato Transparent per default, non ha quindi facoltà di eseguire direttamente operazioni critiche. imageQuesto infatti può richiamare altro codice Transparent oppure SafeCritical, ma non può  richiamare direttamente codice decorato come Critical. Questo modello è illustrato nel grafico a fianco, in cui le frecce verdi rappresentano le chiamate consentite e le rosse quelle non consentite.
Gli attributi appena descrtitti, insieme all’attributo AllowPartiallyTrustedCallers (descritto nel paragrafo precedente), rappresentano i pilastri del Level 2 Security Transparency, un modello di sicurezza pensato inizialmente per Silverlight, ma ora esteso anche nella versione 4.0 del CLR.
Ritornando all’esempio della sandbox nel paragrafo precedente, il plug-in è considerato automaticamente come Transparent perchè caricato nella sandbox, questo potrà quindi richiamare i soli metodi della libreria decorati come Trasparent o SafeCritical, se infatti un codice Transparent, tenta ad esempio di richiamare codice nativo tramite p/invoke, di elevare i privilegi oppure tenta di richiamare direttamente un metodo decorato come Critical, il runtime solleverà una MethodAccessException.
Di seguito un esempio di metodi decorati con gli attributi della Level 2 Security Transparency:

image

 

Conclusioni

Il .Net Framework 4.0, attualmente in Beta 2, contiene una notevole revisione del precendente modello di security denominato Level 1. La CAS policy è disabilitata per default, sbilanciando verso il sistema operativo la gestione della sicurezza anche per gli eseguibili managed, così come avviene per quelli nativi.
L’eventuale assegnazione dei permessi, per il codice managed partial trust, è demandata totalmente al codice managed che di hosting, che ha l’onere di creare una sandbox ed assegnare il permission set opportuno, semplificando notevolmente questa operazione.
Tuttavia le novità, sono state introdotte in maniera quasi indolore, on quanto è possibile migrare il codice esistente che utilizza API deprecate, riabilitando le features della CAS agendo sia sul file di configurazione che a livello di attributi dell’assembly.

 

L'autore

Andrea Colaci è un libero professionista e collabora con ObjectWay S.p.a. Si occupa di design e sviluppo software dal 1999, ha maturato esperienze in diversi scenari quali FF.AA., Telecomunicazioni, Servizi post-vendita, Industria ed Istituti Bancari.
E' certificato Microsoft MCAD, MCPD su ASP.NET 3.5 e MCTS su WPF.
Segue il progetto Microsoft Velocity fin dalla prima CTP, ha pubblicato alcuni articoli e diversi post tecnici al riguardo e frequenta attivamente il forum ufficiale.
Attualmente lavora come consulente senior, su tecnologie Microsoft, in un gruppo bancario.

Powered by Community Server (Commercial Edition), by Telligent Systems