Controllo della protezioneStrumenti per la gestione degli ACL

Jesper M. Johansson

In Windows, gli elenchi di controllo di accesso (ACL) forniscono un controllo estremamente fine sulla capacità degli utenti e dei processi di utilizzare le risorse, come file e cartelle. La gestione degli ACL può rivelarsi una delle attività più complesse correlate alla protezione dei sistemi degli utenti. Fortunatamente, sono disponibili diverse utilità molto efficaci

che consentono di automatizzare e semplificare le attività associate alle autorizzazioni e agli ACL.

La maggior parte degli utenti avrà familiarità con il vecchio strumento cacls.exe che è stato incluso in ogni versione di Windows NT® sin dalla prima volta in cui questo sistema operativo è stato rilasciato. Se si esegue cacls.exe in Windows Vista™, verrà visualizzato il seguente messaggio di benvenuto:

Microsoft Windows [Version 6.0.5744]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.

C:\Windows\system32>cacls

 NOTE: Cacls is now deprecated, please use Icacls.

Oltre ad aggiornare gli ACL in Windows Vista (trattati nel numero di giugno 2007 di TechNet Magazine; visitare il sito Web technetmagazine.com/issues/ 2007/06), Microsoft ha anche aggiornato alcuni strumenti utilizzati per la gestione degli ACL. L'aspetto più interessante è che i più significativi di questi aggiornamenti sono utilità da riga di comando.

Icacls.exe è una nuova utilità di Windows Vista (e uno strumento di livello inferiore in Windows Server® 2003 Service Pack 2). Questo strumento sostituirà in tutta probabilità cacls.exe, che, come si saprà già, non è mai stato completamente aggiornato per il supporto delle autorizzazioni più granulari introdotte con Windows® 2000 e pertanto l'ultimo aggiornamento di questa utilità risale a circa sette anni fa.

L'aspetto sorprendente è che, malgrado sia obsoleto, cacls.exe include alcune nuove funzionalità. Primo, è in grado di riconoscere sia i punti di giunzione che i collegamenti simbolici ed è in grado di attraversarli. Secondo, è in grado di stampare e impostare un ACL utilizzando la stringa SDDL (Security Description Definition Language).

Tuttavia, malgrado gli aggiornamenti a cacls.exe, in realtà gli utenti sono interessati alle funzionalità disponibili in icacls.exe.

Salvataggio e ripristino degli ACL

Un mio desiderio costante negli ultimi 10 anni ha riguardato la possibilità di salvare un ACL in modo da poterlo ripristinare in un momento successivo. Questa risulta una delle operazioni più complesse che è possibile eseguire sugli ACL. Eccetto in alcuni casi particolari, sono poche le probabilità di tornare esattamente all'ultimo punto salvato in caso di danneggiamento degli ACL. Tuttavia, questa funzionalità può essere piuttosto utile.

Prima di illustrare le attività di salvataggio e ripristino degli ACL, è bene esaminare il motivo della complessità insita in tali operazioni. Si supponga di disporre di una gerarchia contenente i dati relativi agli studenti di un istituto universitario locale. L'ACL viene salvato il primo febbraio. Il 17 aprile si scopre che l'ACL è stato danneggiato e si decide di ripristinarlo dalla copia salvata. Quali sono le complicazioni associate a questa operazione?

Primo, il nuovo trimestre è iniziato il 2 aprile. Circa il 15% degli studenti si è laureato e di conseguenza le relative directory non sono più disponibili. Pertanto, nel file di backup sono presenti ACL non validi. Inoltre, un gruppo di nuovi studenti, un altro 15%, ha cominciato a seguire i corsi universitari con l'inizio del nuovo trimestre. A questi nuovi studenti, nel file di backup sono ora associate home directory, non gli ACL. Quali sono gli ACL relativi a questi nuovi studenti? C'è poi da considerare il 70% degli studenti rimanenti che hanno creato nuovi file e cartelle e naturalmente ne hanno eliminati altri. È possibile ignorare i file e le cartelle eliminati, ma come configurare le nuove cartelle che hanno creato? Che cosa succede se uno studente decidesse di condividere una cartella con i suoi amici il 4 marzo? Questa attività di condivisione verrà interrotta una volta ripristinato l'ACL?

