Parte prima

Il problema

Quale attento amministratore di sistema accetterebbe mai di installare un qualsiasi .EXE su un server pur provenendo dall'amico fidato? Nessuno, e spero per tutti voi che seguiate questa ferrea politica.L'astinenza però non si può protrarre a lungo e prima o poi ci verrà ordinato dal vertice aziendale di aprire le porte ad un applicativo che sfugge al nostro controllo. Il problema riguarda anche i client e i rischi vanno dai soliti virus/worm ad apparentemente innocui Activex. Gli utenti hanno molto potere perché risiedono all'interno del dominio e condividono documenti di diverso genere. I client sono più difficili da controllare dei server perché gli utenti possono aggirare gli ostacoli delle policy con un a certa facilità, a volte con candida ignoranza, altre volte con consapevole malizia.Non è poi da sottovalutare l'eterna lotta fra utenti ed amministratori per il controllo dei client. C'è chi adotta politiche restrittive assicurandosi così una certa tranquillità nell'amministrazione e la propria fotografia sul tabellone delle freccette; c'è chi invece è più permissivo rischiando quotidiane perdite dati, e passando le notti di recovery con le 'torte della nonna' degli utenti con cui è stato benevolo.

Non meno infida è la vulnerabilità delle applicazioni. Poniamo di installare un servizio per gli agenti di vendita, per quanta fiducia riponiamo nello sviluppatore che lo ha realizzato, esiste comunque la possibilità che un pirata informatico usi alcune funzionalità di questo servizio, ad esempio per scopi distruttivi.Io mi trovo in una situazione un po' imbarazzante perché sono uno sviluppatore e quindi rientro in quella categoria di persone che creano lo scompiglio tra gli amministratori di sistema. In diverse occasioni però mi trovo dall'altra parte della barricata a risolvere insieme agli amministratori grottesche situazioni create da maldestri sviluppatori. Le metodologie classiche che uso anche io in questi casi, servono solo ad arginare il problema.

Il certificato digitale è invece il sistema più utilizzato sui client, di solito per Activex, alcuni dei quali indispensabili alla navigazione in Internet. Un certificato però garantisce solo due cose: l'identità dell'autore e che il codice, dopo essere stato firmato digitalmente, non sia più stato modificato da nessuno.
Questo significa che se il codice provoca dei problemi, sapete chi li ha provocati ma non avete ovviamente alcuna possibilità di evitare che questi accadano. In pratica conoscete l'indirizzo del colpevole, ma il danno è ormai fatto e probabilmente quando andrete a trovarlo, vedrete appeso alla sua porta un cartello con scritto "torno subito". La debolezza del certificato digitale è ben nota, tanto da essere sfruttata in modo molto subdolo dagli autori di "Dialer" che in molti casi diffondono panico e persino truffe di vario genere non solo in Italia.

L'approccio del Framework.NET

Il Framework.NET è una tecnologia che ha stravolto il mondo dello sviluppo in Windows ma, quasi paradossalmente, i principali benefici sono soprattutto a vantaggio degli amministratori; parlo di sicurezza, stabilità ed integrità dei sistemi.
Il codice managed, cioè sotto il controllo del Framework.NET, in contrasto con il tradizionale codice unmanaged o nativo, è verificabile nel senso che è possibile sapere in anticipo quale operazione stia per effettuare l'applicazione e conseguentemente se permettere l'esecuzione o negarla a priori. Questa tecnologia è chiamata code access security.
Appare chiaro che sia necessario trattare in modo diverso l'applicazione installata localmente da quella presente in una pagina web. La soluzione si chiama evidence ed entra in gioco quando il sistema deve eseguire il codice di un assembly (file nel quale si trova il codice managed).
Quando viene richiesta l'esecuzione di un assembly, il Framework.NET determina la sua evidence grazie ad una o più informazioni:

• cartella da cui viene lanciato;

