Protezione

Controllo dell'account utente di Windows Vista

Mark Russinovich

Panoramica:

• Esecuzione con privilegi utente standard
• Virtualizzazione del Registro di sistema e del file system
• Elevazione dei privilegi dello stato dell'account

Il controllo dell'account utente è una delle funzionalità meno apprezzate di Windows Vista. Nella mia serie in tre parti sulle modifiche al kernel di Windows Vista, pubblicata su TechNet Magazine e disponibile in linea all'indirizzo technetmagazine.com, non ho esaminato il controllo dell'account utente perché ho ritenuto che questo argomento meritasse un articolo a parte.

In questo articolo verranno illustrati i problemi che il controllo dell'account utente è in grado di risolvere e verranno descritte l'architettura e l'implementazione delle tecnologie su cui questa funzionalità si basa. Queste tecnologie includono il refactoring delle operazioni che in precedenza richiedeva diritti amministrativi, la virtualizzazione leggera per consentire la corretta esecuzione dei programmi senza diritti amministrativi, la capacità dei programmi di richiedere in modo esplicito i diritti amministrativi e l'isolamento dei processi amministrativi dai processi non amministrativi in esecuzione sul desktop dello stesso utente.

Scopo del controllo dell'account utente

Il controllo dell'account utente ha lo scopo di consentire agli utenti di utilizzare diritti utente standard anziché diritti amministrativi. I diritti amministrativi consentono agli utenti di leggere e modificare qualsiasi parte del sistema operativo, compresi il codice e i dati di altri utenti, e persino lo stesso sistema Windows ®. Senza i diritti amministrativi gli utenti non possono accidentalmente (o deliberatamente) modificare le impostazioni di sistema né compromettere le informazioni riservate di altri utenti su computer condivisi e i malware non sono in grado di alterare le impostazioni di protezione del sistema o disattivare il software antivirus. L'esecuzione di applicazioni con i diritti utente standard può pertanto consentire di ridurre le chiamate urgenti al supporto tecnico negli ambienti aziendali, limitare l'impatto del malware, garantire un funzionamento costante dei computer domestici e proteggere i dati riservati sui computer condivisi.

Per rendere possibile l'esecuzione con un account utente standard, il controllo dell'account utente ha dovuto risolvere numerosi problemi. Innanzitutto, prima del rilascio di Windows Vista™, il modello di utilizzo di Windows è stato considerato uno dei presunti diritti amministrativi. Gli sviluppatori di software presupponevano che i relativi programmi potevano accedere e modificare qualsiasi impostazione relativa a file, chiavi del Registro di sistema o sistema operativo. Anche quando in Windows NT® sono stati introdotti meccanismi di protezione e impostazioni che consentivano di distinguere tra accessi concessi ad account utente standard e amministrativi, gli utenti venivano guidati attraverso un processo di installazione che li incoraggiava a utilizzare l'account amministrativo incorporato o un account membro del gruppo Administrators.

Il secondo problema che il controllo dell'account utente ha dovuto affrontare è rappresentato dal fatto che gli utenti necessitano talvolta di diritti amministrativi per eseguire operazioni comuni, come installazione di software, modifica dell'ora di sistema e apertura di porte nel firewall.

La soluzione del controllo dell'account utente a questi problemi consiste nella possibilità di eseguire la maggior parte delle applicazioni con diritti utente standard e di evitare l'uso di diritti amministrativi per qualsiasi tipo di operazione nonché nell'incoraggiare gli sviluppatori di software a creare applicazioni che possono essere eseguite con diritti utente standard. Il controllo dell'account utente consente di realizzare questi obiettivi fornendo la possibilità di richiedere con minore frequenza i diritti amministrativi, consentendo l'esecuzione delle applicazioni legacy con diritti utente standard, semplificando l'accesso degli utenti standard ai diritti amministrativi quando sono necessari e consentendo persino agli utenti con privilegi amministrativi di eseguire le applicazioni come utenti standard.

Esecuzione con privilegi utente standard

Un controllo completo di tutte le operazioni amministrative durante lo sviluppo di Windows Vista ha consentito di identificare molte delle attività che potrebbero essere consentite agli utenti standard senza compromettere la protezione del sistema. Ad esempio, anche le aziende che hanno adottato account utente standard per i relativi sistemi desktop Windows XP non possono rimuovere gli utenti che viaggiano di frequente dal gruppo Administrators unicamente perché Windows XP non prevede alcuna differenziazione tra la modifica del fuso orario e la modifica dell'ora di sistema. Gli utenti di computer portatili che desiderino configurare il fuso orario locale in modo che i relativi appuntamenti vengano visualizzati correttamente nel calendario durante un viaggio devono disporre del privilegio "Modifica dell'orario di sistema" (definito internamente SeSystemTimePrivilege) che, per impostazione predefinita, è concesso solo agli amministratori.

L'orario viene comunemente utilizzato nei protocolli di protezione, come Kerberos, ma il fuso orario influisce solo sulla modalità di visualizzazione dell'orario e, pertanto, Windows Vista prevede l'aggiunta di un nuovo privilegio, "Modifica del fuso orario" (SeTimeZonePrivilege), che viene assegnato al gruppo Users, come illustrato nella Figura 1. In tal modo, gli utenti di computer portatili in molte aziende hanno la possibilità di eseguire le applicazioni con account utente standard.