Il salvataggio e il ripristino degli ACL non sono affatto operazioni semplici. È necessario muoversi con estrema cautela quando si eseguono queste operazioni. È molto probabile inoltre che l'esecuzione di queste operazioni causi un comportamento non definito. Il ripristino degli ACL viene in genere eseguito come ultima risorsa; maggiore è il tempo trascorso sin dall'ultimo backup dell'ACL, maggiore sarà la probabilità che si verifichi un errore durante il processo di ripristino.

Se si desidera tuttavia provare questa funzionalità, eseguire icacls.exe con l'opzione /save:

icacls <target> /save acls.bin /t

Gli ACL verranno quindi salvati in un file denominato acls.bin. Il file conterrà una riga per ogni oggetto con un ACL seguita da una riga che specifica l'ACL nella stringa SDDL. Utilizzando l'opzione /t, il comando consentirà di operare sull'oggetto specificato e su tutti gli oggetti e i contenitori al di sotto di esso.

La funzionalità di salvataggio è un miglioramento del toolkit che può arrecare molti vantaggi, ma presenta alcuni difetti. Consente di salvare, ad esempio, solo l'elenco di controllo di accesso discrezionale (DACL) e non l'elenco di controllo di accesso di sistema (SACL). Se, infatti, è presente un SACL, questa funzionalità consente di salvare un valore fittizio che indica solo la presenza di questo elenco, ma non salva alcuna parte del SACL.

Inoltre, la modalità in cui l'ACL viene salvato crea un problema interessante. Prima di aprire l'ACL salvato con l'editor di testo desiderato, tenere presente un punto fondamentale:

non modificare l'ACL salvato.

Se si dovesse aprire il file contenente l'ACL salvato in un editor di testo, si rileverà che il file sembra essere un file di testo in formato Unicode (UTF-16). Infatti, è quasi identico a un file di testo Unicode. Questo potrebbe indurre a pensare che sia possibile modificarlo e salvarlo da un editor di testo. Evitare di eseguire questa operazione.

Se si apre il file che contiene gli ACL salvati in un editor di testo e lo si salva, non sarà più possibile ripristinare gli ACL da tale file. questo file dopotutto non è affatto un file di testo Unicode. Tale file deve iniziare con 2 byte il cui valore è 0xfffe. Se si salva il file con un editor di testo, ad esempio il Blocco note, questo flag verrà inserito nei primi 2 byte all'interno del file. Lo strumento icacls.exe, tuttavia, si aspetta che i dati ACL inizino in corrispondenza del byte 0 nel file. Di conseguenza, lo strumento non sarà in grado di analizzare gli ACL nel file in quanto si aspetta che i primi due byte facciano parte della stringa che specifica l'oggetto su cui operare. Il file di backup sarà inutilizzabile.

Microsoft è consapevole di questo problema, ma poiché è stato riportato molto tardi nel ciclo Beta per Windows Vista, questo difetto non è stato corretto prima del rilascio di questo sistema operativo. Attualmente non si sa quando o se questo problema verrà corretto. Pertanto, per ora, il consiglio migliore è di evitare di modificare gli ACL salvati. Se occorre salvarli, salvare il file come file .bin e utilizzare un editor esadecimale, come l'ambiente di sviluppo preferito.

Una volta salvato un ACL utilizzando l'opzione /save, è possibile ripristinarlo mediante lo strumento icacls.exe utilizzando l'opzione /restore. Il comando di ripristino nella sua forma più semplice utilizza la seguente sintassi:

icacls <directory> /restore acls.bin

La procedura di ripristino non opera sui file. Per un esempio pratico, esaminare la sequenza di comandi illustrati nella Figura 1. Come illustrato nella figura, viene creato un file di salvataggio puntando icacls.exe a un file. Viene eseguito quindi un tentativo di ripristino del file sostituendo semplicemente /save con /restore. Si verifica un errore in quanto il comando di ripristino opera solo sulle directory. I file da modificare sono già specificati nel file acls.bin. Per ripristinare l'ACL, occorre puntare l'ACL alla directory anziché al file. Questa operazione viene eseguita utilizzando l'ultimo comando illustrato in cui viene specificato "." come oggetto su cui operare.

Figure 1 Salvataggio e ripristino degli ACL

C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /restore acls.bin
test.txt\test.txt: The system cannot find the path specified
Successfully processed 0 files; Failed processing 1 files

C:\Users\Jesper>icacls . /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files

Tenere presente inoltre che il comando di ripristino deve essere eseguito con privilegi elevati. È possibile eseguire il comando di salvataggio da un prompt dei comandi come amministratore con privilegi minimi o persino come utente standard, purché si disponga del diritto di lettura dell'ACL. Tuttavia, per ripristinare l'ACL, è necessario disporre di un token amministrativo completo e non sofisticato.

Sostituzione di SID

Un'altra funzionalità molto utile in icacls.exe è la capacità di sostituire le autorizzazioni per un utente con le autorizzazioni per un altro utente. Questa operazione viene eseguita durante il ripristino mediante l'opzione /substitute. In base a quanto riportato nella documentazione relativa all'opzione di sostituzione, questa funzionalità richiede l'utilizzo di un SID; tuttavia, in un altro punto della stessa documentazione viene spiegato che è possibile anche utilizzare un normale nome utente. Pertanto, la sequenza illustrata nella Figura 2 funziona.

Figure 2 Sostituzione dei SID durante il ripristino

C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\foo:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls. /substitute foo bar /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\bar:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files

Come si può osservare, il risultato dell'esecuzione di questa sequenza di comandi è un ACL identico a quello disponibile in precedenza, ma la voce ACE che in precedenza specificava le autorizzazioni per foo ora specifica tali autorizzazioni per bar.

Modifica del proprietario

Lo strumento chown è stato per anni la funzionalità di base dei sistemi UNIX. Windows originariamente non prevedeva alcuna funzionalità integrata per la modifica del proprietario di un oggetto. Successivamente, nel Resource Kit è stato incluso lo strumento setowner. Windows NT 4.0 prevedeva invece lo strumento takeown.exe, ma questa utilità consentiva solo di assumere la proprietà non di concederla ad altri utenti, a meno che non si disponesse delle loro password. Ora icacls.exe fornisce un metodo integrato che consente di impostare il proprietario degli oggetti per i quali si dispone dell'autorizzazione per l'impostazione del proprietario:

C:\>icacls c:\test /setowner foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

Sfortunatamente, icacls.exe non è in grado di visualizzare il proprietario di un oggetto. Non è disponibile alcun metodo per verificare, dalla riga di comando, chi è il proprietario dell'oggetto. Inoltre, se si salva l'ACL per un oggetto, il proprietario dell'oggetto non verrà salvato.

Tenere presente che in icacls.exe è presente un bug dovuto al fatto che questo strumento non richiama SeTakeOwnershipPrivilege per modificare il proprietario. Se si dispone del diritto per la modifica del proprietario di un oggetto in base all'ACL, icacls.exe dovrebbe funzionare in modo corretto. Tuttavia, se si è amministratore, ma non si dispone dell'autorizzazione per la modifica del proprietario in base all'ACL dell'oggetto, non sarà possibile utilizzare icacls.exe a tale scopo a causa del bug sopra menzionato. In tal caso, è necessario utilizzare lo strumento takeown.exe che richiama SeTakeOwnershipPrivilege, ma consente solo di modificare il proprietario nel proprio account o nel gruppo Administrators, non in un account arbitrario:

C:\>takeown /f c:\test

SUCCESS: The file (or folder): “c:\test” now owned by user “JJ-VistaRTMTst\Jesper”.

Tenere presente che anche lo strumento subinacl, che è possibile scaricare dall'Area download Microsoft, fornisce l'opzione setowner. Subinacl in effetti funziona in molti casi in modo più intuitivo rispetto a icacls, ma è molto più complicato da utilizzare.

Individuazione di file per uno specifico utente

Icacls ha un'altra funzione utile: consente di individuare i file che dispongono di autorizzazioni per specifici utenti. Ad esempio:

C:\windows\system32>icacls “c:\program files” /findsid jesper /t

SID Found: c:\program files\Passgen\
passgen.exe.
Successfully processed 1808 files; Failed processing 0 files

Questo potrebbe rivelarsi utile nel caso in cui si tenti di individuare il tipo di accesso consentito a uno specifico utente.

Ripristino e modifica degli ACL

