Technology Experience

Contenuti gestiti da Igor Damiani
posts - 949, comments - 2741, trackbacks - 15120

My Links

News

  • Questo blog si propone di raccogliere riflessioni, teoriche e pratiche, su tutto quello che riguarda il world-computing che mi sta attorno: programmazione in .NET, software attuale e futuro, notizie provenienti dal web, tecnologia in generale, open-source.

    L'idea è quella di lasciare una sorta di patrimonio personale, una raccolta di idee che un giorno potrebbe farmi sorridere, al pensiero di dov'ero e cosa stavo facendo.

    10/05/2005,
    Milano

Archives

Post Categories

Generale

[MCAD.33] Un ultimo sguardo a caspol.exe e alle policy di sicurezza

Dopo aver parlato, poco tempo fa, di caspol.exe e di come .NET implementa alcune logiche di sicurezza, voglio descrivere un attimo una cosa che mi ha fatto perdere parecchio tempo per evidente ignoranza della questione. Ovvero (può sembrare banale), come revocare permessi ad un'applicazione.

Lasciatemi descrivere lo scenario in cui voglio ambientare la mia spiegazione. Supponiamo di prendere la nostra applicazione ReadRegistry che abbiamo creato a suo tempo e di farla girare da una qualsiasi directory del nostro PC. Abbiamo detto che trattandosi di un EXE eseguito da un disco locale, questo assembly gira nella My_Computer_Zone. In questo caso, quindi, l'assembly gira come FullTrust. Di questo abbiamo già parlato: se vi siete persi qualcosa, andate a leggere i miei post precedenti.

Tutto questo è molto bello, però io mi sono posto la seguente domanda:
se io volessi revocare i permessi alla mia applicazione, cosa devo fare?

Ci tengo a rispondere a questa domanda, perchè io non la trovo così banale, soprattutto perchè fino ad adesso ho omesso (più o meno volutamente) un concetto importante. Arriviamo al dunque: aprite il tool .NET Framework 1.1 Configuration e date un'occhiata ai 5 Code Group built-in. Come abbiamo fatto noi precedentemente, possiamo ovviamente definire code groups aggiuntivi, personalizzati, custom, insomma. Ogni code group può appartenere ad uno qualsiasi dei 5 code group predefiniti: nel tool appariranno come indentati rispetto al code group corrispondente. Esattamente come abbiamo fatto noi l'altra volta: ovvero, per dare dei permessi speciali al nostro assembly, abbiamo dovuto creare un code group tutto nostro dentro la LocalIntranet_Zone.

A questo gruppo, che avevamo chiamato "ReadRegistry", abbiamo assegnato i permessi di FullTrust.
Non è propriamente esatto.
In realtà, i permessi assegnati ad un group equivalgono alla "somma" dei permessi di tutti i code group incontrati durante l'esplorazione dell'albero: scusatemi, ma non so spiegarmi meglio! Adesso facciamo la prova del 9 (ma è vero che la prova del 9 a volte può fallire?) e sarà tutto più chiaro.

Revochiamo un permesso, ma l'assembly gira senza problemi. PERCHE'?
Quello che vogliamo fare è togliere i permessi di lettura dal registry alla nostra applicazione, anche se quest'ultima gira dal nostro disco C: (quindi, My_Computer_Zone). Se avete ancora aperto .NET Framework 1.1 Configuration, è il momento di agire.

Andate nel nodo Permission Sets, duplicate il set chiamato FullTrust e rinominatelo come  FullTrust_NoRegistry. Cliccate con il pulsante destro, selezionate Change Permissions, selezionate la voce Registry, cliccate sul pulsante Add. Non date alcun permesso: il nostro assembly non deve assolutamente avere alcun permesso sul registry. Cliccate semplicemente su Ok per chiudere la finestra di dialogo. Fine prima parte.
Adesso create un nuovo code group dentro il code group My_Computer_Zone, chiamatelo NoRegistry. La membership condition sarà quella di avere lo strong name del nostro assembly. Il permission sets sarà quello appena creato, ovvero FullTrust_NoRegistry. Fine seconda ed ultima parte del test.

Cosa ci aspettiamo? Anche se l'applicativo gira da C: continua a funzionare regolarmente, senza sollevare alcun exception. Perchè?  Il motivo sta tutto nella frase criptica che ho detto prima: i permessi associati al nostro assembly sono FullTrust + FullTrust_NoRegistry: il primo è dato dal nodo My_Computer_Zone, il secondo dal nodo NoRegistry. Ecco spiegato il motivo per cui l'assembly non dà alcun messaggio di errore. Ovvero...
Ogni code group eredita anche i permessi dei code groups padri.

Revochiamo veramente il permesso
Tornate nel tool .NET Framework 1.1 Configuration, andate nelle properties del nostro code group NoRegistry. Nella finestra di dialogo ci sono due check-box di cui non abbiamo mai parlato.

- This policy level will only have the permissions from the permission set associated with this code group
Se è attivo, blocchiamo questo processo di "ereditarietà" che ho appena descritto. Se un assembly appartiene a questo code group, all'assembly vengono assegnati i permessi specificati dal code group, senza considerare i padri. Equivale all'opzione -exclusive del comando caspol.exe.

- Policy level below this level will not be evaluated
Se è attivo e se un assembly appartiene a questo code group, all'assembly vengono assegnati i relativi permessi, evitando di valutare i code group figli. Equivale all'opzione -levelfinal del comando caspol.exe.

Per ottenere veramente quello che vogliamo, quindi, ci basta abilitare il primo checkbox. Proviamo ad eseguire ReadRegistry.exe. Questa volta all'assembly viene assegnato il permission sets denominato FullTrust_NoRegistry : ovvero, tutti i permessi possibili ed immaginabili, tranne l'accesso al registry.

E questa volta, finalmente, abbiamo l'exception che ci aspettiamo!!!

Conclusioni
Scrivere un intero articolo per ottenere un'exception non è granchè, vero?
Abbiamo dimostrato però che anche se un'applicazione gira dalla My_Computer_Zone, possiamo comunque limitare le sue possibilità, assegnando e revocando permessi come meglio crediamo. Notare che caspol.exe e il tool relativo contengono tutta una serie di permessi piuttosto interessanti: rete, accesso ad Internet, UI, Reflection, possibilità di stampare, etc. Tutto questo (anche se credo che poi pochi lo faranno realmente) per creare permission sets piuttosto "mirati" per le nostre applicazioni Windows Forms.

powered by IMHO 1.2

Print | posted on Monday, September 19, 2005 11:17 AM | Filed Under [ MCAD ]

Feedback

Gravatar

# Re: [MCAD.33] Un ultimo sguardo a caspol.exe e alle policy di sicurezza

Proprio ieri ho avuto a che fare con un problema simile.
Grazie, mi hai chiarito le idee :)
9/19/2005 12:22 PM | Roberto Marcellino
Gravatar

# re: [MCAD.33] Un ultimo sguardo a caspol.exe e alle policy di sicurezza

Illuminante, per capire come funziona la security in .net è questo articolo di Don Box:
http://msdn.microsoft.com/msdnmag/issues/02/09/SecurityinNET/default.aspx
E' vecchiotto ed un po tosto ma tutto sommato scorrevole.

CIao
9/19/2005 12:51 PM | Mighell
Gravatar

# re: [70-320] Caspol.exe ed Al.exe

3/4/2006 9:08 AM | rosalba
Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET