Protezione

I nuovi ACL migliorano la protezione in Windows Vista

Jesper Johansson

Panoramica:

• Novità negli ACL
• Controlli più rigidi sull'amministratore
• Autorizzazioni per il programma di installazione trusted
• Utenti e gruppi modificati

Sebbene la struttura di base degli elenchi di controllo di accesso (ACL) per Windows Vista non sia stata modificata in modo radicale, sono state tuttavia apportate alcune piccole ma importanti modifiche che è necessario conoscere. Alcune modifiche

sono state ritenute necessarie in quanto in Windows® XP gli ACL sono stati responsabili di diversi problemi. Innanzitutto, la maggior parte degli utenti di Windows XP dispone di privilegi di esecuzione come amministratore, ovvero utilizza un account membro del gruppo Administrators predefinito. Per gli utenti privati, questo rappresenta una certezza virtuale in quanto tutti gli account aggiunti durante l'installazione diventano amministratori. Pertanto, tutti i programmi utilizzati da questi utenti verranno eseguiti con privilegi amministrativi, con conseguente possibilità di accesso illimitato al sistema operativo. Ovviamente, questa situazione si rivela particolarmente problematica in caso di programmi di dubbia provenienza.

Il secondo problema da risolvere era rappresentato dal fatto che gli ACL predefiniti nelle versioni precedenti di Windows erano spesso motivo di irritazione per gli utenti in quanto includevano voci di controllo di accesso (ACE) per gruppi come Everyone, Power Users e simili. Ad esempio, l'ACL predefinito nella directory radice del volume di avvio (in genere C:\) in Windows XP concedeva l'accesso in lettura al gruppo Everyone e l'autorizzazione per la creazione di cartelle ai membri del gruppo Users. Infine, Windows XP prevedeva alcune limitazioni sui tipi di operazioni eseguibili con gli ACL. In Windows XP non era ad esempio possibile assegnare autorizzazioni al proprietario corrente di un oggetto. Questo sistema operativo prevedeva l'assegnazione delle autorizzazioni di proprietario, ma non il trasferimento di tali autorizzazioni in caso di modifica del proprietario. Analogamente, i proprietari disponevano sempre di diritti impliciti per un oggetto, indipendentemente dalle autorizzazioni ad essi assegnate per l'oggetto in questione.

Con Windows Vista™, Microsoft si è assunta l'impegno di risolvere la maggior parte di questi problemi e di attivare il supporto per altre funzionalità, come il controllo dell'account utente. Questo articolo è incentrato sulle modifiche più significative correlate al controllo dell'accesso in Windows Vista. La trattazione di questo argomento proseguirà nell'articolo del prossimo mese, in cui verranno esaminati gli strumenti che è possibile utilizzare per la gestione del controllo dell'accesso.

Utenti e gruppi nuovi e modificati

Alcuni utenti e gruppi in Windows Vista sono nuovi, mentre altri, già esistenti in Windows XP, sono stati rimossi. Inoltre, è stato modificato il comportamento di alcuni utenti e gruppi. Ciascuna delle modifiche apportate ha un certo impatto sulla modalità di gestione del controllo dell'accesso.

Amministratore: disattivato per impostazione predefinita L'account amministratore predefinito, a cui è associato l'identificatore relativo (RID) 500, è ora disattivato per impostazione predefinita nella maggior parte dei casi. L'account amministratore è stato creato per i casi di emergenza, ovvero per essere utilizzato per il recupero del computer come ultima opzione quando tutte le altre falliscono. Nella maggior parte dei casi viene tuttavia utilizzato come account amministrativo standard, violando pertanto diversi principi di protezione. La violazione del più significativo di questi principi, l'accountability, ovvero la capacità di identificare le azioni e il comportamento di un utente all'interno di un sistema, implica l'incapacità di tenere traccia dell'autore di eventuali modifiche al sistema. Pertanto, l'account è stato dichiarato parzialmente obsoleto. È possibile che in futuro l'account venga dichiarato da Microsoft completamente obsoleto, ma per ora è disattivato per impostazione predefinita. Se non sono presenti altri account locali nel gruppo Administrators, sarà possibile continuare a utilizzare RID 500 nella Console di ripristino di emergenza e in modalità provvisoria; in caso contrario, non potrà e non dovrà essere utilizzato.

Tenere presente che esiste una differenza tra l'account amministratore predefinito e gli altri account nel gruppo Administrators. In genere, le iniziali del termine "Administrator" sono in maiuscolo quando si fa riferimento all'account con il RID 500 per distinguerlo da un account "amministratore" che rappresenta qualsiasi altro account membro del gruppo Administrators predefinito. Anche le iniziali dei nomi dei gruppi sono in maiuscolo.