Se un ACL viene danneggiato o eliminato, icacls.exe consente di reimpostarlo in modo da ereditare dal relativo padre. Questa funzionalità sarebbe stata estremamente utile per contrastare le minacce di tipo "zero day" che hanno cominciato a colpire nell'autunno del 2006. Un metodo utilizzato per limitare il problema in un componente di Windows è stato negare l'accesso Everyone all'oggetto. Questo era semplice, ma la rimozione della voce di controllo di accesso (ACE) era quasi impossibile mediante gli strumenti integrati in Windows XP e Windows Server 2003. Tuttavia, in Windows Vista, è sufficiente eseguire il seguente comando:

C:\windows\system32>icacls “c:\program files\passgen\passgen.exe” /reset

processed file: c:\program files\passgen\passgen.exe
Successfully processed 1 files; Failed processing 0 files

Icacls.exe, ovviamente, consente di eseguire tutte le operazioni standard di concessione/negazione/rimozione. L'unico elemento realmente nuovo in questo elenco è la rimozione. Utilizzando questa opzione, è possibile rimuovere tutte le voci ACE di consenso, tutte le voci ACE di negazione o entrambi i tipi di voce per un determinate utente da uno specifico oggetto o gerarchia. Nella Figura 3 vengono illustrati alcuni esempi di diverse operazioni di concessione, rimozione e negazione.

Figure 3 Operazioni di concessione, negazione e rimozione

C:\>icacls c:\test /grant foo:(F)
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(F)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:g foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /deny foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(N)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:d foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

La capacità di rimuovere solo le voci ACE di negazione può risultare utile se si desidera concedere l'accesso a un oggetto a uno specifico gruppo o utente.

Impostazione dei livelli di integrità

Icacls.exe consente inoltre di visualizzare e impostare i livelli di integrità. Windows Vista supporta l'applicazione di etichette di integrità agli oggetti. Icacls.exe è lo strumento da riga di comando da utilizzare per eseguire questa operazione:

C:\>icacls c:\test /setintegritylevel high

processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
    Mandatory Label\High Mandatory Level:(NW)

Successfully processed 1 files; Failed processing 0 files

Tenere presente che icacls.exe visualizza solo un'etichetta di integrità se per un oggetto ne è stata impostata una in modo esplicito. La maggior parte dei file non prevede l'impostazione esplicita di un'etichetta di integrità e pertanto è raro che si sia in grado di visualizzarne una.

Infine, icacls.exe è in grado di verificare se un oggetto contiene un ACL canonico. Come menzionato in precedenza, gli strumenti di terze parti inseriscono le voci ACE nell'ordine errato negli ACL. Icacls.exe è in grado di verificare e correggere questi tipi di problemi, come illustrato di seguito:

C:\>icacls c:\test /verify
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

Interfaccia utente degli ACL

L'interfaccia utente degli ACL è stata lievemente modificata rispetto a quella disponibile in Windows XP. Nelle figure 4 e 5 viene illustrata la finestra di dialogo dell'interfaccia utente degli ACL disponibile in Windows XP e Windows Vista, rispettivamente.

Figura 4 Finestra di dialogo dell'interfaccia utente degli ACL in Windows XP

Figura 4** Finestra di dialogo dell'interfaccia utente degli ACL in Windows XP **

Figura 5 Finestra di dialogo dell'interfaccia utente degli ACL in Windows Vista

Figura 5** Finestra di dialogo dell'interfaccia utente degli ACL in Windows Vista **