• sito o URL da cui viene scaricato;

• zona in cui si trova (Internet, Intranet o local computer);

• strong name (una chiave univoca impostata dallo sviluppatore);

• hash (identificativo che cambia a seconda del contenuto dell'assembly);

• firma digitale Authenticode (come quella usata per gli Activex).

In sostanza questo meccanismo fa si che siano applicate policy diverse allo stesso assembly solo per il fatto che l'evidence è differente. Ad esempio, grazie a questo sistema, un assembly eseguito da una cartella di rete sarà soggetto ad una policy più restrittiva rispetto ad uno lanciato dal disco locale. Oppure è possibile attribuire una policy meno restrittiva agli assembly che sono stati contrassegnati da una certo produttore software.
L'evidence viene immediatamente identificata al momento in cui l'assembly è caricato in memoria. Da questa informazione il Framework.NET estrapola la relativa policy di sicurezza che può essere quella di default o quella aggiunta/modificata dall'amministratore di sistema.
Ogni volta che il codice avrà la necessità di accedere ad una risorsa o di eseguire un'operazione che potrebbe avere implicazioni di sicurezza, il Framework.NET provvederà ad assicurarsi che l'operazione rispetti la policy associata. In caso contrario verrà lanciata un'eccezione che di fatto consiste nell'interrompere l'esecuzione del codice e/o presentare all'utente una dialog di avviso.

Operazioni a rischio

Ecco che grazie al Framework.NET l'amministratore si trova immediatamente nella condizione di poter decidere se un applicativo può o meno compiere accesso a determinate risorse. Perciò ogni volta che un assembly tenta di accedere a risorse potenzialmente a rischio, viene sottoposto ad una verifica dei permessi imposti nelle policy.
Il permesso più importante è quello di eseguire codice nativo (COM o API Win32). Il codice nativo per sua natura non è verificabile perciò lasciarlo abilitato significa esporsi ai rischi di cui si è parlato all'inizio.
Fra i permessi di accesso che il Framework.NET rende controllabili, vi sono Active Directory, database, file system, stampanti, registry, event log, socket (comunicazioni in rete), protocollo http, interazione con l'utente, ed altro ancora.
Per esempio, gli assembly eseguiti da una cartella condivisa in rete potranno accedere ai file presenti su quella cartella ma non al disco locale.

Analogamente il codice scaricato ed avviato da Internet potrà usare solo la dialog di apertura file (ma non quella di salvataggio), non avrà alcun diritto di modifica sulla security, disporrà di un proprio clipboard privato, potrà collegarsi via http solo al sito da cui è stato prelevato, potrà stampare solo dopo l'approvazione dell'utente e non potrà scrivere file se non in dieci megabyte di Isolated Storage, una porzione di disco con cui gli utenti non possono interagire.
La struttura del Framework.NET è modellabile e, qualora ve ne fosse la necessità, lo sviluppatore potrebbe creare nuovi permessi in aggiunta a quelli predefiniti che rispondono più puntualmente alle risorse che l'azienda deve difendere.
I permessi del Framework.NET sono aggregabili in diverse configurazioni a seconda della policy sul quale l'amministratore vuole agire:

• Enterprise (policy globali);

• Machine (policy del PC locale);

• User (policy relative alle credenziali associate all'applicazione);

• Application Domain (policy dell'ambiente che ospita l'assembly).

Le quattro policy citate sono preconfigurate in modo ottimale durante l'installazione del Framework.NET ma possono essere modificate e/o arricchite dall'amministratore con gli strumenti che verranno esaminati nella seconda parte dell'articolo.

Quando un assembly vuole accedere ad una risorsa, il Framework.NET estrapola la relativa permission da ciascuna delle quattro policy ed esegue la loro intersezione. Di conseguenza l'assembly avrà il permesso di accedere alla risorsa solo se questo è concesso in tutti i livelli Enterprise, Machine, User e Application Domain.

Il rich client viene dal web

Oggi la maggior parte di aziende lavorano con i rich client. Il problema viene dal desiderio di portarli in un contesto Intranet o Internet, desiderio giustificato per diversi motivi fra cui l'assenza di deploy e la maggiore fruibilità dell'applicazione.
Se però il codice non è managed, si ricade nei problemi di affidabilità del codice e dei certificati digitali.
Sulla strada del web si trovano i browser che però offrono un'interattività ed una fruibilità dell'informazione decisamente più bassa. Il problema del browser risiede nelle due sue imprescindibili tecnologie: html ed http.
I rich client sono la soluzione, applicazioni che vengono scaricate trasparentemente dal browser, avviate sul client senza la necessità di certificati digitali e con un rigoroso controllo sul codice eseguito.
Non appena il codice dovesse tentare di accedere a risorse negate dalle policy stabilite dall'amministratore (o quelle di default), il programma verrebbe terminato.
Alla PDC di Ottobre 2003 abbiamo assistito ad un'eccezionale demo di Amazon che ha presentato un rich client sviluppato per Longhorn, la prossima versione di Windows. Solo una foto come quella che ho scattato durante la presentazione può dare un idea di come sarà il carrello di Amazon all'uscita di Longhorn.

Applicabilità reale

Quali sono le limitazioni della code access security? In questo momento il Framework.NET 1.1 offre 2882 classi in 136 namespace, numeri che non possono esprimere così chiaramente la montagna di servizi agli sviluppatori. Nonostante ciò spesso è necessario ricorrere ancora a codice unmanaged, che sfugge cioè dal controllo del Framework.NET e che di conseguenza le policy tipicamente negano. Gli sviluppatori hanno bisogno di codice unmanaged quando devono usare i servizi di COM, COM+ e le Win32 API sulle più svariate tecnologie come ad esempio l'accesso alla porta seriale.

Il futuro è già tracciato e già con la prossima versione di Visual Studio Whidbey e del Framework.NET 2.0, arriveranno molte nuove classi e le relative permission che minimizzeranno questo problema. In particolare dovrebbe esordire la prima versione di Indigo, il futuro sistema di comunicazioni fra applicativi che si propone di inglobare gli enterprise services (COM, COM+ e DCOM) ed evolvere notevolmente gli attuali Web Services e Remoting.
Questo primo passo conduce verso Longhorn, la prossima versione di Windows, che vedrà l'esordio di WinFX, candidato alla sostituzione delle Win32. WinFX offrirà tutti i servizi delle Win32 e molti altri nuovi, interamente costituiti da codice managed e perciò sotto il completo controllo del Framework.NET e delle sue policy.

In un sistema operativo dove i servizi sono selettivamente classificati per rischio e altrettanto selettivamente controllabili, l'amministratore potrà redigere delle policy mirate ai giusti requisiti di sicurezza e che allo stesso tempo vadano incontro alle esigenze degli utenti, annullando di fatto i problemi di sicurezza legati alla presenza di codice nativo. Questa transizione sembra ancora troppo lontana?
Non sono di questo avviso perché stiamo per vivere un nuovo cambio generazionale dell'hardware passando dai 32bit ai 64bit. Credo che Microsoft approfitterà di questo indispensabile salto generazionale per introdurre contemporaneamente le nuove tecnologie che vedranno la luce con Longhorn.
I numerosissimi servizi realizzati con COM/COM+ e le DLL scritte in C++ basate sulle Win32 API, anche se potranno continuare a funzionare senza alcuna modifica, dovranno comunque essere aggiornate se vorranno usufruire dei vantaggi delle piattaforme a 64bit. Quale migliore occasione per migrarle al mondo managed di WinFX?

Nella seconda parte dell'articolo verranno mostrati nel dettaglio gli strumenti che permettono la configurazione e la gestione della code access security.

Inizio pagina