In Windows XP, l'account amministratore predefinito disponeva di alcuni diritti e privilegi speciali non concessi a nessun altro amministratore. Molti di questi privilegi sono stati rimossi in Windows Vista, con due importanti eccezioni: Primo, un account amministratore disattivato può essere utilizzato nella Console di ripristino di emergenza se non sono presenti altri amministratori locali. Secondo, l'account amministratore non è soggetto al controllo dell'account utente e dispone sempre di un token amministrativo completo. Lo stesso vale per l'amministratore di dominio (RID 500 in un dominio).

Rimozione delle autorizzazioni del gruppo Power Users Il gruppo Power Users precedente è stato, per motivi pratici, disattivato. Il gruppo è ancora presente, ma molte delle autorizzazioni ad esso assegnate sono state rimosse. Non è affatto un segreto che un utente che era membro del gruppo Power Users era in sostanza un amministratore a tutti gli effetti che tuttavia non aveva assunto formalmente i privilegi di amministratore. Una volta mi è capitato di sostituire un computer su cui veniva eseguito Windows XP Service Pack 2 (SP2) e a cui sono state applicate tutte le patch in meno di 45 minuti, ottenendo privilegi amministrativi. Tali privilegi includevano il riconoscimento, la scrittura di un programma di piccole dimensioni in C++, la disconnessione e la riconnessione per completare la sostituzione, operazioni tutte consentite perché ero membro del gruppo Power Users.

Poiché molte organizzazioni hanno concesso autorizzazioni sofisticate al gruppo Power Users e si basano sull'appartenenza dei relativi utenti a tale gruppo, non è stato possibile rimuovere il gruppo in Windows Vista. Tuttavia, è probabile che Microsoft rimuova completamente il gruppo Power Users in una versione futura di Windows. È pertanto consigliabile iniziare a pianificare la migrazione dal gruppo Power Users.

Programma di installazione trusted Il programma di installazione trusted è un servizio, non un utente, anche se dispone di autorizzazioni in tutto il file system. La protezione avanzata consente di considerare ogni servizio come entità di protezione completa a cui è possibile assegnare le stesse autorizzazioni concesse a qualsiasi altro utente. Per una panoramica di questa funzionalità, vedere il numero di gennaio 2007 di TechNet Magazine. Nel libro Windows Vista Security (Grimes e Johansson, Wiley Press, 2007) la protezione avanzata viene esaminata in dettaglio, illustrando, tra l'altro, il modo in cui viene utilizzata da altre funzionalità, come il firewall e IPsec.

I SID dei servizi non vengono rilasciati dalle autorità descritte in precedenza, come NT AUTHORITY o un dominio. Il nome completo per l'account virtuale TrustedInstaller è NT SERVICE\TrustedInstaller e il relativo SID è il seguente:

S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464

È possibile visualizzare il SID per qualsiasi servizio, anche per quelli non esistenti, eseguendo il comando sc showsid, come illustrato nella Figura 1.