Come è possibile osservare, sono state apportate alcune modifiche. Primo, nella finestra di dialogo viene visualizzato in modo molto chiaro l'oggetto su cui si sta operando, il che può risultare utile se si utilizzano più oggetti contemporaneamente. Secondo, nella parte inferiore della finestra è presente un collegamento ipertestuale utilizzabile nel caso in cui si desideri ricevere assistenza. Tuttavia, la modifica più significativa sta nella rimozione dei pulsanti Aggiungi e Rimuovi che sono stati sostituiti con un pulsante Modifica che viene ampiamente utilizzato a supporto della funzionalità di controllo dell'account utente in Windows Vista. Come è possibile dedurre dalla presenza dell'icona di uno scudo sul pulsante, l'utente che ha avviato questa finestra di dialogo non dispone dell'autorizzazione per la modifica dell'ACL e pertanto sarà necessaria l'elevazione dei privilegi per poter modificare le autorizzazioni. Tenere presente che questa situazione non si verifica per impostazione predefinita se si crea una cartella nella directory radice dell'unità C: e si verificano immediatamente le proprietà. In quanto proprietario della cartella, si disporrebbe di autorizzazioni implicite per la modifica dell'ACL e l'icona dello scudo non verrebbe visualizzata. Lo scudo indica un moniker COM, un meccanismo utilizzato per avviare una richiesta di elevazione per una parte di un processo in esecuzione. Se si fa clic sul pulsante Modifica, viene visualizzata la nota finestra di dialogo per l'elevazione dei privilegi e se, in questa finestra, si fa clic su Continua verrà visualizzata una finestra di dialogo quasi identica a quella visualizzata in Windows XP facendo clic sul pulsante Aggiungi. L'interfaccia utente degli ACL segue questo modello che prevede la visualizzazione di due finestre di dialogo consecutive; viene visualizzata una finestra di dialogo fino a quando non si ottiene l'elevazione dei privilegi e, successivamente, viene visualizzata la nota finestra di dialogo disponibile nelle versioni precedenti di Windows.

Se si fa clic sul pulsante Avanzate e sulla scheda Controllo, viene sempre visualizzato un pulsante per l'elevazione dei privilegi, come illustrato nella Figura 6. Non è possibile modificare il controllo senza l'elevazione, anche se si dispone del controllo completo sull'oggetto e si è il proprietario dell'oggetto. Questo avviene in quanto la capacità di modificare il SACL di un oggetto è gestita dal privilegio SE_SECURITY_NAME, noto come "Gestione file registro di controllo e di protezione" negli strumenti dell'interfaccia utente grafica (GUI). Per impostazione predefinita, solo gli amministratori dispongono di tale diritto. Tuttavia, il privilegio viene rimosso da un amministratore in modalità Approvazione amministratore (quando il controllo dell'account utente è attivato), in quanto è necessaria l'elevazione anche se si è amministratore.

Figura 6 La modifica delle impostazioni di controllo in Windows Vista richiede sempre l'elevazione

Figura 6** La modifica delle impostazioni di controllo in Windows Vista richiede sempre l'elevazione **

Una considerazione finale sui requisiti di elevazione quando si modificano gli ACL: tutte queste istruzioni hanno carattere contingente se non si disattiva il controllo dell'account utente. Se si disattiva il controllo dell'account utente, si ripristineranno tutte le funzionalità disponibili in Windows XP, ad eccezione delle finestre di dialogo che hanno un aspetto differente. Tuttavia, non sarà necessaria alcuna elevazione, a condizione che si esegua l'accesso come amministratore, in quanto nel token ora sarà sempre presente il SID del gruppo Administrators.

Altri Strumenti

Icacls.exe è uno strumento molto utile e rappresenta un significativo miglioramento rispetto a cacls.exe, ma presenta alcuni punti deboli. Forse l'inconveniente più significativo è rappresentato dal fatto che non è in grado di gestire l'accesso a oggetti diversi da file e directory. In Windows Vista le modifiche apportate agli ACL di altri oggetti sono minime rispetto a Windows XP, tuttavia non mancano occasioni in cui si desidera gestire gli ACL in un servizio, in una chiave del Registro di sistema o anche in un oggetto Active Directory®.

Se si è avvezzi alla riga di comando, per eseguire questa operazione è necessario utilizzare lo strumento subinacl.exe. Subinacl.exe è incluso negli strumenti di supporto ed è anche disponibile come download.

È bene tuttavia tenere presente che subinacl.exe non è uno strumento facile da utilizzare. Infatti, in alcune situazioni risulta uno strumento senza dubbio poco intuitivo. Tuttavia, subinad.exe è uno strumento incredibilmente potente per la gestione del controllo dell'accesso. Ogni amministratore avanzato necessita di questo strumento.

ACL del Registro di sistema

Analogamente agli ACL del file system, anche negli ACL del Registro di sistema sono state introdotte alcune modifiche. Le modifiche introdotte tuttavia sono di minore entità rispetto a quelle apportate al file system. La differenza più ovvia rispetto alle versioni precedenti di Windows è rappresentata dalla rimozione di quasi tutte le voci ACE del gruppo Power Users, in quanto tale gruppo è stato dichiarato obsoleto. Gli utenti membri del gruppo Power Users dispongono ora degli stessi privilegi degli altri utenti. questo testimonia esattamente la complessità insita negli ACL, ma anche che non tutte le voci ACE per il gruppo Power Users sono state rimosse. Alcune, sfortunatamente, non vengono più utilizzate.