Figura 1** Privilegio “Modifica del fuso orario” **(Fare clic sull'immagine per ingrandirla)

Windows Vista consente inoltre agli utenti standard di configurare le impostazioni WEP quando si connettono alle reti wireless, creare connessioni VPN, modificare le impostazioni di risparmio energia e installare gli aggiornamenti critici di Windows. Inoltre, questo sistema operativo fornisce le impostazioni dei Criteri di gruppo che consentono agli utenti standard di installare i driver della stampante e di altri dispositivi approvati dagli amministratori IT nonché installare i controlli ActiveX® dai siti approvati dagli amministratori.

E per quanto riguarda le applicazioni consumer e line of business (LOB) che non vengono eseguite correttamente con gli account utente standard? Sebbene alcune applicazioni software richiedano legittimamente diritti amministrativi, molti programmi memorizzano inutilmente i dati degli utenti in aree globali di sistema. Microsoft consiglia che i programmi di installazione di applicazioni globali che prevedono l'esecuzione con diritti amministrativi creino una directory all'interno della directory %Programmi% in cui memorizzare i file eseguibili e i dati ausiliari delle relative applicazioni e creino una chiave in HKEY_LOCAL_MACHINE\Software per le impostazioni delle relative applicazioni. È possibile che un'applicazione venga eseguita con account utente differenti e pertanto è consigliabile che memorizzi i dati specifici degli utenti nella directory %AppData% per utente e salvi le impostazioni per utente nel profilo del Registro di sistema dell'utente in HKEY_CURRENT_USER\ Software. Gli account utente standard non dispongono dell'accesso in scrittura alla directory %Programmi% o alla chiave HKEY_LOCAL_MACHINE\Software ma, poiché la maggior parte dei sistemi Windows viene eseguita in modalità utente singolo e la maggior parte degli utenti ha usufruito di privilegi di amministratore fino al rilascio di Windows Vista, le applicazioni che non salvano in modo corretto le impostazioni e i dati specifici degli utenti in tali posizioni continuano a funzionare comunque.

Windows Vista consente l'esecuzione di queste applicazioni legacy con account utente standard grazie alla virtualizzazione dello spazio dei nomi del file system e del Registro di sistema. Quando un'applicazione modifica un'area globale di sistema nel file system o nel Registro di sistema e questa operazione non riesce perché l'accesso viene negato, Windows reindirizza l'operazione a un'area per utente; quando l'applicazione esegue la lettura da un'area globale di sistema, Windows verifica prima la presenza di dati nell'area per utente e, se questi non sono presenti, consente di eseguire la lettura dall'area globale.

Ai fini della virtualizzazione, Windows Vista considera un processo come legacy se è un processo a 32 bit anziché a 64 bit, non viene eseguito con diritti amministrativi e non include un file manifesto che indica che è stato scritto per Windows Vista. In base a questa definizione, qualsiasi operazione che non ha origine da un processo classificato come legacy, compresi gli accessi alle condivisioni di file di rete, non è virtualizzata. Lo stato della virtualizzazione di un processo viene memorizzato come flag nel relativo token, che rappresenta la struttura di dati del kernel che tiene traccia del contesto di protezione di un processo, inclusi il relativo account utente, le appartenenze ai gruppi e i privilegi.

È possibile visualizzare lo stato della virtualizzazione di un processo aggiungendo la colonna Virtualizzazione alla pagina Processi di Gestione attività. Nella Figura 2 viene indicato che per la maggior parte dei componenti di Windows Vista, tra cui Gestione finestre desktop (Dwm.exe), Client Server Runtime Subsystem (Csrss.exe) ed Esplora risorse, la virtualizzazione è disattivata in quanto tali componenti contengono un file manifesto di Windows Vista o vengono eseguiti con diritti amministrativi e pertanto non consentono la virtualizzazione. Per Internet Explorer® (iexplore.exe) la virtualizzazione è attivata in quanto questa applicazione è in grado di ospitare più script e controlli ActiveX e deve presumere che questi elementi non sono stati scritti per funzionare in modo corretto con diritti utente standard.

Figura 2** Stato della virtualizzazione visualizzato in Gestione attività **(Fare clic sull'immagine per ingrandirla)

Le posizioni del file system che vengono virtualizzate per i processi legacy sono %Programmi%, %ProgramData% e %SystemRoot%, escluse alcune sottodirectory specifiche. Tuttavia, tutti i file con estensioni di eseguibili, tra cui .exe, .bat, .scr, .vbs e altri, sono esclusi dalla virtualizzazione. Ne consegue che i programmi che si aggiornano automaticamente da un account utente standard non vengono eseguiti correttamente anziché creare versioni private dei relativi eseguibili non visibili a un amministratore che esegue un programma di aggiornamento globale. Per aggiungere ulteriori estensioni all'elenco delle eccezioni, inserirle nella seguente chiave del Registro di sistema ed eseguire il riavvio:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Luafv\Parameters\ExcludedExtensionsAdd 

Utilizzare un tipo multistringa per delimitare più estensioni e non includere alcun punto prima del nome dell'estensione.

Le modifiche alle directory virtualizzate dai processi legacy vengono reindirizzate alla directory radice virtuale dell'utente, %LocalAppData%\VirtualStore. Se, ad esempio, un processo virtualizzato in esecuzione sul mio sistema crea C:\Windows\Application.ini, il file effettivamente creato è C:\Users\Markruss\AppData\Local\VirtualStore\Windows\Application.ini. Il componente locale del percorso evidenzia il fatto che i file virtualizzati non vengono spostati con il resto del profilo quando l'account prevede un profilo mobile.

Se in Esplora risorse si accede a una directory contenente file virtualizzati, sulla barra degli strumenti di Esplora risorse viene visualizzato il pulsante File compatibilità, come illustrato nella Figura 3. Questo pulsante consente di accedere alla sottodirectory VirtualStore corrispondente per visualizzare i file virtualizzati.

Figura 3** Il pulsante File compatibilità indica i file virtualizzati **(Fare clic sull'immagine per ingrandirla)

Nella Figura 4 viene illustrata l'implementazione della virtualizzazione del file system tramite Driver filtro virtualizzazione file LUA (%SystemRoot%\System32\Drivers\Luafv.sys). Essendo un driver di filtro del file system, questo driver è in grado di visualizzare tutte le operazioni del file system ma implementa solo le funzionalità per le operazioni dei processi legacy. È possibile osservare che questo driver modifica il percorso del file di destinazione per un processo legacy che crea un file in un'area globale di sistema ma non per un processo che esegue un'applicazione di Windows Vista con diritti utente standard. Dal punto di vista del processo legacy, l'operazione riesce quando il file viene creato in una posizione completamente accessibile dall'utente, ma le autorizzazioni predefinite per la directory \Windows negano l'accesso all'applicazione scritta per Windows Vista.

Figura 4** Virtualizzazione del file system **

La virtualizzazione del Registro di sistema viene implementata in modo leggermente diverso rispetto alla virtualizzazione del file system. Le chiavi del Registro di sistema virtualizzate includono la maggior parte del ramo HKEY_LOCAL_MACHINE\Software, ma vi sono numerose eccezioni, tra cui:

HKLM\Software\Microsoft\Windows
HKLM\Software\Microsoft\Windows NT
HKLM\Software\Classes 

Solo le chiavi che vengono comunemente modificate da applicazioni legacy, ma che non introducono problemi di compatibilità o interoperabilità, vengono virtualizzate. Windows reindirizza le modifiche delle chiavi virtualizzate da un'applicazione legacy alla chiave radice virtuale del Registro di sistema di un utente in HKEY_ CURRENT_USER\Software\Classes\VirtualStore. La chiave risiede nell'hive Classes dell'utente, %LocalAppData%\Microsoft\Windows\UsrClass.dat, di cui, analogamente a tutti gli altri dati dei file virtualizzati, non viene eseguito il roaming con un profilo utente mobile.

Anziché mantenere un elenco fisso di posizioni virtualizzate, come avviene in windows per il file system, lo stato della virtualizzazione di una chiave viene archiviato come flag, REG_ KEY_DONT_VIRTUALIZE, nella chiave stessa. L'utilità Reg.exe consente di visualizzare questo flag e gli altri due flag correlati alla virtualizzazione, REG_KEY_ DONT_SILENT_FAIL e REG_KEY_ RECURSE_FLAG, come illustrato nella Figura 5. Quando si imposta REG_KEY_DONT_SILENT_FAIL e la chiave non viene virtualizzata (è impostato il flag REG_KEY_DONT_VIRTUALIZE), a un'applicazione legacy, a cui verrebbe negato l'accesso all'esecuzione di un'operazione sulla chiave, viene invece concesso qualsiasi tipo di accesso di cui l'utente dispone alla chiave anziché l'accesso richiesto dall'applicazione. REG_KEY_RECURSE_FLAG indica se le nuove sottochiavi ereditano dai flag di virtualizzazione del padre anziché solo dai flag predefiniti.

Figura 5** Flag di virtualizzazione visualizzati nell'utilità Reg **(Fare clic sull'immagine per ingrandirla)

Nella Figura 6 viene illustrata l'implementazione della virtualizzazione del Registro di sistema mediante Gestione configurazione, che gestisce il Registro di sistema nel kernel del sistema operativo, Ntoskrnl.exe. Come con la virtualizzazione del file system, un processo legacy che crea una sottochiave di una chiave virtualizzata viene reindirizzato alla chiave radice del Registro di sistema dell'utente, ma a un processo di Windows Vista viene negato l'accesso dalle autorizzazioni predefinite.

Oltre alla virtualizzazione del file system e del Registro di sistema, alcune applicazioni richiedono l'implementazione di ulteriori meccanismi in grado di garantirne la corretta esecuzione con diritti utente standard. Ad esempio, un'applicazione che verifica se l'account con cui viene eseguita appartiene al gruppo Administrators potrebbe in altri casi funzionare, ma non sarà possibile eseguirla se non appartiene a tale gruppo. Windows Vista definisce quindi una serie di correzioni rapide per la compatibilità tra le applicazioni in modo che tali applicazioni siano in grado di funzionare indipendentemente dall'appartenenza al gruppo in questione. Le correzioni rapide per la compatibilità applicate più comunemente alle applicazioni legacy per consentirne il corretto funzionamento con i diritti utente standard vengono illustrate nella Figura 7. I professionisti IT aziendali possono utilizzare strumenti come Application Compatibility Toolkit (ACT), disponibile all'indirizzo technet.microsoft.com/windowsvista/aa905066.aspx, e la relativa utilità Standard User Analyzer (SUA) o lo strumento LUA Buglight di Aaron Margosis per identificare i requisiti delle correzioni rapide per la compatibilità per le relative applicazioni LOB. Gli sviluppatori assegnano le correzioni rapide per la compatibilità a un'applicazione utilizzando lo strumento Compatibility Administrator, che fa parte di ACT, e distribuiscono il database di compatibilità risultante (file .sdb) sui relativi desktop tramite Criteri di gruppo. Tenere presente che, se necessario, la virtualizzazione può essere completamente disattivata per un sistema mediante un'impostazione dei criteri di protezione locali.

Figure 7 Correzioni rapide per la compatibilità per gli utenti comuni

Effetti della virtualizzazione

È possibile modificare lo stato della virtualizzazione di un processo selezionando Virtualizzazione dal menu di scelta rapida che viene visualizzato quando si fa clic con il pulsante destro del mouse su di esso in Gestione attività. Nella Figura A viene illustrato il comportamento di un prompt dei comandi quando il relativo stato di virtualizzazione viene modificato. La virtualizzazione risulta inizialmente disattivata in quanto il prompt dei comandi include un manifesto di Windows Vista. Poiché viene eseguito con diritti utente standard, il prompt dei comandi non è in grado di creare un file nella directory \Windows, ma dopo essere stato virtualizzato con Gestione attività, riesce a creare il file in modo corretto. Quando la virtualizzazione ritorna allo stato disattivato, il prompt dei comandi non è in grado di trovare il file, che risiede in realtà nell'archivio virtuale dell'utente.

Figura A** Modifica dello stato della virtualizzazione **(Fare clic sull'immagine per ingrandirla)

Modalità Approvazione amministratore

Anche se gli utenti eseguono solo programmi compatibili con i diritti utente standard, alcune operazioni richiedono tuttavia i diritti amministrativi. La maggior parte delle installazioni software richiede diritti amministrativi per la creazione di directory e chiavi del Registro di sistema in aree globali di sistema o per l'installazione di servizi o di driver di dispositivo. Anche la modifica delle impostazioni globali di sistema per Windows e le applicazioni richiede diritti amministrativi, così come la funzionalità controllo genitori di Windows Vista. Sarebbe possibile eseguire la maggior parte di queste operazioni passando a un account amministratore dedicato, ma lo svantaggio di questo approccio sta nella necessità per la maggior parte degli utenti di continuare a utilizzare l'account amministrativo per l'esecuzione delle relative attività quotidiane.

Windows Vista include pertanto la funzionalità avanzata "Esegui come" in modo da consentire agli utenti standard di avviare determinati processi con diritti amministrativi. Questa funzionalità ha richiesto l'implementazione nelle applicazioni di un metodo che consentisse di identificare le operazioni per cui il sistema può ottenere i diritti amministrativi per conto dell'applicazione, in base alle esigenze, argomento che illustrerò tra poco.

Inoltre, per consentire agli utenti che agiscono come amministratori di sistema di utilizzare diritti utente standard, ma senza dover inserire i nomi utente e le password ogni volta che desiderano accedere ai diritti amministrativi, Windows Vista fornisce la modalità Approvazione amministratore (AAM, Admin Approval Mode). Questa funzionalità crea due identità per l'utente all'accesso: una con diritti utente standard e un'altra con diritti amministrativi. Poiché ogni utente di un sistema Windows Vista è un utente standard o per la maggior parte dei casi dispone dei privilegi di esecuzione come utente standard in modalità Approvazione amministratore, gli sviluppatori devono presumere che tutti gli utenti di Windows siano utenti standard, il che determinerà una situazione in cui più applicazioni saranno in grado di funzionare con i diritti utente standard senza virtualizzazione o correzioni rapide per la compatibilità.

L'atto di conferire a un processo diritti amministrativi viene definito elevazione. Quando l'elevazione viene eseguita da un account utente standard, viene definita elevazione OTS (Over the Shoulder) in quanto richiede l'immissione di credenziali per un account membro del gruppo Administrators, un'operazione che in genere viene completata da un altro utente che digita le informazioni "sopra la spalla" dell'utente standard. Un'elevazione eseguita da un utente in modalità Approvazione amministratore viene denominata elevazione di consenso perché l'utente deve approvare semplicemente l'assegnazione dei relativi diritti amministrativi.

In Windows Vista un utente viene considerato amministratore se è membro di uno dei gruppi di amministratori elencati nella Figura 8. Molti dei gruppi elencati vengono utilizzati solo in sistemi appartenenti a un dominio e non assegnano direttamente agli utenti diritti amministrativi locali, ma consentono loro di modificare le impostazioni a livello di dominio. Se un utente è membro di uno di questi gruppi, ma non fa parte del gruppo Administrators effettivo, l'utente potrà accedere ai relativi diritti amministrativi tramite elevazioni OTS anziché elevazioni di consenso.

Figure 8 Gruppi amministrativi

Quando un utente appartenente a uno dei gruppi elencati esegue l'accesso, in Windows Vista viene creato un token che rappresenta la versione utente standard dell'identità amministrativa dell'utente. Il nuovo token viene privato di tutti i privilegi assegnati all'utente, eccetto quelli elencati nella Figura 9, che rappresentano i privilegi dell'utente standard predefiniti. Inoltre, tutti i gruppi di amministratori sono contrassegnati con il flag USE_FOR_DENY_ONLY nel nuovo token. Nella Figura 10 viene illustrata l'utilità Process Explorer di Sysinternals (uno strumento di gestione dei processi che è possibile scaricare da microsoft.com/technet/sysinternals) in cui vengono visualizzate le appartenenze ai gruppi e i privilegi di un processo eseguito con diritti amministrazioni nella parte sinistra e senza diritti amministrativi nella parte destra. Per impedirne l'utilizzo involontario, il modello di protezione di Windows richiede che un privilegio con il flag disattivato venga attivato prima di poter essere utilizzato.

Figure 9 Privilegi utente standard

Figura 10** Token per l'utente standard e l'amministratore in modalità Approvazione amministratore **(Fare clic sull'immagine per ingrandirla)

Un gruppo con il flag di sola negazione può essere utilizzato solo per negare l'accesso dell'utente a una risorsa, mai per consentire tale accesso, chiudendo un punto di vulnerabilità che potrebbe essere creato se il gruppo venisse rimosso completamente. Se, ad esempio, un file contenesse un elenco di controllo di accesso (ACL, Access Control List) che negasse al gruppo Administrators qualsiasi tipo di accesso, ma concedesse determinati tipi di accessi a un altro gruppo a cui l'utente appartiene, all'utente verrebbe concesso l'accesso se il gruppo Administrators fosse assente dal token, concedendo alla versione utente standard dell'identità dell'utente un numero di accessi maggiore rispetto alla relativa identità amministrativa.

I sistemi autonomi, che sono in genere rappresentati dai computer di casa, e i sistemi appartenenti a un dominio gestiscono l'accesso in modalità Approvazione amministratore da parte degli utenti remoti in modo differente in quanto i computer connessi a un dominio possono utilizzare gruppi amministrativi di dominio nelle relative autorizzazioni per le risorse. Quando un utente accede a una condivisione file di un computer autonomo, Windows richiede l'identità utente standard dell'utente remoto, mentre in sistemi appartenenti a un dominio Windows rispetta tutte le appartenenze ai gruppi di dominio dell'utente richiedendo l'identità amministrativa dell'utente.

Accesso semplificato ai diritti amministrativi

Esistono diversi metodi con cui il sistema e le applicazioni identificano la necessità di diritti amministrativi. Un metodo che viene visualizzato nell'interfaccia utente di Esplora risorse è rappresentato dall'opzione di scelta rapida e dalla voce del menu di scelta rapida "Esegui come amministratore". Questi elementi contengono l'icona di uno scudo colorato che deve essere posizionata su qualsiasi pulsante o voce di menu che determini un'elevazione di diritti qualora venga selezionata. Se si seleziona "Esegui come amministratore", in Esplora risorse, verrà chiamata l'API ShellExecute con il verb "runas".

Poiché la maggior parte dei programmi di installazione richiede diritti amministrativi, il caricatore di immagini, responsabile dell'avvio iniziale di un eseguibile, include il codice di rilevamento del programma di installazione per identificare gli eventuali programmi di installazione legacy. Alcuni dei sistemi euristici che utilizza sono piuttosto semplici, in quanto vengono impiegati semplicemente per verificare se l'immagine contiene le parole impostazione, installazione o aggiornamento nel relativo nome di file o nelle informazioni interne sulla versione; altri sono più sofisticati in quanto prevedono l'analisi delle sequenze di byte nell'eseguibile che sono comuni alle utilità wrapper di installazione di terze parti.

Il caricatore di immagini chiama inoltre la libreria di compatibilità tra applicazioni (appcompat) per verificare se l'eseguibile di destinazione richiede diritti amministrativi. La libreria controlla il database di compatibilità tra applicazioni per verificare se all'eseguibile è associato il flag di compatibilità RequireAdministrator o RunAsInvoker.

Il metodo più comune con cui un eseguibile può richiedere diritti amministrativi è includere un tag requestedElevationLevel nel relativo file manifesto dell'applicazione. I manifesti sono file XML che contengono informazioni aggiuntive su un'immagine. Questi file sono stati introdotti in Windows XP per identificare eventuali dipendenze dagli assembly DLL in modalità affiancata o dagli assembly di Microsoft .NET Framework. La presenza dell'elemento trustInfo in un manifesto (che è possibile notare nel dump di stringa estratto da Firewallsettings.exe e riportato di seguito) denota un eseguibile scritto per Windows Vista in cui è nidificato l'elemento requestedElevationLevel. L'attributo relativo al livello dell'elemento può avere uno dei tre valori seguenti: asInvoker, highestAvailable e requireAdministrator.

<trustInfo 
 xmlns=”urn:schema-microsoft-com:asm.v3”>
 <security>
  <requestedPrivileges>
   <requestedExecutionLevel
    Level=”requireAdministrator”
    uiAccess=”false”/>
  </requestedPrivileges>
 </security>
</trustInfo>

Gli eseguibili che non richiedono diritti amministrativi, come Notepad.exe, specificano il valore asInvoker. Alcuni eseguibili partono dal presupposto che gli amministratori desiderino sempre il massimo livello di accesso e pertanto utilizzano il valore highestAvailable. A un utente che esegue un eseguibile con tale valore verrà richiesta l'elevazione dei privilegi solo se l'utente utilizza la modalità Approvazione amministratore o se viene considerato un amministratore in base alle regole definite in precedenza e pertanto deve assumere privilegi più elevati per accedere ai relativi diritti amministrativi. Regedit.exe, Mmc.exe ed Eventvwr.exe sono esempi di applicazioni che utilizzano il valore highestAvailable. Infine, requireAdministrator determina sempre una richiesta di elevazione e viene utilizzato da qualsiasi eseguibile che non è in grado di funzionare senza diritti amministrativi.

Le applicazioni di accessibilità specificano "true" per l'attributo uiAccess in modo da pilotare l'input della finestra dei processi con privilegi elevati e, per ottenere questo diritto, è necessario inoltre che tali applicazioni siano firmate e risiedano in una delle diverse posizioni protette, tra cui %SystemRoot% e %Programmi%.

Un metodo semplice per determinare i valori specificati da un eseguibile consiste nel visualizzare il relativo manifesto con l'utilità Sigcheck di Sysinternals, come illustrato di seguito:

sigcheck –m <executable> 

L'esecuzione di un'immagine che richiede diritti amministrativi determina l'avvio di Consent.exe (%SystemRoot%\System32\Consent.exe) nel servizio Applicazioni informazioni (AIS, Application Information Service), contenuto in %SystemRoot%\System32\Appinfo.dll, che viene eseguito all'interno di un processo Host servizio (%SystemRoot%\System32\Svchost.exe). Consent acquisisce un'immagine bitmap dello schermo, vi applica un effetto di dissolvenza, passa a un desktop accessibile solo all'account di sistema locale, imposta l'immagine bitmap come sfondo e visualizza una finestra di dialogo per l'elevazione dei privilegi che contiene informazioni sull'eseguibile. La visualizzazione di un desktop separato impedisce a qualsiasi malware presente nell'account dell'utente di modificare l'aspetto della finestra di dialogo.

Figura 11** Finestre di dialogo per l'elevazione OTS **(Fare clic sull'immagine per ingrandirla)

Se un'immagine è un componente di Windows che ha la firma digitale di Microsoft e l'immagine risiede nella directory di sistema di Windows, nella parte superiore della finestra di dialogo verrà visualizzata una striscia blu, come illustrato nella parte superiore della Figura 11. La striscia grigia (finestra di dialogo centrale) è relativa alle immagini che hanno la firma digitale di società diverse da Microsoft e la striscia arancione (finestra di dialogo inferiore) è relativa alle immagini prive di firma. Nella finestra di dialogo per l'elevazione dei privilegi vengono visualizzati l'icona, la descrizione e l'autore per le immagini con firma digitale, ma solo un'icona generica, il nome file e il messaggio "Autore non identificato" per le immagini prive di firma. Questo rende più difficoltoso per il malware imitare l'aspetto del software autorizzato. Il pulsante Dettagli nella parte inferiore della finestra di dialogo si espande per mostrare la riga di comando che verrà passata all'eseguibile nel caso in cui venga avviato. La finestra di dialogo relativa all'elevazione di consenso in modalità Approvazione amministrazione, illustrata nella Figura 12, è simile, ma anziché richiedere l'immissione di credenziali amministrative include i pulsanti Continua e Annulla.

Figura 12** Finestra di dialogo per l'elevazione in modalità Approvazione amministratore **(Fare clic sull'immagine per ingrandirla)

Se un utente rifiuta un'elevazione di privilegi, in Windows verrà restituito un errore di accesso negato al processo che ha eseguito l'avvio. Quando un utente accetta un'elevazione di privilegi immettendo le credenziali di amministratore o facendo clic sul pulsante Continua, AIS chiama CreateProcessAsUser per avviare il processo con l'identità amministrativa appropriata. Sebbene AIS sia, dal punto di vista tecnico, il padre del processo con privilegi elevati, questo servizio utilizza la nuova funzionalità dell'API CreateProcessAsUser che consente di impostare l'ID processo padre del processo su quello del processo da cui è stato originariamente avviato (vedere la Figura 13). Per questo motivo, i processi con privilegi elevati non vengono visualizzati come elementi figlio del processo Host servizio di AIS in strumenti come Process Explorer, in cui vengono visualizzati gli alberi dei processi.

Figura 13** Flusso del processo di elevazione dei privilegi **

Anche se le finestre di dialogo per l'elevazione dei privilegi vengono visualizzate su un desktop protetto separato, per impostazione predefinita, gli utenti non dispongono di alcun metodo per verificare che la finestra di dialogo visualizzata sia legittima e non presentata dal malware. Questo non rappresenta un problema per la modalità Approvazione amministratore in quanto il malware non può ottenere diritti amministrativi con una finestra di dialogo di consenso non legittima. Tuttavia, il malware potrebbe attendere una richiesta di elevazione OTS di un utente standard, intercettarla e utilizzare una finestra di dialogo trojan horse per acquisire le credenziali di amministratore. Con tali credenziali i malware possono ottenere l'accesso all'account dell'amministratore e infettarlo.

Per questa ragione, non è consigliabile utilizzare le elevazioni OTS negli ambienti aziendali. Per disattivare le elevazioni OTS (e ridurre le chiamate al supporto tecnico), eseguire l'editor dei criteri di protezione locali (Secpol.msc) e configurare "Controllo account utente: comportamento della richiesta di elevazione dei privilegi per utenti standard" su "Nega automaticamente richieste di esecuzione con privilegi elevati".

Gli utenti privati che sono consapevoli dei problemi relativi alla protezione devono configurare le elevazioni OTS per richiedere una Secure Attention Sequence (SAS) che il malware non è in grado di intercettare o simulare. Per configurare SAS, eseguire l'Editor criteri di gruppo (Gpedit.msc), accedere a Configurazione computer | Modelli amministrativi | Componenti di Windows | Interfaccia utente delle credenziali e attivare "Richiedi percorso trusted per immissione credenziali". Una volta eseguite queste operazioni, verrà chiesto di premere la combinazione di tasti Ctrl + Alt + Canc per accedere alla finestra dialogo per l'elevazione dei privilegi.

Isolamento dei Processi con privilegi elevati

Windows Vista colloca una barriera intorno ai processi con privilegi elevati per proteggerli da programmi malware eseguiti sullo stesso desktop con diritti utente standard. Senza una barriera di protezione, il malware potrebbe gestire un'applicazione amministrativa inviando a tale applicazione input sintetizzati di mouse e finestra tramite messaggi finestra. Sebbene il modello di protezione di Windows standard impedisca al malware in esecuzione in un processo con diritti utente standard di compromettere un processo con diritti elevati eseguito come utente differente, non impedisce tuttavia al malware eseguito come versione diritti standard di un utente amministrativo di aprire i processi con privilegi elevati dell'utente, inserire del codice in questi processi e avviare i thread dei processi per eseguire il codice inserito.

Il meccanismo di protezione di Windows Vista per i messaggi finestra è definito User Interface Privilege Isolation (UIPI). Questa funzionalità è basata sul nuovo meccanismo di integrità di Windows che Windows Vista utilizza come la barriera di protezione per i processi con privilegi elevati. In questo nuovo modello di protezione, tutti i processi e gli oggetti hanno livelli di integrità e il criterio di integrità di un oggetto può limitare gli accessi che sarebbero altrimenti concessi a un processo dal modello di protezione DAC (Discretionary Access Control, controllo di accesso discrezionale) di Windows.

I livelli di integrità (IL) vengono rappresentati dagli identificatori di protezione (SID), che rappresentano anche gli utenti e i gruppi, dove il livello viene codificato nell'identificatore relativo (RID) del SID. Nella Figura 14 vengono illustrati il nome visualizzato, il SID e la versione esadecimale del RID del SID per i quattro livelli di integrità principali. I numeri esadecimali mostrano una distanza di 0x1000 tra ciascun livello che consente l'utilizzo dei livelli intermedi da parte delle applicazioni di accessibilità dell'interfaccia utente oltre che un'espansione futura.

Figure 14 Livelli di integrità principali

Nella Figura 15 vengono illustrati i criteri dei livelli di integrità degli oggetti e i tipi di accesso su cui tali criteri impongono limitazioni, che corrispondono agli accessi generici definiti per un oggetto. Ad esempio, No-Write-Up impedisce a un processo con livello di integrità inferiore di ottenere gli accessi rappresentati dagli accessi di tipo GENERIC_WRITE. Il criterio predefinito per la maggior parte degli oggetti, inclusi file e chiavi del Registro di sistema, è No-Write-Up, che impedisce a un processo di ottenere l'accesso in scrittura a oggetti con un livello di integrità superiore, anche se l'elenco di controllo di accesso discrezionale (DACL) dell'oggetto concede all'utente questo tipo di accesso. Gli unici oggetti con un criterio differente sono gli oggetti processo e thread. I relativi criteri, No-Write-Up e No-Read-Up, impediscono a un processo eseguito con un livello di integrità inferiore di inserire codice ed eseguire la lettura di dati, ad esempio le password, da un processo con un livello di integrità più alto.

Figure 15 Criteri dei livelli di integrità

Windows assegna a ogni processo un livello di integrità che colloca nel token del processo insieme ai SID dei gruppi a cui l'utente che esegue il processo appartiene. Nella Figura 16 vengono elencati esempi di processi assegnati a livelli di integrità differenti. I processi ereditano in genere il livello di integrità del relativo padre, ma un processo può anche avviare un altro processo con un livello di integrità differente, come avviene in AIS quando avvia un processo con privilegi elevati. È possibile visualizzare i livelli di integrità del processo con l'utilità Whoami incorporata specificando l'opzione /all oppure con l'utilità Process Explorer o AccessChk di Sysinternals. Process Explorer consente di visualizzare i livelli di integrità dei processi con l'aggiunta della colonna relativa al livello di integrità.

Figure 16 Assegnazione di livelli di integrità a processi di esempio

Ogni oggetto a protezione diretta ha un livello di integrità esplicito o implicito. Agli oggetti processo, thread e token è sempre assegnato un livello di integrità esplicito che in genere è identico al livello di integrità memorizzato nel token del processo corrispondente. Alla maggior parte degli oggetti è assegnato un livello di integrità esplicito e pertanto gli oggetti vengono impostati automaticamente su un livello di integrità medio. Gli unici oggetti creati con un livello di integrità diverso da quello medio sono gli oggetti creati da un processo eseguito al livello di integrità basso e a cui è pertanto assegnato un livello di integrità basso. È possibile utilizzare lo strumento iCacls incorporato (%SystemRoot%\System32\iCacls.exe) per visualizzare i livelli di integrità dei file e l'utilità AccessChk di Sysinternals per visualizzare i livelli di integrità di file, chiavi del Registro di sistema, servizi e processi. Nella Figura 17 viene mostrato che una directory a cui è necessario accedere dalla modalità protetta di Internet Explorer ha un livello di integrità basso.

Figura 17** Utilità AccessChk in cui viene visualizzato il livello di integrità della directory Preferiti di un utente **(Fare clic sull'immagine per ingrandirla)

Se un oggetto ha un livello di integrità esplicito, viene memorizzato in una voce di controllo di accesso (ACE) di un nuovo tipo di Windows Vista, Label ACE, nell'elenco di controllo di accesso di sistema (SACL) del descrittore di protezione dell'oggetto (vedere la Figura 18). Il SID nella voce ACE corrisponde al livello di integrità dell'oggetto e i flag della voce ACE codificano i criteri di integrità dell'oggetto. Prima di Windows Vista, negli elenchi di controllo di accesso di sistema venivano memorizzati solo le voci di controllo di accesso di controllo che richiedono il privilegio "Gestione file registro di controllo e di protezione" (SeSecurityPrivilege), ma la lettura di un tipo Label ACE richiede solo l'accesso Autorizzazioni di lettura (READ_CONTROL). Perché un processo possa modificare il livello di integrità di un oggetto è necessario che disponga dell'accesso Modifica proprietario in (WRITE_OWNER) all'oggetto e un livello di integrità uguale o più alto di quello dell'oggetto; il processo inoltre può impostare solo un livello di integrità uguale o inferiore a quello ad esso assegnato. Il nuovo privilegio"Modifica delle etichette di oggetti" (SeRelabelPrivilege) consente a un processo di modificare il livello di integrità di qualsiasi oggetto a cui il processo ha accesso e anche di impostare il livello di integrità su un valore superiore al livello di integrità ad esso assegnato; tuttavia, per impostazione predefinta, questo privilegio non è assegnato a tutti gli account.

Figura 18** Tipo Label ACE di un oggetto **

Quando un processo tenta di aprire un oggetto, il controllo di integrità viene eseguito prima del controllo del DACL di Windows standard nella funzione SeAccessCheck del kernel. In base ai criteri di integrità predefiniti, un processo può aprire un oggetto per l'accesso in scrittura solo se il relativo livello di integrità è uguale o più alto del livello di integrità dell'oggetto e il DACL concede al processo il tipo di accesso desiderato. Ad esempio, un processo con livello di integrità basso non può aprire un processo con livello di integrità medio per l'accesso in scrittura, anche se il DACL concede al processo l'accesso in scrittura.

In base ai criteri di integrità predefiniti, i processi possono aprire qualsiasi oggetto, ad eccezione degli oggetti processo e thread, per l'accesso in lettura, purché il DACL dell'oggetto concede ai processi l'accesso in lettura. Ne consegue che un processo eseguito a un livello di integrità basso può aprire qualsiasi file accessibile all'account utente con cui viene eseguito. La modalità protetta di Internet Explorer utilizza i livelli di integrità per impedire al malware di modificare le impostazioni dell'account utente, ma non impedisce al malware di leggere i documenti dell'utente.

Gli oggetti processo e thread rappresentano delle eccezioni in quanto il relativo criterio di integrità include anche No-Read-Up. Ne consegue che il livello di integrità di un processo deve essere uguale o più alto del livello di integrità del processo o del thread che desidera aprire e perché l'operazione di apertura riesca, è necessario che il DACL conceda al processo il tipo di accesso desiderato. Si supponga che i DACL consentano l'accesso desiderato; nella Figura 19 vengono illustrati i tipi di accessi che i processi eseguiti con i livelli di integrità medio e basso hanno agli altri processi e oggetti.

Figura 19** Accessi a oggetti e processi **

Anche il sottosistema di messaggistica di Windows rispetta i livelli di integrità per implementare la funzionalità UIPI consentendo a un processo di inviare solo un numero limitato di messaggi di finestre informative alle finestre di proprietà di un processo con un livello di integrità più alto. Questo impedisce ai processi utente standard di pilotare l'input alle finestre di processi con privilegi elevati o di compromettere un processo con privilegi elevati inviando a tale processo messaggi in formato non corretto che determinano sovraccarichi del buffer interno. I processi possono scegliere di consentire a ulteriori messaggi di eludere le misure di protezione chiamando l'API ChangeWindowMessageFilter. UIPI impedisce inoltre agli hook delle finestre di influire sulle finestre dei processi con livello di integrità più alto in modo che un processo utente standard non sia in grado ad esempio di registrare i tasti premuti dall'utente in un'applicazione amministrativa.

Elevazioni e limiti di protezione

È importante tenere presente che le elevazioni di privilegi del controllo dell'account utente sono una convenienza e non un limite di protezione. Un limite di protezione richiede che i criteri di protezione stabiliscano chi o cosa può oltrepassare tale limite. Gli account utente sono un esempio di limite di protezione in Windows perché un utente non può accedere ai dati appartenenti a un altro utente senza disporre dell'autorizzazione di tale utente.

Perché le elevazioni non rappresentano limiti di protezione, non esiste alcuna garanzia che il malware eseguito su un sistema con diritti utente standard non possa compromettere un processo con privilegi elevati per ottenere diritti amministrativi. Ad esempio, le finestre di dialogo per l'elevazione dei privilegi identificano solo l'eseguibile a cui verranno concessi privilegi elevati, senza indicare le operazioni che l'eseguibile effettuerà durante l'esecuzione. L'eseguibile elaborerà gli argomenti della riga di comando, caricherà le DLL, aprirà i file di dati e comunicherà con altri processi. Ciascuna di queste operazioni potrebbe consentire a eventuali malware di compromettere il processo con diritti elevati e ottenere pertanto diritti amministrativi.

Esecuzione in una sandbox con livello di integrità basso

La modalità protetta di Internet Explorer viene eseguita con un livello di integrità basso per innalzare una barriera protettiva contro gli eventuali malware che potrebbero infettare il relativo processo. Questo impedisce al malware di modificare le impostazioni di account dell'utente e installarsi in una posizione di avvio automatico. È possibile utilizzare l'utilità PsExec di Sysinternals insieme all'opzione -l per avviare processi arbitrari con un livello di integrità basso in modo da esplorare la sandbox. Come illustrato nella Figura B, un prompt dei comandi eseguito con un livello di integrità basso non è in grado di creare un file nella directory temporanea dell'utente a cui è associato un livello di integrità medio, ma è in grado di eseguire tale operazione nella directory temporanea di Internet Explorer a cui è associato un livello di integrità basso.

Figura B** Il prompt dei comandi è in grado di creare solo file con un livello di integrità simile **(Fare clic sull'immagine per ingrandirla)

I processi in modalità Approvazione amministratore con privilegi elevati sono particolarmente soggetti ad attacchi di malware in quanto vengono eseguiti nello stesso account utente dei processi con diritti standard dell'utente in modalità Approvazione amministratore e condividono il profilo dell'utente. Molte applicazioni leggono le impostazioni e caricano le estensioni registrate nel profilo di un utente, offrendo al malware l'opportunità di assumere privilegi elevati. Ad esempio, le comuni finestre di dialogo di controllo caricano le estensioni Shell configurate nella chiave del Registro di sistema di un utente (in HKEY_CURRENT_USER), fornendo pertanto al malware la possibilità di aggiungersi come estensione in modo da essere caricato in qualsiasi processo con privilegi elevati che utilizza queste finestre di dialogo.

Anche i processi elevati da account utente standard possono essere compromessi a causa dello stato di condivisione. Tutti i processi eseguiti in una sessione di accesso condividono lo spazio dei nomi interno in cui Windows memorizza oggetti come eventi, mutex, semafori e memoria condivisa. Se il malware sa che un processo con privilegi elevati tenterà di aprire e leggere uno specifico oggetto memoria condivisa all'avvio del processo, potrebbe creare l'oggetto con contenuti che determinano un sovraccarico del buffer in modo da inserire del codice nel processo con privilegi elevati. Questo tipo di attacco è relativamente sofisticato, ma impedisce che le elevazioni OTS rappresentino un limite di protezione.

La conclusione è che le elevazioni sono state introdotte per convenienza in modo da incoraggiare gli utenti che desiderano accedere ai diritti amministrativi a utilizzare, per impostazione predefinita, i diritti utente standard. Gli utenti che desiderano le garanzie di un limite di protezione possono rinunciare alla comodità utilizzando un account utente standard per le attività quotidiane e la funzionalità Cambio rapido utente (FUS, Fast User Switching) per passare a un account amministratore dedicato per eseguire le attività amministrative. D'altra parte, gli utenti che desiderano rinunciare alla protezione a favore della comodità possono disattivare il controllo dell'account utente su un sistema nella finestra di dialogo Account Utente del Pannello di controllo, tenendo presente tuttavia che questa operazione determina la disattivazione della modalità protetta di Internet Explorer.

Conclusioni

L'esecuzione con privilegi utente standard offre numerosi vantaggi, tra cui la garanzia della protezione dei sistemi da danni accidentali o volontari e la protezione dei dati e dell'integrità degli utenti che condividono un sistema da accessi non autorizzati. Le diverse modifiche e tecnologie alla base del controllo dell'account utente avranno come risultato l'introduzione di un cambiamento sostanziale nel modello di utilizzo di Windows. Con Windows Vista, gli utenti di Windows sono per la prima volta in grado di eseguire gran parte delle attività quotidiane e la maggior parte delle applicazioni software con diritti utente standard e molte aziende hanno ora la possibilità di distribuire account utente standard.

Mark Russinovichè un Technical Fellow di Microsoft nella Platform and Services Division. È coautore di Microsoft Windows Internals (Microsoft Press, 2004) e spesso partecipa come oratore a conferenze su IT e sviluppo. È entrato in Microsoft dopo la recente acquisizione dell'azienda che ha cofondato, Winternals Software. Ha inoltre creato Sysinternals, dove ha pubblicato le utilità Process Explorer, Filemon e Regmon.

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