Figura 1** sc showsid mostra il SID per qualsiasi servizio, inclusi quelli non ancora esistenti **(Fare clic sull'immagine per ingrandirla)

Questo SID inizia con S-1-5-80. Osservare che la prima sottoautorità è 80, che corrisponde a SECURITY_SERVICE_ID_BASE_RID, il che indica che questo SID viene rilasciato dalla sottoautorità NT SERVICE a un servizio. Lo stesso vale per qualsiasi servizio. Le sottoautorità e i RID rimanenti sono basati sul nome del servizio stesso. Questo consente a uno sviluppatore di concedere le autorizzazioni al relativo servizio senza dover prima creare e installare il servizio, in quanto il nome è deterministico e non cambia da computer a computer.

Qualora non si sia in grado di individuare il servizio TrustedInstaller nel gestore dei servizi, il relativo nome visualizzato è "Programma di installazione dei moduli di Windows".

Rimozione degli account Guida e supporto tecnico Gli account Support_xxxxxx e HelpAssistant sono stati entrambi rimossi dalle installazioni pulite di Windows Vista, anche se vengono mantenuti durante l'aggiornamento da una versione precedente di Windows. L'account Support_xxxxxx veniva utilizzato per eseguire gli script del supporto tecnico. È possibile che alcuni OEM che fornivano contenuto della Guida personalizzato fornissero anche account di supporto creati da loro stessi. Non è chiaro cosa accadrà agli account degli OEM, ma è molto probabile che gli OEM smetteranno semplicemente di crearli. In verità, questi account non sono più necessari. Infatti, dal punto di vista della protezione, non è stata un'idea brillante consentire agli utenti di eseguire gli script del supporto tecnico così come di un qualsiasi altro utente e, pertanto, sarebbe meglio se questi account non venissero più utilizzati. Per eseguire questa attività, Windows Vista fornisce un nuovo meccanismo.

L'account HelpAssistant veniva utilizzato durante l'assistenza remota. Analogamente al supporto tecnico, la funzionalità di assistenza remota è stata riprogettata per evitare l'utilizzo dell'account HelpAssistant che, pertanto, è stato rimosso.

Nuovi SID basati sui percorsi di rete Nei sistemi operativi basati su Windows NT® sono stati sempre presenti alcuni SID basati sui percorsi di rete, come NETWORK e INTERACTIVE, che indicano gli utenti che eseguono l'accesso dalla rete e in modo interattivo. Esiste inoltre un SID REMOTE INTERACTIVE LOGON che viene assegnato agli utenti che eseguono l'accesso tramite Servizi terminal. Tenere presente che gli utenti di Servizi terminal avranno nei relativi token sia il SID REMOTE INTERACTIVE LOGON che il SID INTERACTIVE LOGON. In Windows Vista sono stati aggiunti altri due SID: REMOTO e INTERNET. L'esatta motivazione logica alla base dell'aggiunta di un account che indica un accesso tramite connessione remota non è molto chiara, soprattutto considerando che un numero sempre crescente di utenti non stabilirà alcuna connessione a Internet se l'unica rete disponibile è una linea telefonica. Il SID INTERNET è stato ovviamente progettato per indicare qualsiasi utente che esegua l'accesso superando i confini della rete LAN. Il SID NETWORK, tuttavia, indica qualsiasi utente che esegua l'accesso dalla rete, incluso Internet.

DIRITTI PROPRIETARIO e diritti di proprietario Ora è disponibile un SID per DIRITTI PROPRIETARIO, che si applica a qualsiasi utente che diventi proprietario di un file al momento dell'accesso. Questo SID viene utilizzato principalmente per limitare le operazioni che il proprietario può eseguire con il file. Sono state apportate due modifiche significative alla modalità d funzionamento dei diritti di proprietario rispetto a Windows XP. Primo, se un utente è proprietario dell'oggetto, ma nell'oggetto è presente una voce di controllo di accesso applicabile allo stesso utente, i diritti nella voce ACE avranno la priorità sui diritti di proprietario dell'utente. Poiché al proprietario sono sempre stati associati diritti impliciti, questa importante modifica avrà un significativo impatto su alcuni aspetti dell'amministrazione del sistema. Secondo, il SID DIRITTI PROPRIETARIO può essere utilizzato per limitare ulteriormente le operazioni che il proprietario può eseguire con un oggetto.

Si supponga di disporre di una cartella di proprietà dell'utente Jesper, che contiene un ACL, come illustrato nella Figura 2. L'utente, Jesper, dispone solo dell'autorizzazione di lettura per la cartella, anche se è il proprietario. Se tenta di copiare un file in tale cartella, la copia non riuscirà in quanto Jesper non dispone dell'autorizzazione di scrittura nella cartella. Questo non è tuttavia completamente evidente nei messaggi di errore. Se si tenta di copiare un file in una cartella di cui si è proprietario ma non si dispone dell'autorizzazioni di scrittura per l'utilizzo di Esplora risorse®, si verifica la seguente situazione: innanzitutto, un messaggio in Esplora risorse indica e richiede la necessità di elevare le autorizzazioni per copiare il file, ma la copia del file non riesce perché non si dispone dei diritti di copia in questa cartella. Vengono visualizzati il messaggio di errore "Per eseguire l'operazione è necessaria l'autorizzazione" e i pulsanti "Riprova" (sostanzialmente inutile) e "Annulla". Questa situazione si verifica anche se si è proprietario della cartella.

Figura 2** Solo l'account di sistema locale e un altro utente hanno accesso a questa cartella. **(Fare clic sull'immagine per ingrandirla)

Se Jesper tenta di modificare l'ACL nel file, gli verrà chiesto di elevare il relativo token prima di eseguire questa operazione. Poiché è il proprietario del file, ha la possibilità di effettuare questa operazione. Il proprietario dispone di diritti impliciti per la lettura e la modifica dell'ACL (READ_CONTROL e WRITE_DAC) a meno che non sia presente una voce ACE per DIRITTI PROPRIETARIO che specifichi diversamente.

Per comprendere l'effetto del SID DIRITTI PROPRIETARIO, aggiungiamo questo SID all'ACL sopra citato. A questo punto, si dispone delle autorizzazioni illustrate nella Figura 3.

Figura 3** L'aggiunta delle autorizzazioni DIRITTI PROPRIETARIO alla cartella consente di modificare le autorizzazioni di Jesper **(Fare clic sull'immagine per ingrandirla)