Esaminando gli ACL nel Registro di sistema, è possibile osservare che in alcuni punti è presente una voce ACE per un SID denominato RESTRIZIONI. Questo SID, sebbene non rappresenti una novità per Windows Vista, è molto interessante e poco conosciuto. Il SID RESTRIZIONI denota qualsiasi processo che presenta un token con restrizioni. Un token con restrizioni viene creato utilizzando una funzionalità speciale dell'API CreateRestrictedToken. Un token di questo tipo contiene uno o più SID con restrizioni, ovvero SID che vengono utilizzati in un controllo di accesso separato. Si supponga che un processo sia in esecuzione con un token con restrizioni. Se tale processo tenta di accedere a un oggetto con una voce ACE per il SID RESTRIZIONI, in Windows verranno eseguiti due controlli di accesso. Il primo è un normale controllo di accesso. Il secondo controllo funziona in modo identico al primo ma viene eseguito solo per i SID con restrizioni all'interno del token. È necessario superare entrambi i controlli di accesso.

Attualmente, diversi ACL utilizzano il SID RESTRIZIONI, in particolare nel Registro di sistema. Una schermata di un ACL di questo tipo viene mostrata nella Figura 7.

Figura 7 Gli ACL del Registro di sistema includono una voce ACE per il SID RESTRIZIONI in diversi punti

Figura 7** Gli ACL del Registro di sistema includono una voce ACE per il SID RESTRIZIONI in diversi punti **

Attualmente, pochi processi fanno uso della funzionalità token con restrizioni, in particolare per quanto riguarda i SID con restrizioni. Un esempio di processo che fa uso di questa funzionalità è il processo del servizio che ospita Windows Firewall, Base Filtering Engine e Servizio criteri di diagnostica. Utilizza inoltre un token con restrizioni in scrittura. In base alle mie scoperte, solo nove servizi utilizzano correntemente il SID RESTRIZIONI e i token con restrizioni in scrittura in Windows Vista.

Come con le versioni precedenti di Windows, la procedura consigliata in relazione alle autorizzazioni del Registro di sistema è quella di muoversi con estrema cautela. Modificare le autorizzazioni nel Registro di sistema solo in circostanze eccezionali. Dato il complesso modello di ereditarietà e considerate le operazioni sensibili eseguite nel Registro di sistema, esiste la probabilità piuttosto elevata che si verifichi un errore irreversibile se gli ACL nel Registro di sistema vengono modificati senza prestare particolare attenzione.

Riepilogo

Come con la maggior parte delle versioni di Windows, sono state apportate alcune sottili modifiche al controllo dell'accesso in Windows Vista. Tuttavia, a differenza di alcune delle altre versioni recenti, sono state introdotte molte modifiche di minore entità che determinano un significativo cambiamento del comportamento del sistema. Il controllo dell'account utente, in particolare, ha richiesto diverse modifiche, come le etichette di integrità e la modifica dell'interfaccia utente degli ACL. Inoltre, siamo di fronte al primo più importante processo di pulitura degli ACL della storia registrata.

Sotto molti aspetti, gli ACL predefiniti di Windows sono stati semplificati in Windows Vista, cosa mai accaduta in precedenza. Come con le versioni precedenti, tuttavia, è necessario muoversi con estrema nell'ambito del controllo dell'accesso fino a quando non se ne comprende a fondo il funzionamento. Questo vale in particolar modo per le nuove versioni del sistema operativo. È auspicabile che gli strumenti descritti nel presente articolo consentano di semplificare l'esplorazione dei concetti alla base degli ACL.

Jesper M. Johansson, Principal Security Engineer, si occupa dei problemi di protezione del software e collabora con TechNet Magazine come redattore. Detiene un titolo Ph.D in MIS e ha oltre 20 anni di esperienza in ambito di protezione dei computer. Questo articolo è adattato dal nuovo libro di Roger Grimes e Jesper Johansson, Windows Vista Security: Securing Vista Against Malicious Attacks (Wiley, 2007).

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