Ripassando per l'esame ho provato a fare una piccola ricerca su Google, inserisco la parola CAS e mi è toccato spulciare fino a pagina 5 per iniziare a vedere qualche cosa d'attinente per il resto club alpini, società di costruzioni etc.
ovviamente totalmente differente il risultato se inserisco Code Access Security.
L'argomento è talmente interessante che merita un post e dunque.. vediamo cosa posso aggiungere dopo le slide di Santini e Rialdi che per fortuna sono ancora disponibili per il download.
Prima d'attentrarci nei meandri dell'argomento in un mio vecchio post indicavo un articolo su msdn che spiegava il perchè è saggio utilizzare i privilegi minimi.
Quando vogliamo restringere la pericolisità del "danno" di un'applicazione i principali strumenti sono l'utilizzo sapiente della RBS e la CAS. Se per il codice unmanaged la scelta obbligata è la prima per il codice manged utilizzando sapientemente la CAS è possibile granulare correttamente cosa il nostro codice può fare ma anche cosa l'utente può fargli fare.
Il meccanismo utilizzato è quello dell"evidence" ossia un set d'informazioni che identificano con tutta una serie d'informazioni un assembly. Le informazioni spaziano dalla directory nella quale esso si trova (application directory), strong name, all'hash queste ed altre informazioni sono membri della System.Security.Policy. Comunque le evidence sono di due tipi le host (es. origine:directory, Url o sito) e le assembly, queste ultime sono del tipo customer user o definite dal developer. Sulle slide che ho ricordato prima trovate riferimenti alla code group ed ai permessi.
Ci potremmo chiedere se la CAS sostituisce l'operating system securitity? La risposta è NO essa si pone come uno strato su di essa, dunque è un complemento e non un suo sostituto.
Ok, tutto questo è bello ma come faccio a sapere se un assembly è attendibile e come si configurano i permessi? Sempre utilizzando .Net Configuration tool si utilizza il nodo CRITERI DI PROTEZIONE RUNTIME
-
Valutare l'assembly: facciamo clic col tasto destro su di esso e scegliamo Valuta Assembly seguendo passo passo il wizard vedremo i permessi che esso ha;
-
Nuovi permessi ed assegnazione: E per aggiungerne? Prima cosa dobbiamo decidere a che livello vogliamo impostarli enterprise, computer, user (il primo si applica a tutta la rete, il secondo a tutte le applicazioni sul PC, il secondo all'utente singolo) Es. presi da mania di grandezza supponiamo di voler creare un nuovo set di permessi che porta il nostro nome per tutta la rete, quindi scegliamo il nodo Enterprise e poi Set di Autorizzazioni, seguendo passo passo la procedura impostiamo prima il nome del set in questo caso "Autorizzazioni di Rosalba" e poi che tipo di autorizzazione dobbiamo dare (dns, internet, contatore di prestazioni, stampa in corso etc etc) e per ciascuna le proprietà. Al termine vedremo sotto le altre (Full Trust, Execution etc) anche quella che abbiamo appena creato. A questo punto come l'assegniamo? Sempre nel nodo Enterprise scegliamo Gruppi di Codice, All Code dunque tasto destro e poi Nuovo, dunque creiamo un nuovo gruppo di codice e specifichiamo il tipo di condizione per il gruppo di codice (le evidence dette prima ed anche un livello personalizzato mediante XML da scrivere o da importare) dunque gli assegniamo il set di autorizzazioni dunque "Autorizzazioni di Rosalba" e poi fine. Ora mi ridimensiono pure io!
Questa è la strada facile se vogliamo/dobbiamo utilizzare caspol.exe i parametri sono effettivamente un pò tanti da postare dunque vi rimando a questo in italiano di MSDN
Piccola nota fino ad ora ho utilizzato solo Windows XP PRO, dunque le prove le potete fare tranquillamente anche se non avete Windows Server 2003.
Ma se poi ciò che è previsto dalla CAS non permette alla nostra applicazione? In questo caso ricorriamo alla CAS Assmbly Declarations.
Le ragioni:
-
gli amministratori utilizzando il tool Permview possono analizzare i permessi che l'assembly richiede, dunque grazie ai metadati può risparmiarsi di leggere pagine e pagine della documentazione che accompagna la nostra applicazione
-
le risorse utlizzare saranno solo quelle che la nostra applicazione ha il permesso di utilizzare, e l'amministratore capirà dall'eccezione lanciata che cosa è successo sempre che ci siamo ricordati di utilizzare la SecurityAction.RequestMinimum
-
un attacco alla nostra applicazione non provoca grossi danni essendo essa in una piccola sandbox
-
sappiamo esattamente i permessi che essa richiede poichè ogni volta che dobbiamo aggiungere una doppiamo dichiararla con SecurityAction.RequestOptional altrimenti viene trovata un'eccezione di tipo System.Security.Policy.PolicyException.
Il resto...magari la prossima volta oggi è domenica mi 
un pò di riposo.