Con queste autorizzazioni, se l'account Jesper tenta di eseguire una copia nella cartella, questa operazione riuscirà in quanto Jesper è il proprietario e dispone dei diritti appropriati. Tuttavia, se Jesper tenta di modificare l'ACL nell'oggetto, questa operazione non riuscirà. La voce ACE per DIRITTI PROPRIETARIO specifica che il proprietario deve disporre solo del privilegio di modifica, ma non gli è consentito modificare l'elenco di controllo di accesso discrezionale (DACL). Pertanto, l'autorizzazione DIRITTI PROPRIETARIO viene utilizzata principalmente per rimuovere WRITE_DAC, ovvero la capacità di modificare il descrittore di protezione, dal proprietario.

Se un amministratore modifica il proprietario dell'oggetto, le autorizzazioni DIRITTI PROPRIETARIO non verranno automaticamente trasferite al nuovo proprietario. In questo caso, la voce ACE per DIRITTI PROPRIETARIO viene disattivata e viene contrassegnata come Solo eredità ma non viene applicata a contenitori o oggetti; in altre parole non viene applicata a nulla. Questa operazione viene eseguita per assicurare che gli amministratori non vengano completamente esclusi dall'utilizzo dell'oggetto. Per applicare di nuovo la voce ACE per DIRITTI PROPRIETARIO, l'amministratore deve accedere alla voce ACE e riattivarla manualmente. A tal fine, occorre contrassegnarla come applicabile alla cartella corrente, alle sottocartelle e ai file desiderati.

Il SID DIRITTI PROPRIETARIO può rivelarsi molto utile in numerosi scenari interessanti, ad esempio quando l'amministratore desidera che gli utenti siano in grado di creare file e cartelle su un file server, ma non desidera che siano in grado di modificare gli ACL in tali cartelle. Un'altra probabile situazione è rappresentata da uno scenario in cui alcuni utenti sono stati membri per un determinato periodo di un gruppo e hanno creato alcuni oggetti ma, successivamente, probabilmente per motivi aziendali, sono stati rimossi da questo gruppo. A questo punto, tali utenti non dovrebbero essere in grado di modificare le impostazioni sugli oggetti creati.

Il SID DIRITTI PROPRIETARIO viene ampiamente utilizzato nella protezione avanzata. Quando un servizio crea un oggetto transitorio in fase di esecuzione, il creatore dell'oggetto rappresenta il SID principale del processo di servizio, in genere LocalSystem, NetworkService o LocalService, e non il SID per il servizio stesso. Ne consegue che qualsiasi altro servizio in esecuzione nello stesso contesto del processo può modificare l'oggetto, uno scenario quasi mai auspicabile. Se si imposta un SID DIRITTI PROPRIETARIO per tali oggetti, il sistema operativo sarà in grado di impedire ad altri servizi di accedere agli oggetti.

ACL predefiniti

Gli ACL predefiniti in Windows XP garantivano un discreto livello di protezione. A parte alcuni problemi di ridotta entità, come consentire agli utenti di inserire i file nella directory principale del volume di avvio, erano in linea di massima una "soluzione assennata". Tuttavia, alcuni OEM hanno avuto la presunzione di avere un'idea più precisa di cosa costituisse una discreta protezione. Nella schermata nella Figura 4 viene illustrata un'immagine dell'ACL contenuto nella directory di Windows su un computer che esegue Windows XP Media Center Edition di un importante OEM. L'OEM ha disattivato essenzialmente la protezione del file system.

Figura 4** ACL configurato da un OEM **

Microsoft ha apportato alcune modifiche agli ACL in Windows Vista. Innanzitutto, chiunque abbia familiarità con Windows XP saprà senz'altro che tutti i file del sistema operativo sono di proprietà del gruppo Administrators e che gli amministratori dispongono del controllo completo su tali file. Ogni membro del gruppo Administrators disponeva pertanto di un accesso illimitato a questi file. Questo non avviene in Windows Vista.

