Accedendo ad un computer come amministratori chiaramente è possibile effettuare qualsiasi operazione. Di conseguenza quando in un sistema operativo Windows si utilizza un’applicazione non gestita, essa ottiene tutti i privilegi dell’utente che la esegue. In tal caso se accidentalmente l’utente amministratore esegue un file malevolo non ci sono barriere che possano bloccare le sue azioni.
Per evitare questo scenario si dovrebbe accedere al computer con un’utenza che possieda soltanto privilegi minimi. Un concetto molto importante in tale contesto è quello di sicurezza di accesso al codice (CAS - Code Access Security), una modalità operativa che permette di controllare i permessi che ciascuna applicazione deve possedere.
Il CAS è un sistema di sicurezza che permette ad amministratori e sviluppatori di controllare le autorizzazioni delle applicazioni in modo del tutto simile alle autorizzazioni sugli account utente. Tramite tale sistema è possibile, ad esempio, garantire ad un’applicazione i privilegi di lettura e scrittura sul registro di sistema. E’ possibile controllare le autorizzazioni della maggior parte delle risorse del sistema, incluse:
Sfortunatamente il CAS può essere applicato soltanto ad applicazioni basate sul .NET Framework, mentre applicazioni diverse non possono essere gestite e operano senza alcuna restrizione CAS ma soltanto con restrizioni legate ai privilegi dell’utenza utilizzata.
Ogni sistema di sicurezza necessita di un modo per identificare gli utenti e determinare cosa un’utente possa fare e cosa non possa fare e CAS non rappresenta un’eccezione da questo punto di vista. Tuttavia siccome questo sistema di sicurezza identifica ed assegna permessi alle applicazioni invece che agli utenti, esso non può basarsi su nomi utente e password ma sulla cosiddetta evidenza (evidence).
L’evidenza è l’informazione che l’ambiente di esecuzione del .NET Framework fornisce su un assembly. Esempi di tale informazioni sono la cartella o il sito web dal quale un determinato assembly viene gestito o le firme digitali. Esistono due tipi di evidenza: host evidence e assembly evidence. La prima descrive i dati relativi all’identità dell’assembly (ad esempio indirizzo o directory di appartenenza); la seconda fornisce dati come il codice hash o le informazioni crittografate sul nome dell’assembly.
Si definisce permesso la specifica di un controllo di accesso. Per esempio il permesso File Dialog determina se un assembly può presentare o meno ad un determinato utente le finestre di dialogo Open o Save, entrambe o nessuna. All’interno del .NET Framework sono presenti diversi permessi predefiniti ed inoltre è possibile definire permessi personalizzati. Tra quelli predefiniti ci sono:
I permessi vengono raggruppati in insiemi (permission sets). Ad esempio l’insieme di permessi Internet contiene sei permessi: FileDialog, Isolated Storage, File, Security, User Interface, Printing.
Il .NET Framework include sette insiemi di permessi predefiniti:
Un concetto molto importante è quello di code groups. Si tratta di strumenti tramite cui si assegnano agli assembly i rispettivi insiemi di permessi, in modo del tutto simile agli user groups (gruppi utente) che servono a gestire gli account di Windows.
Quando ad esempio un amministratore vuole permettere l’accesso ad una determinata cartella egli crea un gruppo utente, aggiunge gli utenti a tale gruppo ed infine assegna il permesso al gruppo. I code groups funzionano in modo del tutto simile, con la differenza che non si devono aggiungere individualmente i vari assembly al gruppo poichè l’appartenenza ad un determinato gruppo è determinata dall’evidenza (concetto che abbiamo visto in precedenza) che viene specificata come condizione di appartenenza al gruppo. Ad esempio qualsiasi codice che gira su Internet dovrebbe essere membro del code group Internet_Zone.
Dopo aver definito i precedenti concetti possiamo passare a parlare di security policy, ossia raggruppamenti logici di code groups e di insiemi di permessi. Questi strumenti danno agli amministratori una grande flessibilità nella configurazione del CAS a diversi livelli. Come impostazione predefinita esistono quattro livelli di policy: Enterprise, Machine, User e Application Domain.
Il livello Enterprise è il più elevato e permette di gestire le policy dell’intero sistema, il livello Machine permette di gestire le policy relative al codice che viene eseguito su una determinata macchina, il livello User quelle a livello di utente. L’ambiente di esecuzione valuta questi tre livelli separatamente e fornisce ad un assembly il minimo insieme di permessi garantiti da ogni livello.
Il CAS è completamente indipendente dalla sicurezza del sistema operativo e occorre utilizzare lo strumento .NET Framework Configuration per gestire i permessi dei vari assembly. Il CAS lavora al di sopra della sicurezza del sistema operativo e in pratica quando occorre determinare se un assembly possa o meno effettuare una determinata azione vengono valutati entrambi i tipi di sicurezza e viene applicato l’insieme di permessi più restrittivo.
Se ad esempio il CAS consentisse ad un assembly di poter accedere in scrittura ad una determinata cartella ma l’utente che stesse eseguendo l’assembly non avesse tale permesso allora l’assembly non potrebbe scrivere in quella cartella.
Di seguito un’immagine tratta dal sito Microsoft che rende bene l’idea di questi concetti:
Quindi lo strumento .NET Framework Configuration fornisce un’interfaccia grafica per la gestione delle policy di sicurezza e delle applicazioni che usano servizi remoti. Tra le varie operazioni che è possibile effettuare citiamo:
Vediamo come effettuare la prima di queste operazioni. Per prima cosa avviamo lo strumento .NET Framework Configuration e quindi andiamo nella scheda Strumenti di amministrazione, selezionando la voce Microsoft .NET Framework Configuration
Si apre la seguente finestra
In essa dobbiamo cliccare su Configure Code Access Security Policy e poi su Evaluate Assembly. Nella nuova finestra che si apre basta selezionare il percorso dell’assembly che si vuole valutare e cliccare su Next. A questo punto comparirà una finestra con il riepilogo delle informazioni di interesse.
Le altre operazioni si possono effettuare in modo del tutto simile, selezionando le opportune voci. Per approfondire la conoscenza su di esse vi invito, come sempre, a consultare la documentazione ufficiale Microsoft.
mrwebaster.it
Formattazione testo mia.
Per evitare questo scenario si dovrebbe accedere al computer con un’utenza che possieda soltanto privilegi minimi. Un concetto molto importante in tale contesto è quello di sicurezza di accesso al codice (CAS - Code Access Security), una modalità operativa che permette di controllare i permessi che ciascuna applicazione deve possedere.
Il CAS è un sistema di sicurezza che permette ad amministratori e sviluppatori di controllare le autorizzazioni delle applicazioni in modo del tutto simile alle autorizzazioni sugli account utente. Tramite tale sistema è possibile, ad esempio, garantire ad un’applicazione i privilegi di lettura e scrittura sul registro di sistema. E’ possibile controllare le autorizzazioni della maggior parte delle risorse del sistema, incluse:
- File system
- Registro
- Stampanti
- Log degli eventi
Sfortunatamente il CAS può essere applicato soltanto ad applicazioni basate sul .NET Framework, mentre applicazioni diverse non possono essere gestite e operano senza alcuna restrizione CAS ma soltanto con restrizioni legate ai privilegi dell’utenza utilizzata.
Ogni sistema di sicurezza necessita di un modo per identificare gli utenti e determinare cosa un’utente possa fare e cosa non possa fare e CAS non rappresenta un’eccezione da questo punto di vista. Tuttavia siccome questo sistema di sicurezza identifica ed assegna permessi alle applicazioni invece che agli utenti, esso non può basarsi su nomi utente e password ma sulla cosiddetta evidenza (evidence).
L’evidenza è l’informazione che l’ambiente di esecuzione del .NET Framework fornisce su un assembly. Esempi di tale informazioni sono la cartella o il sito web dal quale un determinato assembly viene gestito o le firme digitali. Esistono due tipi di evidenza: host evidence e assembly evidence. La prima descrive i dati relativi all’identità dell’assembly (ad esempio indirizzo o directory di appartenenza); la seconda fornisce dati come il codice hash o le informazioni crittografate sul nome dell’assembly.
Si definisce permesso la specifica di un controllo di accesso. Per esempio il permesso File Dialog determina se un assembly può presentare o meno ad un determinato utente le finestre di dialogo Open o Save, entrambe o nessuna. All’interno del .NET Framework sono presenti diversi permessi predefiniti ed inoltre è possibile definire permessi personalizzati. Tra quelli predefiniti ci sono:
- Variabili d’ambiente – Garantisce l’accesso alle variabili d’ambiente (come Path, Username, Number_Of_Processors). E’ possibile garantire l’accesso a tutte le variabili d’ambiente o specificarne solo alcune
- Directory Services – Garantisce il diritto ad accedere e gestire Active Directory
- Event Log – Garantisce l’accesso al log degli eventi
- File IO – Limita l’accesso a file e cartella. E’ possibile specificare una lista di percorsi a cui un assembly può accedere garantendo privilegi di lettura, scrittura, ecc.
- Printing – Limita i privilegi di stampa
- Reflection – Controlla se un assembly possa o meno accedere ad informazioni di altri assembly
- Registry – Limita l’accesso alle chiavi di registro
- SQL Client – Controlla se un assembly possa accedere o meno a SQL Server
- User Interface – Determina se un assembly possa creare o meno nuove finestre
- Web Access – Determina se un assembly possa accedere a siti web ed eventualmente a quali siti
I permessi vengono raggruppati in insiemi (permission sets). Ad esempio l’insieme di permessi Internet contiene sei permessi: FileDialog, Isolated Storage, File, Security, User Interface, Printing.
Il .NET Framework include sette insiemi di permessi predefiniti:
- Fulltrust – Esenta un assembly dalla verifica dei permessi da parte del CAS
- SkipVerification – Consente ad un assembly di bypassare il controllo dei permessi
- Nothing – Nega l’esecuzione di un determinato assembly
- Internet – Assegna un insieme ristretto di permessi ad un assembly
- Everything – Garantisce ad un assembly tutti i permessi
Un concetto molto importante è quello di code groups. Si tratta di strumenti tramite cui si assegnano agli assembly i rispettivi insiemi di permessi, in modo del tutto simile agli user groups (gruppi utente) che servono a gestire gli account di Windows.
Quando ad esempio un amministratore vuole permettere l’accesso ad una determinata cartella egli crea un gruppo utente, aggiunge gli utenti a tale gruppo ed infine assegna il permesso al gruppo. I code groups funzionano in modo del tutto simile, con la differenza che non si devono aggiungere individualmente i vari assembly al gruppo poichè l’appartenenza ad un determinato gruppo è determinata dall’evidenza (concetto che abbiamo visto in precedenza) che viene specificata come condizione di appartenenza al gruppo. Ad esempio qualsiasi codice che gira su Internet dovrebbe essere membro del code group Internet_Zone.
Dopo aver definito i precedenti concetti possiamo passare a parlare di security policy, ossia raggruppamenti logici di code groups e di insiemi di permessi. Questi strumenti danno agli amministratori una grande flessibilità nella configurazione del CAS a diversi livelli. Come impostazione predefinita esistono quattro livelli di policy: Enterprise, Machine, User e Application Domain.
Il livello Enterprise è il più elevato e permette di gestire le policy dell’intero sistema, il livello Machine permette di gestire le policy relative al codice che viene eseguito su una determinata macchina, il livello User quelle a livello di utente. L’ambiente di esecuzione valuta questi tre livelli separatamente e fornisce ad un assembly il minimo insieme di permessi garantiti da ogni livello.
Il CAS è completamente indipendente dalla sicurezza del sistema operativo e occorre utilizzare lo strumento .NET Framework Configuration per gestire i permessi dei vari assembly. Il CAS lavora al di sopra della sicurezza del sistema operativo e in pratica quando occorre determinare se un assembly possa o meno effettuare una determinata azione vengono valutati entrambi i tipi di sicurezza e viene applicato l’insieme di permessi più restrittivo.
Se ad esempio il CAS consentisse ad un assembly di poter accedere in scrittura ad una determinata cartella ma l’utente che stesse eseguendo l’assembly non avesse tale permesso allora l’assembly non potrebbe scrivere in quella cartella.
Di seguito un’immagine tratta dal sito Microsoft che rende bene l’idea di questi concetti:
Quindi lo strumento .NET Framework Configuration fornisce un’interfaccia grafica per la gestione delle policy di sicurezza e delle applicazioni che usano servizi remoti. Tra le varie operazioni che è possibile effettuare citiamo:
- Verifica di un assembly per determinare di quale code group sia membro
- Verifica di un assembly per determinare di quali permessi disponga
- Aggiunta di un nuovo insieme di permessi
- Aggiunta di un nuovo code group
- Reset dei livelli di policy
Vediamo come effettuare la prima di queste operazioni. Per prima cosa avviamo lo strumento .NET Framework Configuration e quindi andiamo nella scheda Strumenti di amministrazione, selezionando la voce Microsoft .NET Framework Configuration
Si apre la seguente finestra
In essa dobbiamo cliccare su Configure Code Access Security Policy e poi su Evaluate Assembly. Nella nuova finestra che si apre basta selezionare il percorso dell’assembly che si vuole valutare e cliccare su Next. A questo punto comparirà una finestra con il riepilogo delle informazioni di interesse.
Le altre operazioni si possono effettuare in modo del tutto simile, selezionando le opportune voci. Per approfondire la conoscenza su di esse vi invito, come sempre, a consultare la documentazione ufficiale Microsoft.
mrwebaster.it
Formattazione testo mia.