La magia dietro UAC

Diciamolo, la feature che mi piace di più di Vista è UAC. Recentemente ho ripetuto più volte che il comportamento di default di Windows XP, di assegnare poteri immensi a tutte le applicazioni, è dannoso non solo tenendo in mente la prospettiva del malware. Un'applicazione normale, per colpa di qualche bug, potrebbe accidentalmente sovrascrivere tutti i settori dell'hard disk riempiendoli di 0. Siccome l'ho visto accadere coi miei occhi in una macchina virtuale, la possibilità che questo accada nella mia testa è stata riqualificata come "pratica" anziché solo "teorica".

Su UAC ci sarebbe ben poco da aggiungere, soprattutto dopo il post esauriente di Vik sull'argomento, ma lo scopo di questo post è di chiarire cosa avviene under the cover e di fare alcune considerazioni su due modi diversi di loggarsi in Vista.

Uno dei punti del contendere più spesso dibattuti^[1] a riguardo è se convenga sia dal punto di vista della sicurezza che dell'usabilità loggarsi come amministratore (non necessariamente Administrator ma inteso come utente appartenente al gruppo degli amministratori; d'ora in poi SuperPippo) oppure come utente normale (Pippo) avendo avuto l'accortezza di creare un utente aggiuntivo di amministrazione.

Un'analisi delle differenze può aiutare a decidere meglio:

• ai fini di ottenere l'elevazione, se ci si logga come SuperPippo (in gergo Admin Approval Mode o AAM), di default appare il cosiddetto prompt "Mi Consenta" dove basta cliccare "Continue" per proseguire:
   
  Nel caso ci si è loggati come Pippo, è necessario digitare la password di SuperPippo (o altro utente Admin) per proseguire, nello stesso gergo Over The Shoulder (OTS) authentication:
  
• Nel caso in cui ci si logghi come Pippo, un processo che ottiene elevazione, girerà con le credenziali di SuperPippo. Se ad esempio crea un file in %Documents% il file verrà scritto nella cartella Documents di SuperPippo e non di Pippo come ci si potrebbe aspettare!

Se il primo dei due punti può rappresentare un piccolo vantaggio in termini di sicurezza (password invece che un click magari maldestro), il secondo è decisamente uno svantaggio in termini di usabilità. È però possibile loggarsi come SuperPippo e fare in modo che anziché un prompt "Mi Consenta", si venga accolti con una richiesta di password, tramite un setting disponibile via Local Security Policy:

In realtà per i super-paranoici è possibile richiedere il three-finger-salute (CTRL+ALT+DEL) prima del prompt "Mi Consenta" o richiesta di password, tramite l'apposita opzione nelle group policy:

Questa era addirittura l'opzione di default nelle prime beta di Vista, abbandonata precocemente per motivi di usabilità. Interessante è un post di Jim Allchin che dettaglia tutti i motivi che anno portato a tutte le attuali scelte di default.

Il migliore dei mondi possibili (unico utente SuperPippo, ma richiesta di password anziché "Mi Consenta") è perció solo ad una manciata di click di configurazione.

Ma dal punto di vista della sicurezza, cosa cambia tra quando ci si logga come SuperPippo e quando ci si logga come Pippo? Assolutamente niente^[2].

Un facile esperimento è quello di loggarsi come SuperPippo, aprire un Command Prompt non elevato e cercare di scrivere in %SYSTEM%: il risultato è quello di Access Denied. Se si tenta l'operazione da un Command Prompt elevato, l'operazione va complessivamente in porto.

Come avviene la magia che da il titolo a questo post? Cosa succede a SuperPippo se l'AAM è attivato? Perché l'amministratore non riesce ad accedere in scrittura a folder che sono accessibili all'amministratore?

Il trucco è semplice. Nel momento in cui ci si logga come SuperPippo in AAM, il sistema crea un token^[3] secondario (detto anche split-token) rimuovendo alcuni permessi associati al token dell'amministratore. I permessi che vengono rimossi sono indicati in questa pagina MSDN. Qui di sotto la differenza di permessi tra i due token, quello usato per processi che richiedono elevazione e quello usato per tutto il resto delle operazioni:

Inoltre, e questo è il punto fondamentale per capire cosa succede quando si accede ad un file, il SID associato al gruppo Amministratori è marcato come Deny  come si può notare da questa figura:

Questo significa che l'utente SuperPippo verrà considerato appartenente al gruppo degli Amministratori solamente in caso di matching di ACE di tipo Deny. Normalmente invece l'accesso ai folder per gli Amministratori è definito da una ACE di tipo Allow, per cui a tutti gli effetti, il token secondario di SuperPippo, quello usato di default, è il token di un utente "normale". Questo meccanismo accoppiato con le ACL più aggressive per default di Vista (dettagliate in questo interessantissimo articolo su TechNet) rende di fatto SuperPippo un utente normale. Ergo affermazioni come la seguente sono palesemente false:

Con Vista Microsoft prosegue con la politica di “tutti amministratori”, laddove i controllori di identità (UAC) si limitano ad evitare che un malware ne approfitti

In realtà con Vista si persegue la politica opposta: "nessun amministratore", con l'antipaticissimo UAC a tenere le chiavi del paradiso proibito.

Conclusione: tra loggarsi come SuperPippo (AAM) e loggarsi come Pippo (OTS) non c'è nessuna differenza a livello di sicurezza: se si preferisce il prompt con la richiesta di password, basta cambiare una policy per ottenere lo stesso effetto. Dal punto di vista pratico però, la modalità AAM ha qualche piccolo vantaggio di usabilità. Un ulteriore consiglio da tenere in mente, se si preferisce la modalità AAM, è quello di creare comunque un account amministrativo secondario in caso di disaster recovery.

-quack

^[1] Si veda ad esempio questo post di Jeff Atwood alquanto critico nei confronti di Vista: Microsoft didn't have the guts to make standard users the default-- as they absolutely should have-- in Windows Vista.

^[2] Cioé la differenza tra autenticazione AAM (mi loggo come SuperPippo e inserisco una password o clicco consenta) e OTS (mi loggo come Pippo e inserisco la password di SuperPippo) è nulla in quanto UAC non costituisce un security boundary. Si veda questo interessante post di Russinovich, tenendo presente che uno squatting attack è estremamente complicato da portare a compimento.

^[3] Un token è un oggetto di sistema che rappresenta un set di privilegi.