Programma di installazione trusted In Windows Vista, la maggior parte dei file del sistema operativo è di proprietà del SID TrustedInstaller e solo tale SID dispone del controllo completo su questi file. Questa modifica è parte integrante dei meccanismi di integrità che sono stati introdotti in Windows Vista e ha lo scopo specifico di impedire a un processo eseguito come amministratore o sistema locale di sostituire automaticamente i file. Per eliminare un file del sistema operativo, è necessario pertanto assumere la proprietà del file e aggiungervi una voce ACE che consenta di eliminarlo. Questo fornisce un livello minimo di protezione contro un processo eseguito come LocalSystem e che dispone dell'etichetta di integrità Sistema; si suppone che un processo con livello di integrità basso non sia in grado di elevare i relativi privilegi per modificare la proprietà. Alcuni servizi, ad esempio, possono essere eseguiti con livello di integrità medio anche se vengono eseguiti con un account di sistema locale. Tali servizi non possono sostituire i file di sistema e, pertanto, un potenziale exploit che assume il controllo di questi servizi non sarà in grado di sostituire i file del sistema operativo, rendendo un po' più difficoltosa l'installazione di un rootkit o altro malware nel sistema. Inoltre, diventa ancora più difficile per gli amministratori di sistema che non gradiscono la presenza di un file binario di sistema rimuovere tale file.

Voci ACE di negazione Numerosi oggetti nel file system contengono voci ACE di negazione associate al gruppo Everyone, il che è stato motivo di grande costernazione per la maggior parte degli amministratori. Se si attiva l'opzione "Visualizza cartelle e file nascosti", verrà visualizzata la nota directory Documents and Settings. Se, tuttavia, si fa clic su tale directory, verrà visualizzato il messaggio di errore Accesso negato. Per capire cosa avviene nella directory Documents and Settings, esaminare l'elenco delle directory nella Figura 5.

Figura 5** Documents and Settings è un punto di giunzione, non una directory **(Fare clic sull'immagine per ingrandirla)

Documents and Settings, in realtà, non è una directory ma un punto di giunzione. Tenere presente che i punti di giunzione sono simili ai collegamenti simbolici che reindirizzano semplicemente l'accesso a una destinazione differente. In questo caso, la giunzione reindirizza a una directory definita C:\Users. Microsoft ha apportato modifiche significative allo spazio dei nomi del file system in Windows Vista e i dati degli utenti sono stati spostati in C:\Users. Anche altri elementi sotto il precedente spazio dei nomi "C:\Documents and Settings\<Nomeutente>" sono stati spostati. Ad esempio, "C:\Documents and Settings\<Nomeutente>\Dati applicazioni" è stato spostato in C:\Users\<nomeutente>\appdata\roaming. È possibile avere un'idea più chiara delle modifiche apportate se si accede a una riga di comando e si utilizza il comando dir /a, come illustrato nella Figura 5. La ragione per cui lo spazio dei nomi è stato modificato in modo così radicale risiede nella necessità di renderlo più intuitivo per gli utenti e di ottenere una separazione più netta tra documenti e dati. Anziché memorizzare tutti i file di dati sotto la cartella documenti, gli sviluppatori possono ora creare cartelle personalizzate sotto il profilo dell'utente e l'utente sarà in grado di visualizzarle da tale posizione. I dati delle applicazioni per tutti gli utenti ora risiedono in una cartella nascosta denominata %systemroot%\ProgramData anziché in Documents and Settings\All Users\Dati applicazioni.

Microsoft non ha rimosso lo spazio dei nomi "C:\Documents and Settings" in quanto le applicazioni precedenti potrebbero essere configurate a livello di codice per l'utilizzo di tale nome anziché delle variabili di ambiente desiderate, come %USERPROFILE%. Tali applicazioni smetterebbero di funzionare nel caso in cui lo spazio dei nomi "C:\Documents and Settings" venisse rimosso. Pertanto, questi percorsi sono ora rappresentati come punti di giunzione o collegamenti simbolici per garantire la compatibilità con le versioni precedenti. Tuttavia, è possibile che le applicazioni in cui tali percorsi sono specificati a livello di codice smettano comunque di funzionare, a seconda della modalità con cui accedono ai dati presenti nei percorsi in questione; nelle versioni di Windows in lingue diverse dalla lingua inglese, tali applicazioni non sono più funzionanti. Questo aspetto è fondamentale. Quando un aggiornamento a Windows, ad esempio Windows XP SP2 o Windows Vista, compromette il funzionamento di programmi di terze parti, la ragione risiede quasi sempre nella formulazione di ipotesi non valide o nell'utilizzo improprio di Windows da parte degli sviluppatori di questi programmi.

Se si tenta di aprire un file, ad esempio digitando "C:\Documents and Settings\<Nomeutente>\Documenti\foo.txt", l'operazione riuscirà, purché si disponga di un file in tale percorso denominato foo.txt. Tuttavia, se si tenta di accedere a "C:\Documents and Settings\<Nomeutente>\Documenti", verrà visualizzato il messaggio di errore "Accesso negato". Per capire cosa succede, dare un'occhiata all'ACL nella Figura 6.

Figura 6** In Documents and Settings è presente una voce ACE di negazione **(Fare clic sull'immagine per ingrandirla)

Esaminare la prima voce ACE nell'elenco. Si tratta di una voce ACE di negazione per il gruppo Everyone per la visualizzazione del contenuto delle cartelle. I programmi possono attraversare i punti di giunzione e aprire i documenti con percorsi assoluti perché il gruppo Everyone dispone del privilegio Ignorare controllo incrociato (noto anche come SeChangeNotifyPrivilege). I tentativi di un utente o un processo di enumerare le directory che rappresentano non riusciranno a causa della presenza della voce ACE di negazione. Per questo motivo non è possibile visualizzare il contento all'interno di C:\Documents and Settings né eliminare la "directory". La ragione principale dell'inserimento della voce ACE di negazione in questo percorso consiste nell'impedire agli utenti di eliminare la giunzione e compromettere il funzionamento delle applicazioni precedenti. Ha lo scopo inoltre di ricordare agli sviluppatori di non scrivere applicazioni che prevedono l'utilizzo dello spazio dei nomi precedente ma che possano essere avviate tramite l'uso di variabili di ambiente o stringe del Registro di sistema in modo da isolare le applicazioni da eventuali modifiche future e differenze di lingua.

Tenere presente che tutti i punti di giunzione sono nascosti per impostazione predefinita e pertanto la maggior parte degli utenti non è in grado di visualizzarli. Per impedire che vengano eliminati, Microsoft ha inserito una voce ACE di negazione per l'autorizzazione "Visualizzazione contenuto cartella".

Ignorare controllo incrociato La ragione per cui gli utenti possono accedere ai file per i quali dispongono dei diritti appropriati all'interno di cartelle (o punti di giunzione) per le quali non dispongono di diritti risiede nel fatto che il gruppo Everyone dispone del privilegio Ignorare controllo incrociato. Ignorare controllo incrociato o SeChangeNotifyPrivilege rappresenta il privilegio di base in Windows e viene concesso a un processo per il quale tutti gli altri privilegi sono stati rimossi, a meno che il processo non richieda esplicitamente che gli venga rimosso anche tale privilegio. Questo è quello che accade quando si avvia un processo utilizzando la riga runas /trustlevel:0x10000 < in Windows Vista. Il programma specificato in <comando> verrà eseguito con un token con restrizioni e tutti i privilegi, eccetto SeChangeNotifyPrivilege, verranno rimossi dal token del processo.

Il punto più interessante è che trustlevel 0x20000 fornisce un token con il set di SID standard ma con privilegi rimossi. 0x40000 fornisce un token completamente normale.

Autorizzazioni predefinite

Le autorizzazioni predefinite nel file system di Windows Vista presentano lievi differenze rispetto a Windows XP. Se si esamina l'ACL in %systemdrive% (in genere l'unità C: o volume di avvio), in Windows XP o Windows Server® 2003, è possibile osservare quanto riportato di seguito (o qualcosa di molto simile nelle versioni precedenti di Windows XP):

D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU) 

Di seguito viene illustrato lo stesso ACL all'interno della stessa directory in Windows Vista:

D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU) 

È possibile rilevare numerose differenze degne di nota. Innanzitutto, ora sono presenti due voci ACE per BA (BUILTIN\Administrators) anziché una, ma il risultato finale è lo stesso. In Windows Vista, una voce ACE non viene ereditata e concede l'accesso completo alla directory radice, mentre l'altra voce ACE è una voce ACE IO (Solo eredità), ereditata da contenitori e oggetti, e concede il controllo completo o GA (Generico completo). Lo stesso vale per la sostituzione della voce ACE per SY (LocalSystem) con due voci ACE in Windows Vista. In Windows XP, l'unica voce ACE disponibile concedeva l'accesso completo ed era ereditata da oggetti e contenitori. Ancora una volta non si nota una modifica sostanziale. La ragione principale per la modifica dell'ACL è il tentativo di chiarire e ridurre i privilegi in modo da semplificare la gestione e, potenzialmente, il ripristino dell'ACL.

L'aspetto più interessante è che la voce ACE per CO (Creator/Owner) è stata rimossa. Ne consegue che se un utente crea un oggetto nella directory radice del file system, non vengono più concesse autorizzazioni speciali al creatore dell'oggetto.

È inoltre possibile osservare che la voce ACE per WD (Everyone) è stata rimossa. La maggior parte degli utenti interessati alla protezione, sebbene sia possibile che non abbiano compreso completamente le implicazioni delle loro azioni, ha espresso forti perplessità su questa voce ACE. Microsoft ha tentato invano per anni di spiegare che Everyone era dal punto di vista funzionale identico al gruppo Users predefinito, ma alla fine ha optato per la rimozione di tale voce. Poiché è presente una voce ACE identica per BU (BUILTIN\Users), anch'essa ereditata da contenitori e oggetti, il risultato finale è che nulla è cambiato.

Inoltre, due delle voci ACE per BU, ovvero il gruppo Users predefinito, sono state sostituite con le voci ACE per AU (Authenticated Users). La ragione risiede nel fatto che l'account Guest è membro del gruppo Users predefinito (in virtù del fatto che INTERACTIVE è membro del gruppo Users predefinito), ma Guest non è membro di Authenticated Users. Per consentire all'account Guest di leggere ed eseguire file, la voce ACE 0x1200a9 (Lettura/esecuzione) continua a essere concessa al gruppo BU. Tuttavia, le voci ACE che concedono le autorizzazioni per la creazione di file e cartelle sono invece concesse al gruppo Authenticated Users. Questo è un elemento di grande differenza rispetto a Windows XP. In Windows XP, un account Guest era in grado di creare file nella directory radice. In Windows Vista, un account Guest non è in grado di creare tali file. Tenere presente, tuttavia, che questa considerazione non è valida per i casi in cui l'account Guest è attivato e i membri del gruppo Guests sono in grado di accedere alla directory radice del volume di avvio. Per impostazione predefinita, l'account Guest è disattivato.

Infine, nei due elenchi sopra riportati sono presenti un paio di voci ACE molto interessanti e apparentemente complicate. In Windows XP, è presente una voce ACE ereditata da contenitori, che specifica 0x100004 per il gruppo Users predefinito. Questa voce ACE concede al gruppo Users il diritto di creare sottocartelle in quanto è ereditata dai contenitori. È presente anche una voce ACE Solo eredità, ereditata dalle sottocartelle per 0x100002. Questa voce concede agli utenti il diritto di creare file e sottocartelle nelle cartelle da essi create sotto la directory radice. In altre parole, queste due voci ACE consentono agli utenti, compresi i membri del gruppo Guests, di creare file e cartelle sotto la directory radice, come indicato in precedenza.

In Windows Vista, le voci ACE corrispondenti sono una voce ACE Solo eredità, ereditata da contenitori e file, che concede le autorizzazioni GR (Lettura generica), GX (Esecuzione generica) e GW (Scrittura generica) insieme a SD (Descrittore di protezione), e una voce ACE applicabile solo alla directory radice che concede il privilegio LC. LC è un acronimo che appartiene alle voci ACE in Active Directory®. In Active Directory, questo acronimo indica che un utente è in grado di visualizzare oggetti figlio. Tuttavia, il valore esadecimale di LC è 0x4. Per una directory, 0x4 corrisponde a FILE_ ADD_SUBDIRECTORY, che diventa equivalente, dal punto di vista funzionale, a 0x100004, in quanto è già disponibile il valore 0x100000 (capacità di utilizzare l'oggetto per la sincronizzazione) che viene fornito dalla voce ACE 0x1200a9. In altre parole, si ottiene lo stesso risultato ottenuto in Windows XP: gli utenti hanno la capacità di creare sottodirectory all'interno della directory principale.

Da dove provengono i valori esadecimali? E soprattutto cosa sono i valori esadecimali? Come si è potuto osservare, il controllo dell'accesso è costituito da numeri esadecimali (base16), come 0x1200a9. Questi numeri sono in effetti rappresentazioni dei bit delle maschere di bit all'interno di una maschera di accesso che sono attivati, il che indica che vengono utilizzati nella specifica voce ACE. Quando si utilizza uno strumento, come icacls, sc o secedit per elencare un ACL, le maschere di bit vengono rappresentate da stringhe di testo molto più semplici se esiste una corrispondenza 1:1.

Pertanto, per determinare il significato di LC, è sufficiente accedere al sito Web MSDN®, individuare la stringa LC e cercare nella colonna relativa ai valori dei diritti di accesso ADS_RIGHT_ACTRL_DS_LIST. Se si apre il file di intestazione Iads.h e si cerca questa stringa, si scoprirà che corrisponde a 0x4. Per le stringhe non Active Directory (quelle che non sono precedute dal prefisso "ADS_RIGHT"), il valore esadecimale si trova generalmente in AccCtrl.h. Una volta individuato il valore esadecimale, è piuttosto semplice cercarlo nella maschera di accesso in WinNt.h o AccCtrl.h per determinarne il significato.

Per ulteriori informazioni in merito, è opportuno consultare il libro Protect Your Windows Network (di Jesper Johansson e Steve Riley, Addison-Wesley, 2005). Il capitolo 17 tratta in maniera dettagliata la modalità di analisi delle stringhe SDDL (Security Description Definition Language) e delle voci ACE.

Le autorizzazioni concesse a tali sottodirectory sono gestite esclusivamente dalla voce ACE (A;OICIIO;SDGXGWGR;;;AU) in Windows Vista, il che rappresenta la differenza più significativa tra Windows Vista e Windows XP. Anziché concedere il controllo completo al creatore delle sottodirectory, come in Windows XP, Windows Vista concede privilegi di modifica agli utenti membri del gruppo Authenticated Users.

Il risultato finale di questo nuovo ACL è che il creatore di un oggetto non può più disporre di diritti special. Probabilmente, la maggiore differenza rispetto a Windows XP è che il gruppo Authenticated Users dispone dei privilegi di modifica anche per le sottocartelle create dagli amministratori. In Windows XP, i gruppi Users e Authenticated Users non dispongono di diritti per gli oggetti creati dagli amministratori nella directory radice. Nel complesso, tuttavia, sebbene queste voci ACE possano sembrare complesse, il risultato finale non è molto differente da quello ottenuto in Windows XP.

In sintesi, in Windows Vista tutti, compreso l'utente Guest, sono in grado di leggere ed eseguire file nella directory radice. Solo agli utenti membri del gruppo Authenticated Users è consentito creare nuovi file e cartelle e, dopo che li hanno creati, vengono loro concesse le autorizzazioni di modifica per i file e le cartelle in questione. In altre parole, le autorizzazioni sono leggermente più limitate in Windows Vista rispetto a Windows XP, anche se è importante notare che l'account Guest è disattivato per impostazione predefinita.

Modifiche ai token

Quando un utente membro del gruppo Administrators in Windows XP esegue l'accesso, il relativo token contiene il SID del gruppo Administrators e l'utente può seguire tutte le operazioni consentite al gruppo Administrators. In Windows Vista, invece, questo non avviene a causa del controllo dell'account utente. Il SID del gruppo Administrators è ancora presente nel token, ma è contrassegnato come di sola negazione, come illustrato nella schermata di Process Explorer nella Figura 7.

Figura 7** Con il controllo dell'account utente, il SID del gruppo Administrators viene utilizzato solo per la negazione dell'accesso a meno che non si esegua l'elevazione dei privilegi **(Fare clic sull'immagine per ingrandirla)

Quando si esegue il controllo dell'accesso, una voce di questo tipo nel token viene utilizzata solo per negare l'accesso, ovvero per soddisfare le voci ACE di negazione. Tutte le voci ACE di consenso per tale SID vengono ignorate. Ne consegue che un utente, anche se esegue l'accesso al sistema come amministratore, in realtà non dispone sempre dei privilegi di amministratore.

Livelli di integrità

Windows ora supporta l'etichettatura di processi e oggetti con livelli di integrità. I livelli di integrità sono rappresentati anche come voci ACE, ma non fanno parte dell'elenco di controllo di accesso discrezionale (DACL). Fanno invece parte dell'elenco di controllo di accesso di sistema (SACL), con alcuni flag speciali. Ad esempio, il flag NW viene utilizzato per indicare un processo con livello di integrità inferiore a cui viene impedito di scrivere in un oggetto con un livello di integrità superiore (SDDL_NO_WRITE_UP). Questo argomento viene trattato in maniera dettagliata da Mark Russinovich nel suo articolo "Controllo dell'account utente di Windows Vista" in questo numero di TechNet Magazine.

Conclusione

Sebbene non siano state introdotte modifiche rivoluzionarie nel controllo dell'accesso in Windows Vista, come è avvenuto in Windows 2000, è possibile osservare numerose piccole modifiche. Tali modifiche, prese singolarmente, non incidono in modo significativo, ma nell'insieme hanno un notevole impatto sulla modalità di gestione del sistema Inoltre, queste modifiche supportano numerose altre iniziative, in particolare il controllo dell'account utente e la protezione avanzata. È possibile che alcuni amministratori restino delusi quando iniziano a utilizzare Windows Vista. Ho assistito più volte a commenti sui "sistemi operativi tirannici" che impongono restrizioni sulla possibilità di eliminazione di parti del sistema operativo che, per ragioni diverse, non sono gradite. Tuttavia, vi sono valide motivazioni alla base delle modifiche introdotte nel nuovo sistema operativo e, molto probabilmente, se si dedica un po' di tempo all'analisi di ciò che è stato fatto, se ne comprenderà il perché.

Jesper Johansson è Security Architect per una grossa azienda di e-commerce, responsabile per la strategia di protezione nell'ambito della gamma delle proprietà e dei servizi delle applicazioni. Ha lavorato nel settore della protezione per 20 anni ed è autore di numerosi articoli e di due libri dedicati alla protezione. Quando non si dedica alla protezione delle informazioni, insegna immersioni subacquee.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.