Progettazione del meccanismo di integrità di Windows

  • Articolo

Il meccanismo di integrità di Windows è un'estensione dell'architettura di sicurezza di Windows, basata sul monitoraggio dei riferimenti alla sicurezza nel kernel. Il monitoraggio dei riferimenti alla sicurezza applica il controllo di accesso confrontando i SID utente e gruppo nel token di accesso alla sicurezza con autorizzazioni di accesso concesse nell'elenco di controllo di accesso di un oggetto del descrittore di sicurezza di un oggetto. Il meccanismo di integrità aggiunge un livello di integrità al token di accesso alla sicurezza e una voce di controllo di accesso dell'etichetta obbligatoria all'ACL di sistema (SACL) nel descrittore di sicurezza.

Le parti principali del meccanismo di integrità sono:

  • Livelli di integrità predefiniti e la relativa rappresentazione.
  • Criteri di integrità che limitano le autorizzazioni di accesso.
  • Livello di integrità assegnato al token di accesso alla sicurezza.
  • Voce di controllo di accesso dell'etichetta obbligatoria.
  • Etichette obbligatorie assegnate agli oggetti.
  • Restrizioni di integrità all'interno delle API SeAccessCheck e in modalità kernel.

Ognuna di queste parti è descritta in dettaglio di seguito. Il meccanismo di integrità di Windows è sempre attivo, indipendentemente da altre opzioni dei criteri di sicurezza. I controlli del livello di integrità, come i controlli di controllo di accesso, non sono facoltativi. Non sono disponibili opzioni dei criteri di sicurezza per disabilitare i controlli a livello di integrità. Anche se il meccanismo di integrità supporta l'interfaccia utente, il meccanismo di integrità rimane in vigore quando l'interfaccia utente è disabilitata dalla Criteri di gruppo di sicurezza.

Livelli di integrità

Windows definisce i livelli di integrità usando un SID. L'uso di un SID per rappresentare un livello di integrità semplifica l'integrazione del meccanismo di integrità nelle strutture di dati di sicurezza esistenti senza richiedere modifiche al codice. I SID a livello di integrità hanno il formato seguente: S-1-16-xxxx. La tabella 1 mostra i componenti dei SID a livello di integrità.

Valori dell'autorità di identificatore SID a livello di integrità della tabella 1

Valore Descrizione

16

Rappresenta l'autorità di etichettatura obbligatoria (SECURITY_MANDATORY_LABEL_AUTHORITY).

xxxx

Rappresenta il campo RID (Relative Identifier) che è il livello di integrità. RID è un valore esadecimale che rappresenta il livello di integrità.

Esistono quattro livelli di integrità primari in Windows Vista con quattro valori corrispondenti. Un valore inferiore indica un livello di integrità inferiore o un livello inferiore di attendibilità. Questi valori sono definiti nel file di intestazione winnt.h. La tabella 2 mostra i livelli di integrità definiti e i relativi valori corrispondenti.

Tabella 2 Livelli di integrità definiti e valori corrispondenti

Valore Descrizione Simbolo

0x0000

Livello non attendibile

SECURITY_MANDATORY_UNTRUSTED_RID

0x1000

Livello di integrità basso

SECURITY_MANDATORY_LOW_RID

0x2000

Livello di integrità medio

SECURITY_MANDATORY_MEDIUM_RID

0x3000

Livello di integrità elevato

SECURITY_MANDATORY_HIGH_RID

0x4000

Livello di integrità del sistema

SECURITY_MANDATORY_SYSTEM_RID

Un esempio di SID a livello di integrità medio è questa stringa: S-1-16-8192. Il valore RID 8192 è l'equivalente decimale di 0x2000.

I RID sono separati da intervalli di 0x1000 per consentire la definizione di livelli aggiuntivi in futuro. La separazione consente anche di assegnare un livello di integrità a un processo leggermente superiore al medio, ad esempio per soddisfare obiettivi di progettazione di sistema specifici.

I SID a livello di integrità definiti hanno valori di nome stringa associati. L'uso dell'API LookupAccountSID restituirà i nomi di stringa per ogni SID a livello di integrità. La tabella 3 mostra i nomi di stringa per i livelli di integrità.

Nomi delle stringhe a livello di integrità della tabella 3

SID a livello di integrità Nome

S-1-16-4096

Etichetta obbligatoria\Basso livello obbligatorio

S-1-16-8192

Etichetta obbligatoria\Livello obbligatorio medio

S-1-16-12288

Etichetta obbligatoria\Livello obbligatorio

S-1-16-16384

Etichetta obbligatoria\Livello obbligatorio del sistema

I livelli di integrità sono definiti anche come stringhe SID nel linguaggio SDDL (Security Descriptor Definition Language). SDDL definisce il formato stringa usato dalle funzioni ConvertSecurityDescriptorToStringSecurityDescriptor e ConvertStringSecurityDescriptorToSecurityDescriptor per descrivere un descrittore di sicurezza come stringa di testo. Il linguaggio definisce anche gli elementi stringa per descrivere le informazioni nei componenti di un descrittore di sicurezza. L'uso dell'SDDL per definire i livelli di integrità consente di definire il livello di integrità di un oggetto quando viene creato l'oggetto. Per altre informazioni sulle stringhe SID per i livelli di integrità, vedere Risorse del meccanismo di integrità di Windows. Il supporto SDDL per le etichette obbligatorie è descritto in Appendice A: SDDL per etichette obbligatorie.

Windows Vista usa i SID a livello di integrità nel token di accesso alla sicurezza per rappresentare il livello di integrità dell'oggetto e usa i SID a livello di integrità nell'etichetta obbligatoria ACE in un descrittore di sicurezza per rappresentare il livello di integrità dell'oggetto.

Criteri di integrità

Il meccanismo di integrità di Windows usa criteri semplici per determinare come usare le etichette obbligatorie sugli oggetti per limitare il livello di accesso disponibile per soggetti con integrità inferiore. Ciò significa che i criteri limitano il tipo di accesso che gli oggetti a livello di integrità inferiore possono avere oggetti a livello di integrità superiore. La tabella 4 mostra le due categorie di criteri.

Tabella 4 Categorie di criteri di integrità

Category Descrizione

Criteri obbligatori del token di accesso

Impostare nel token di accesso e determinare il modo in cui i criteri obbligatori si applicano all'oggetto, rappresentato nel token di accesso.

Criteri di etichetta obbligatori

Impostare nell'etichetta obbligatoria ACE (descritto di seguito) sugli oggetti e determinare come limitare l'accesso all'oggetto.

I criteri di integrità vengono usati quando viene eseguita la verifica dei criteri obbligatori quando si valutano le autorizzazioni di accesso in un oggetto a protezione diretta. I criteri determinano la modalità di restrizione dei diritti di accesso tra i livelli di integrità.

Criteri di token di accesso obbligatori

La tabella 5 mostra i criteri di token di accesso obbligatori definiti in Windows Vista.

Tabella 5 Criteri di token di accesso obbligatori in Windows Vista

Criteri Descrizione

TOKEN_MANDATORY_NO_WRITE_UP

Criterio predefinito assegnato a tutti i token di accesso. Il criterio limita l'accesso in scrittura da questo oggetto a qualsiasi oggetto a un livello di integrità superiore.

TOKEN_MANDATORY_NEW_PROCESS_MIN

Controlla il comportamento dell'assegnazione del livello di integrità ai processi figlio. In genere, un processo figlio eredita il livello di integrità del processo padre quando il token di accesso al processo padre viene assegnato al figlio. Con il criterio NEW_PROCESS_MIN, il livello di integrità del processo figlio sarà il livello di integrità minimo del token di accesso padre o il livello di integrità dell'oggetto del file eseguibile per il nuovo processo. Questo criterio viene impostato per impostazione predefinita in tutti i token di accesso.

I criteri di NEW_PROCESS_MIN possono essere descritti da un esempio. Si supponga che esista un programma eseguibile denominato lowcalc.exe. Il file di programma viene assegnato a un'etichetta di integrità ridotta. Da un prompt dei comandi, l'utente esegue lowcalc.exe. Il processo padre, cmd.exe, è in esecuzione a un livello di integrità medio. Poiché il file di immagine, lowcalc.exe, ha un'etichetta di integrità ridotta, il criterio NEW_PROCESS_MIN imposta il livello di integrità del nuovo processo, lowcalc, su basso. Questo è illustrato nell'esempio seguente nella sezione Progettazione di applicazioni da eseguire a livello di integrità basso.

Criteri di etichetta obbligatori

I criteri di etichetta obbligatori sono definiti come flag (bit) nel campo Maschera della voce di controllo di accesso dell'etichetta obbligatoria. Questi flag di criteri determinano le restrizioni relative alle autorizzazioni di accesso che si applicano a soggetti di integrità inferiori. La tabella 6 mostra i criteri di etichetta obbligatori definiti in Windows Vista.

Tabella 6 Criteri di etichetta obbligatori in Windows Vista

Criteri Descrizione

SYSTEM_MANDATORY_POLICY_NO_WRITE_UP

Criterio predefinito per tutte le etichette obbligatorie degli oggetti. Il flag equivale ai criteri di token di accesso NO_WRITE_UP. Il criterio limita l'accesso in scrittura all'oggetto da un soggetto con un livello di integrità inferiore.

SYSTEM_MANDATORY_POLICY_NO_READ_UP

Limita l'accesso in lettura all'oggetto da un soggetto con un livello di integrità inferiore. Il criterio viene usato, ad esempio, per limitare l'accesso in lettura allo spazio indirizzi di memoria virtuale di un processo.

SYSTEM_MANDATORY_POLICY_NO_EXECUTE_UP

Limita l'accesso all'oggetto da un oggetto con un livello di integrità inferiore. Il criterio viene usato, ad esempio, per limitare le autorizzazioni di attivazione di avvio in una classe COM da soggetti di integrità inferiore.

Questi criteri definiti soddisfano gli obiettivi di progettazione per Windows Vista. L'architettura del meccanismo di integrità consente un'espansione futura definendo opzioni di criteri aggiuntive che controllano le autorizzazioni di accesso tra soggetti e oggetti a livelli di integrità diversi.

Modalità di mapping dei criteri di integrità ai diritti generici

Il controllo dei criteri obbligatori si verifica come parte della funzione di sicurezza AccessCheck. AccessCheck (e SeAccessCheck in modalità kernel) include come uno dei parametri della funzione una struttura GENERIC_MAPPING. Il mapping generico fornito dal chiamante esegue il mapping dei diritti di accesso specifici degli oggetti alle categorie generice di lettura, scrittura ed esecuzione. I criteri di etichetta obbligatori implementano restrizioni per l'accesso consentito in base alle categorie generice. Per un tipo di oggetto specifico, il GENERIC_MAPPING comunica ai criteri obbligatori verificare quali diritti di accesso specifici sono vietati.

Se la struttura GENERIC_MAPPING passata a una chiamata a AccessCheck è tutti zero (0), il mapping generico non è definito. Quando il mapping generico non è definito, il controllo dei criteri obbligatori limita tutti i diritti di accesso per soggetti con integrità inferiore. I responsabili delle risorse che usano AccessCheck per la sicurezza degli oggetti privati e passano una struttura GENERIC_MAPPING di tutti gli zero visualizzeranno errori di accesso negato . È necessaria una modifica del codice all'applicazione resource manager per eseguire il mapping dei diritti di accesso specifici del tipo di oggetto ai diritti di accesso generici applicati dai criteri obbligatori.

Modalità di assegnazione dei livelli di integrità ai token di accesso

Il token di accesso alla sicurezza è una struttura di dati interna usata dal kernel. Il token di accesso alla sicurezza contiene valori di informazioni diversi che corrispondono a privilegi, appartenenza al gruppo e altri dettagli correlati alla sicurezza. L'inizializzazione del token di accesso si verifica quando un utente accede in modo interattivo a Windows o quando si verifica un'autenticazione di rete. Quando il token di accesso viene inizializzato, vengono aggiunti i SID, i SID del gruppo e i privilegi, oltre ad altri valori. Windows Vista assegna il livello di integrità per il token di accesso quando viene inizializzato il token di accesso.

Il kernel assegna un token di accesso a ogni processo e thread. Il token di accesso primario del processo contiene il livello di integrità associato a tale processo. Nel meccanismo di integrità di Windows il livello di integrità del processo viene definito livello di integrità soggetto. Se il token di accesso di un'applicazione contiene il SID di integrità media, il processo dell'applicazione viene eseguito a livello di integrità medio. Più processi dell'applicazione in esecuzione nello stesso account utente vengono assegnati allo stesso token di accesso primario. Questo è il modo in cui ogni applicazione viene assegnata allo stesso livello di integrità.

I livelli di integrità vengono assegnati ai token di accesso in base ai SID di gruppo specifici presenti nella struttura TOKEN_GROUPS. Il kernel di Windows assegna un livello di integrità basato su account utente o gruppi predefiniti specifici. Windows Vista assegna un token di accesso con SID di sistema locale che presenta il livello di integrità del sistema, un token di accesso con il SID del gruppo administrators locale viene assegnato il livello di integrità di alto e viene assegnato un token di accesso per un account utente standard.

La tabella 7 mostra le assegnazioni del livello di integrità al token di accesso, in base alla presenza di SID specifici.

Livelli di integrità della tabella 7 collegati a SID specifici

SID nel token di accesso Livello di integrità assegnato

LocalSystem

Sistema

LocalService

Sistema

NetworkService

Sistema

Administrators

Alto

Backup Operators

Alto

Network Configuration Operators

Alto

Operazioni di crittografia

Alto

Utenti autenticati

Medio

Tutti (mondo)

Basso

Anonimo

Non attendibili

I livelli di integrità definiscono diversi livelli di attendibilità per le applicazioni in esecuzione a livelli diversi di accesso. La maggior parte delle applicazioni in Windows Vista viene eseguita a livello di utente standard a livello di integrità media. Le applicazioni a livello di integrità media non presentano restrizioni sul modo in cui interagiscono con altre applicazioni e con i dati a livello di integrità media. Attività o applicazioni specifiche che richiedono diritti amministrativi vengono eseguiti a livello elevato di integrità. I servizi di sistema vengono eseguiti a livello di integrità del sistema, perché esistono restrizioni sulla possibilità di interagire con il desktop predefinito e spesso vengono eseguiti con privilegi di sistema potenti. Alcune applicazioni progettate per l'esecuzione con i diritti più bassi possibili, ad esempio Internet Explorer in modalità protetta, possono essere eseguite con un livello di integrità basso.

Alcuni privilegi amministrativi di Windows possono essere assegnati a un token di accesso solo con almeno un livello di integrità elevato. Se il livello di integrità del token di accesso è minore di alto, non sono consentiti privilegi amministrativi specifici e vengono rimossi dal token di accesso. I privilegi amministrativi associati a un livello di integrità elevato sono:

  • SE_CREATE_TOKEN_PRIVILEGE
  • SE_TCB_PRIVILEGE
  • SE_TAKE_OWNERSHIP_PRIVILEGE
  • SE_BACKUP_PRIVILEGE
  • SE_RESTORE_PRIVILEGE
  • SE_DEBUG_PRIVILEGE
  • SE_IMPERSONATE_PRIVILEGE
  • SE_RELABEL_PRIVILEGE
  • SE_LOAD_DRIVER_PRIVILEGE

Le applicazioni possono assegnare un livello di integrità basso a un token di accesso duplicato durante la creazione di un processo figlio. Windows potrebbe eseguire un processo dell'applicazione con un livello di integrità basso se il file di immagine del programma eseguibile ha un'etichetta obbligatoria bassa. Queste funzionalità sono descritte più avanti in questo articolo.

Come ottenere il livello di integrità per un token di accesso

Il livello di integrità viene archiviato nel token di accesso usando il campo TOKEN_GROUPS. La struttura TOKEN_GROUPS è un elenco di SID e attributi che identificano le appartenenze ai gruppi per tale account utente. Il livello di integrità del token di accesso viene identificato anche nell'elenco di gruppi usando un attributo SID. La struttura SID_AND_ATTRIBUTES contiene il SID a livello di integrità e il livello di integrità viene identificato usando gli attributi SE_GROUP_INTEGRITY e SE_GROUP_INTEGRITY_ENABLED.

È possibile recuperare il livello di integrità del token di accesso dal token di accesso usando l'API GetTokenInformation. GetTokenInformation ha un parametro per indicare la classe di informazioni sul token di accesso da recuperare. Il parametro TOKEN_INFORMATION_CLASS ha un valore definito per il livello di integrità, TokenIntegrityLevel. La struttura di dati restituita è un tipo di TOKEN_MANDATORY_LABEL.

Per determinare il livello di integrità di un processo

  1. Aprire un handle per il token di accesso del processo.

  2. Ottenere il livello di integrità del token di accesso.

  3. Confrontare il SID a livello di integrità con i RID a livello di integrità definiti dal sistema.

Il codice di esempio per ottenere il livello di integrità del token di accesso viene visualizzato in Appendice D.

Come visualizzare il livello di integrità per un token di accesso

Il livello di integrità nel token di accesso alla sicurezza di un processo può essere visualizzato usando strumenti che espongono i dettagli di sicurezza di un processo, ad esempio Esplora processi da SysInternals.com. Le immagini seguenti mostrano la visualizzazione da Esplora processi con la colonna Livello di integrità aggiunta alla visualizzazione (a destra).

Figura 1 Livello di integrità in Esplora processi

Se si esaminano le proprietà di sicurezza di un processo specifico, ad esempio explorer.exe, Esplora processi mostra il livello di integrità nell'elenco dei gruppi definiti nel token di accesso alla sicurezza del processo. L'immagine seguente mostra il livello obbligatorio obbligatorio etichetta/medio assegnato al token di accesso per il processo, explorer.exe.

Figura 2 Explorer.exe come processo di integrità medio

Come impostare il livello di integrità per un token di accesso

Le applicazioni in genere non devono modificare il valore del livello di integrità del processo. Le applicazioni in genere non devono apportare modifiche a uno dei valori nel token di accesso alla sicurezza. Tuttavia, in alcune circostanze, i servizi che supportano i client locali a livelli di integrità diversi possono scegliere di eseguire attività a un livello di integrità inferiore. La rappresentazione è un modo in cui un thread di servizio può essere in esecuzione a un livello di integrità inferiore. Quando un thread di servizio rappresenta un client locale, il thread di rappresentazione ha il contesto di sicurezza del client, che include il livello di integrità del client se il client è in esecuzione nello stesso computer locale.

Un altro modo in cui un'applicazione può eseguire un'operazione, ad esempio la creazione di un set di file e chiavi del Registro di sistema, a un livello di integrità inferiore consiste nell'impostare TokenIntegrityLevel per il token di accesso al thread corrente. Il nuovo livello di integrità non può essere superiore al livello di integrità nel token di accesso primario del processo.

Per impostare il valore di un livello di integrità del token di accesso in un thread

  1. Chiamare OpenThreadToken per ottenere un handle per il token di accesso.

  2. Chiamare GetTokenInformation con il valore del parametro TOKEN_INFORMATION_CLASS di TokenIntegrityLevel per salvare il livello di integrità del thread corrente.

  3. Chiamare SetTokenInformation con il valore del parametro TOKEN_INFORMATION_CLASSdi TokenIntegrityLevel.

Poiché non esiste alcun limite di sicurezza all'interno di uno spazio di indirizzi di processo tra thread a livelli di integrità diversi, i progettisti di applicazioni devono considerare i potenziali rischi di sicurezza di avere codice in esecuzione in un thread con integrità inferiore in esecuzione in un processo di integrità superiore. La maggior parte delle applicazioni potrebbe risultare più semplice creare un processo separato in esecuzione a livello di integrità inferiore per eseguire attività di integrità inferiori.

Un esempio di come impostare TokenIntegrityLevel e creare un processo a un livello di integrità inferiore viene illustrato in Come impostare il livello di integrità per un token di accesso.

Ace etichetta obbligatoria

Il meccanismo di integrità di Windows definisce un nuovo tipo ACE, l'etichetta obbligatoria del sistema ACE. L'etichetta obbligatoria ACE viene usata per rappresentare l'etichetta obbligatoria di un oggetto nel descrittore di sicurezza dell'oggetto. L'etichetta obbligatoria contiene il livello di integrità e i criteri di integrità associati. Un'etichetta obbligatoria ACE viene usata solo nell'ACL di sistema o SACL del descrittore di sicurezza. SACL è un campo separato nel descrittore di sicurezza dall'ACL (DACL) discrezionale.

Figura 3 Campi descrittori di sicurezza

L'elenco di controllo di accesso discrezionale contiene autorizzazioni di accesso utente e gruppo all'oggetto. Qualsiasi utente o gruppo può apportare aggiornamenti all'elenco dati con autorizzazioni di accesso a oggetti WRITE_DAC. Gli ACL discrezionali possono essere aggiornati più frequentemente e da utenti diversi. Uno degli obiettivi di progettazione del meccanismo di integrità è che il sistema di sicurezza deve mantenere l'etichetta con un oggetto dopo l'applicazione di un'etichetta obbligatoria all'oggetto. L'applicazione dell'etichetta obbligatoria appropriata nel descrittore di sicurezza degli oggetti, con un impatto minimo o negativo sulle applicazioni progettate per gestire gli ACL, viene eseguita inserendo l'etichetta obbligatoria nell'ACL di sistema, dove è principalmente sotto il controllo del sistema di sicurezza. L'etichetta obbligatoria è logicamente separata dalle voci di controllo del sistema in SACL. Non esiste alcun ordine obbligatorio per l'etichetta obbligatoria da precedere o seguire le voci di controllo del sistema in SACL.

L'etichetta obbligatoria ACE è simile a un ace consentito di accesso, in quanto contiene un'intestazione ACE, una maschera di accesso e un SID. La parte SID dell'etichetta obbligatoria ACE contiene il SID a livello di integrità. La tabella 8 mostra i campi nell'intestazione ACE.

Tabella 8 Campi contenuti nell'intestazione ACE

Campo intestazione ACE Valore

AceType

SYSTEM_MANDATORY_LABEL_ACE_TYPE

AceFlags

Flag di controllo che definiscono l'ereditarietà del tipo ACE dell'etichetta obbligatoria

AceSize

Dimensioni dell'etichetta obbligatoria ACE

L'etichetta obbligatoria ACE contiene un campo Mask . La maschera viene usata per definire i criteri obbligatori che determinano restrizioni sulle autorizzazioni di accesso applicabili ai processi (o ai soggetti) con un livello di integrità inferiore. Un criterio di esempio usato ampiamente in Windows Vista è il criterio di NO_WRITE_UP. Il flag di criteri NO_WRITE_UP nella maschera ACE dell'etichetta obbligatoria indica che i soggetti con un livello di integrità inferiore (nel token di accesso) rispetto al SID a livello di integrità nell'etichetta obbligatoria dell'oggetto sono limitati a ottenere l'accesso in scrittura generico all'oggetto.

Esiste solo un'etichetta obbligatoria effettiva su un oggetto. Se un descrittore di sicurezza accade per ottenere più di un'etichetta obbligatoria in SACL, la prima etichetta obbligatoria ACE in SACL è l'etichetta efficace per l'oggetto.

Per altre informazioni sull'etichetta obbligatoria ACE, vedere Risorse del meccanismo di integrità di Windows.

Lettura dell'etichetta obbligatoria ACE

Windows Vista usa la funzione di sicurezza GetSecurityInfo per leggere le informazioni sull'etichetta obbligatorie da un oggetto. GetSecurityInfo ottiene le informazioni proprietario, gruppo, DACL o SACL da un oggetto. Il parametro SECURITY_INFORMATION per GetSecurityInfo determina quale parte del descrittore di sicurezza viene restituito. Windows Vista definisce un nuovo valore delle informazioni di sicurezza, LABEL_SECURITY_INFORMATION, che viene usato per restituire l'etichetta obbligatoria ACE da SACL. Se la chiamata a GetSecurityInfo specifica SACL_SECURITY_INFORMATION, vengono restituiti solo gli ACL di controllo del sistema in SACL, non l'etichetta obbligatoria ACE.

L'autorizzazione di accesso necessaria per leggere l'etichetta obbligatoria ACE in un oggetto è il diritto di accesso standard READ_CONTROL. In genere, il diritto di accesso ACCESS_SYSTEM_SECURITY è necessario per ottenere o impostare informazioni in SACL. ACCESS_SYSTEM_SECURITY viene concesso solo se il privilegio SE_SECURITY_NAME è abilitato nel token di accesso. La lettura dell'etichetta obbligatoria da SACL non richiede privilegi SE_SECURITY_NAME o il diritto di accesso ACCESS_SYSTEM_SECURITY.

Impostazione dell'etichetta obbligatoria ACE

Windows Vista usa la funzione di sicurezza SetSecurityInfo per modificare le informazioni sull'etichetta obbligatorie in un oggetto. L'etichetta obbligatoria dell'oggetto viene impostata dal sottosistema di sicurezza al momento della creazione dell'oggetto. Il parametro SECURITY_INFORMATION di SetSecurityInfo deve includere LABEL_SECURITY_INFORMATION per modificare l'etichetta obbligatoria nel descrittore di sicurezza.

L'etichetta obbligatoria assegnata alla creazione dell'oggetto è in genere il livello di integrità corretto per un oggetto e non è necessario modificare l'etichetta obbligatoria. Tuttavia, potrebbero essere presenti requisiti di progettazione dell'applicazione per modificare il livello di integrità di un oggetto quando l'applicazione è progettata per supportare più processi client a livelli di integrità diversi.

Le autorizzazioni necessarie per modificare l'etichetta obbligatoria ACE in SACL di un descrittore di sicurezza sono WRITE_OWNER. La scrittura dell'etichetta obbligatoria in SACL non richiede privilegi SE_SECURITY_NAME o il diritto di accesso ACCESS_SYSTEM_SECURITY. Il livello di integrità nell'etichetta obbligatoria può essere impostato su un valore minore o uguale al livello di integrità dell'oggetto.

La modifica più comune consiste nel ridurre il livello di integrità di un oggetto per consentire a un processo di applicazione di integrità inferiore di avere accesso modificato. Ad esempio, un'applicazione a livello di integrità media deve sincronizzare con un altro processo dell'applicazione in esecuzione a basso livello di integrità. Il processo di integrità media crea un oggetto mutex denominato e lo assegna a un'etichetta obbligatoria a basso per consentire a un processo di integrità inferiore di aprire il mutex per segnalare gli eventi.

Privilegi di rilabel

Il meccanismo di integrità di Windows definisce un nuovo privilegio di sicurezza di Windows, SE_RELABEL_NAME. Se abilitato in un token di accesso alla sicurezza, il privilegio di sicurezza di rivalutazione consente all'oggetto di impostare l'etichetta obbligatoria di un oggetto su un livello di integrità superiore al livello di integrità nel token di accesso dell'oggetto. I criteri di sicurezza predefiniti per Windows Vista non assegnano questo privilegio a un utente o a un gruppo. Il privilegio è progettato per risolvere gli scenari in cui un processo amministratore in esecuzione a un livello elevato di integrità deve modificare o assegnare l'etichetta obbligatoria per gli oggetti a livello di integrità del sistema. Windows Vista non dispone di attività che richiedono o usano il privilegio di rivalutazione.

Come Windows assegna un'etichetta obbligatoria agli oggetti

Windows assegna un'etichetta obbligatoria a un oggetto a protezione diretta quando viene creato il descrittore di sicurezza degli oggetti. Il livello di integrità su un nuovo oggetto viene assegnato in uno dei tre modi seguenti:

  • Il sottosistema di sicurezza assegna all'oggetto un'etichetta obbligatoria quando viene creato il descrittore di sicurezza per l'oggetto.
  • Il processo di creazione specifica un'etichetta obbligatoria esplicita come attributi di sicurezza durante la creazione dell'oggetto usando una funzione, ad esempio CreateFile.
  • Il contenitore padre definisce un'etichetta obbligatoria ereditabile ACE che si applica agli oggetti figlio creati nel contenitore.

Il modo più semplice per comprendere come vengono assegnati i livelli di integrità degli oggetti consiste nel presupporre che a ogni oggetto venga assegnata un'etichetta obbligatoria con lo stesso livello di integrità del soggetto del processo di creazione (o thread). Esistono tuttavia eccezioni all'idea generale in base al tipo di oggetto e al livello di integrità del soggetto. Le eccezioni sono il risultato di scelte di progettazione necessarie per supportare altri requisiti di sistema per un'esperienza utente coerente quando diversi criteri di sicurezza, ad esempio controllo dell'account utente, sono abilitati o disabilitati.

Le etichette obbligatorie possono essere applicate a tutti gli oggetti a protezione diretta con controllo di accesso basato sul descrittore di sicurezza. Esistono molti tipi di oggetti a protezione diretta, tra cui oggetti process e thread, oggetti denominati e oggetti persistenti, ad esempio file o chiavi del Registro di sistema. Windows Vista non assegna etichette obbligatorie esplicite a tutti i tipi di oggetto quando vengono creati oggetti. I tipi di oggetto a cui il sottosistema di sicurezza assegna etichette obbligatorie durante la creazione di oggetti sono:

  • Processo
  • Thread
  • Token di accesso
  • Processo

Tutti gli altri tipi di oggetto hanno un valore predefinito implicito o un'etichetta obbligatoria ereditata. Tenere presente che, durante l'inizializzazione del token di accesso, viene assegnato un livello di integrità al token di accesso di sicurezza creato durante un accesso interattivo. Il primo processo avviato per conto di un accesso utente è userinit.exe, che avvia il processo della shell explorer.exe. Userinit.exe viene avviato da un servizio di sistema (Winlogon) che usa una chiamata a CreateProcessAsUser e passa il token di accesso per l'utente di accesso interattivo.

CreateProcessAsUser crea tra l'altro un oggetto processo e un thread iniziale. Quando viene creato l'oggetto processo, al descrittore di sicurezza per tale processo viene assegnato il livello di integrità dal token di accesso assegnato come token di accesso primario al nuovo processo. Quando userinit.exe chiama CreateProcess per avviare la shell, viene inizializzato l'oggetto processo per explorer.exe. L'oggetto processo include un descrittore di sicurezza e un token di accesso primario. L'etichetta obbligatoria nel processo di explorer.exe viene impostata sul livello di integrità del processo di creazione, userinit.exe, che è medio. Il token di accesso primario per explorer.exe viene ereditato dal processo padre di creazione, userinit.exe e ha un livello di integrità medio. Quando il processo di explorer.exe crea un nuovo thread, all'oggetto thread viene assegnato un descrittore di sicurezza e il sottosistema di sicurezza assegna un livello di integrità all'oggetto thread in base al livello di integrità del processo di creazione. Agli oggetti thread all'interno del processo di explorer.exe viene assegnato un livello di integrità medio, ovvero il livello di integrità del token di accesso primario del processo di creazione.

Nota

Un oggetto token di accesso è un oggetto a protezione diretta con il proprio descrittore di sicurezza. Il descrittore di sicurezza del token viene usato per determinare l'accesso consentito durante le funzioni OpenProcessToken o OpenThreadToken. L'oggetto token di accesso ha un'etichetta obbligatoria nel descrittore di sicurezza nell'oggetto token di accesso. Il token di accesso contiene anche un SID a livello di integrità nell'elenco dei gruppi di token di accesso che rappresenta il livello di integrità del soggetto.

Assegnando sempre etichette obbligatorie per elaborare, thread, token e oggetti processo, il meccanismo di integrità impedisce ai processi per lo stesso utente a livelli di integrità inferiori di accedere a questi tipi di oggetto e di modificarne il contenuto o il comportamento, ad esempio l'inserimento di una DLL o la rappresentazione di un token di accesso di livello superiore.

Livello di integrità predefinito

Non a tutti i tipi di oggetto viene assegnata un'etichetta ACE obbligatoria nel descrittore di sicurezza. Se nel descrittore di sicurezza è presente un'etichetta obbligatoria ACE, questa viene definita etichetta obbligatoria esplicita. Se non è presente alcuna etichetta obbligatoria ACE, il sottosistema di sicurezza usa un'etichetta obbligatoria predefinita implicita per tale oggetto durante il controllo dei criteri obbligatori. L'etichetta obbligatoria predefinita assegna un livello di integrità medio per tutti gli oggetti a protezione diretta. Se un'etichetta obbligatoria non è definita nel descrittore di sicurezza, l'etichetta obbligatoria predefinita implicita si applica a tutti i tipi di oggetto.

Il livello di integrità dell'oggetto predefinito, combinato con il criterio obbligatorio predefinito di NO_WRITE_UP, limita l'accesso a tutti gli oggetti tramite processi con un livello di integrità del soggetto inferiore al medio. L'etichetta e i criteri obbligatori predefiniti impediscono ai processi non attendibili a un'integrità bassa di modificare qualsiasi utente, file di sistema o chiavi del Registro di sistema nel sistema che potrebbero altrimenti consentire l'accesso discrezionale in scrittura nell'elenco dacl.

Gli oggetti del file system NTFS e le chiavi del Registro di sistema non vengono etichettati automaticamente al momento della creazione. Questi oggetti non hanno etichette obbligatorie dopo l'aggiornamento da una versione precedente di Windows a Windows Vista. I file nei file system non NTFS (CDFS o FAT32) che non dispongono di descrittori di sicurezza non sono oggetti a protezione diretta e non hanno un livello di integrità. Ogni descrittore di sicurezza deve avere un'etichetta obbligatoria implicita.

Elabora con un livello di integrità del soggetto al livello di integrità di o superiore al livello medio di creazione di file e chiavi del Registro di sistema senza un'etichetta esplicita. Di conseguenza, il file system e gli oggetti del Registro di sistema creati da un processo di integrità elevata o di sistema hanno un'etichetta media implicita. Le applicazioni che usano etichette obbligatorie possono definire etichette esplicite durante la creazione di oggetti. Tuttavia, Windows Vista non assegna etichette superiori al livello di integrità medio al file system o al Registro di sistema per impostazione predefinita. Ciò non significa che questi oggetti sono necessariamente aperti alla modifica da processi di integrità inferiore. L'elenco di controllo di accesso discrezionale ereditato (o predefinito) nei file system o negli oggetti del Registro di sistema creati da un processo di alto o livello di sistema concede l'accesso in scrittura solo ai membri del gruppo Administrators o agli account del sistema o del servizio locali.

Per la maggior parte dei tipi di oggetto, è necessario utilizzare l'etichetta implicita predefinita obbligatoria del supporto anziché assegnare un'etichetta obbligatoria esplicita in base al livello di integrità del soggetto. Un esempio specifico si basa sulla possibilità di abilitare o disabilitare il controllo dell'account utente usando i criteri di sicurezza locali. Quando controllo dell'account utente è disabilitato, un utente membro del gruppo Administrators locale dispone di tutti i processi in esecuzione con un token di accesso con privilegi completi a un livello di integrità elevato. Se tutti gli oggetti vengono etichettati in modo esplicito a livello di integrità dell'oggetto, a tutti i file, ad esempio documenti e fogli di calcolo creati dall'utente, viene assegnato un livello di integrità elevato. L'etichetta alta sembra appropriata, anche se le autorizzazioni DACL ereditate per il profilo utente forniscono un controllo di accesso sufficiente per l'accesso utente. Tuttavia, se controllo dell'account utente è abilitato dal computer locale o Criteri di gruppo, alla maggior parte dei processi eseguiti dallo stesso utente viene assegnato un token di accesso di sicurezza filtrato a un livello di integrità medio. Dopo l'abilitazione di Controllo dell'account utente, l'utente non sarà in grado di aprire i file creati quando controllo dell'account utente è stato disabilitato. Un'applicazione di integrità media che ha tentato di aprire i documenti ad alta integrità dell'utente riceve un errore di accesso negato.

Se un processo viene eseguito con un livello di integrità del soggetto inferiore al livello di integrità predefinito del supporto, tale processo avrà autorizzazioni di accesso limitato a tutti gli oggetti con un livello di integrità medio implicito. I processi con un livello di integrità basso non potranno modificare alcun oggetto con un livello di integrità esplicito o implicito medio o superiore, indipendentemente dai diritti di accesso concessi nell'elenco di controllo di accesso all'entità di sicurezza. Di conseguenza, tutti gli oggetti creati da un processo con un livello di integrità del soggetto inferiore al livello predefinito (medio) vengono etichettati in modo esplicito dal sottosistema di sicurezza. Le restrizioni di accesso per i processi di integrità bassa sono possibili in Windows Vista perché tutte le applicazioni vengono in genere eseguite a livello di integrità media e i problemi di compatibilità delle applicazioni sono minimi. Le applicazioni eseguite correttamente a bassa integrità richiedono in genere modifiche di progettazione specifiche per funzionare correttamente con accesso limitato. Le modifiche di progettazione sono descritte nella sezione seguente sulla progettazione di applicazioni da eseguire a un livello di integrità basso.

Etichettatura di oggetti creati da soggetti bassi

Le applicazioni possono essere avviate usando la funzione CreateProcessAsUser a un livello di integrità basso. Un processo basso viene inizializzato da CreateProcessAsUser con le informazioni seguenti sul livello di integrità:

  • Il nuovo oggetto processo viene creato con un descrittore di sicurezza contenente un'etichetta obbligatoria con bassa integrità.
  • Viene creato un nuovo oggetto thread per tale processo e con un descrittore di sicurezza che contiene un'etichetta obbligatoria con bassa integrità.
  • Al nuovo processo viene assegnato un token di accesso primario. L'oggetto token di accesso ha un descrittore di sicurezza con un'etichetta obbligatoria bassa e il token di accesso contiene un TokenIntegrityLevel con un SID di integrità basso che rappresenta il livello di integrità del soggetto.

Si supponga che il processo di integrità basso sia in esecuzione e che voglia creare un thread. Per creare un thread, è necessario aprire il proprio oggetto processo per l'accesso in scrittura per creare un nuovo oggetto thread. Se l'etichetta obbligatoria nell'oggetto processo fosse media, l'oggetto basso non aprirà il processo e non riuscirebbe a creare un nuovo thread. Poiché l'oggetto processo è etichettato anche a bassa integrità, il soggetto basso può aprire il processo per l'accesso in scrittura e creare un nuovo oggetto thread. L'esempio mostra perché è importante che le etichette obbligatorie nell'oggetto processo, negli oggetti thread e nel token di accesso alla sicurezza siano coerenti allo stesso livello di integrità.

Nota

Questo vale per tutti i livelli di integrità, non solo per i soggetti bassi.

Si supponga che il processo basso crei un file temporaneo. L'applicazione chiama CreateFile per creare un nuovo file, scrivere alcuni dati e chiudere il file. Successivamente, il processo basso vuole riaprire lo stesso file per accodare i dati. Se il file temporaneo ha un'etichetta obbligatoria implicita predefinita a livello di integrità media, il processo basso non sarà in grado di riaprire il file creato in precedenza per modificare l'accesso. Lo stesso problema potrebbe verificarsi per qualsiasi oggetto a protezione diretta creato da un soggetto con un livello di integrità inferiore al livello predefinito del supporto. Di conseguenza, a tutti gli oggetti a protezione diretta creati da un soggetto con un livello di integrità inferiore al livello predefinito viene assegnata automaticamente un'etichetta obbligatoria esplicita. In altre parole, tutti gli oggetti kernel, le chiavi del Registro di sistema e gli oggetti del file system vengono etichettati in modo esplicito quando il livello di integrità del soggetto è basso.

Come creare un oggetto con un'etichetta obbligatoria specifica

La maggior parte delle applicazioni Windows non deve essere "compatibile con l'integrità". Il sottosistema di sicurezza crea automaticamente gli oggetti e li assegna un'etichetta obbligatoria. Poiché la maggior parte delle applicazioni viene eseguita a un livello di integrità medio e il livello di integrità dell'oggetto predefinito è medio, i criteri di integrità non modificano il controllo di accesso consentito per la maggior parte delle applicazioni. Tuttavia, alcune applicazioni, ad esempio i servizi, sono progettate per supportare le applicazioni client a livelli di integrità diversi. Il servizio potrebbe essere in esecuzione a un livello di integrità superiore rispetto al client e potrebbe voler etichettare nuovi oggetti creati per conto del client in modo esplicito a un livello di integrità inferiore. Il livello di integrità dell'oggetto può essere impostato dal processo di creazione. Il vincolo è che il livello di integrità del nuovo oggetto deve essere minore o uguale al livello di integrità del processo di creazione.

Per creare un oggetto con un'etichetta obbligatoria specifica
  1. Creare un descrittore di sicurezza SDDL che definisce un'etichetta bassa obbligatoria, ad esempio:
    #define LOW_INTEGRITY_SDDL_SACL_W L"S:(ML;;NW;;;LW)"
  2. Convertire la stringa SDDL in un descrittore di sicurezza usando ConvertStringSecurityDescriptorToSecurityDescriptor.
  3. Assegnare il descrittore di sicurezza con l'etichetta bassa obbligatoria a una struttura degli attributi di sicurezza.
  4. Passare il parametro degli attributi di sicurezza alla chiamata per creare un oggetto, ad esempio CreateFile.

Ereditarietà dell'etichetta obbligatoria

Windows Vista non etichetta in modo esplicito i file e le directory nel file system NTFS. Come accennato in precedenza, il sottosistema di sicurezza usa un'etichetta obbligatoria implicita con un livello predefinito di media per gli oggetti che non hanno un'etichetta obbligatoria nel descrittore di sicurezza.

Le applicazioni possono essere progettate per l'esecuzione a un livello di integrità basso. La modalità protetta Internet Explorer è un esempio di un'applicazione Windows Vista progettata per l'esecuzione a bassa integrità. Le applicazioni a bassa integrità potrebbero richiedere cartelle nel file system in cui possono scrivere file temporanei o dati dell'applicazione. Nel caso di Internet Explorer in modalità protetta, viene usata la cartella File Internet temporanea nel profilo dell'utente. In che modo un'applicazione bassa può scrivere in una cartella del file system? La cartella deve essere assegnata a un'etichetta obbligatoria esplicita che consente l'accesso in scrittura da un processo di integrità ridotto.

A seconda della progettazione dell'applicazione, potrebbero essere presenti altri processi di collaborazione che aggiungono file alla cartella usata dall'applicazione a bassa integrità. Se gli altri processi vengono eseguiti anche a bassa integrità, i file creati da tali processi vengono assegnati automaticamente un'etichetta obbligatoria bassa. Tuttavia, se l'altro processo partner ha un'integrità maggiore, il processo partner (un servizio di sincronizzazione file o un agente utente) potrebbe creare file nella cartella bassa che non vengono etichettati automaticamente a basso. Il processo partner crea un file medio nella cartella utilizzata dall'applicazione bassa, che l'applicazione bassa non può modificare o eliminare.

Il meccanismo di integrità consente a una cartella con un'etichetta obbligatoria bassa di avere oggetti, file e sottocartelle figlio, ognuno con un'etichetta obbligatoria diversa e superiore perché ogni oggetto file system ha un descrittore di sicurezza univoco. Esistono molti scenari in cui l'intenzione è che, per una cartella assegnata a un'etichetta obbligatoria bassa, tutti i file nella cartella devono essere assegnati un'etichetta obbligatoria bassa in modo che un processo basso possa modificarli. Il meccanismo di integrità supporta questa operazione consentendo agli ACL di etichetta obbligatori di ereditare dal contenitore padre a contenitori secondari e oggetti figlio.

La struttura dati del tipo ACE di etichetta obbligatoria contiene un'intestazione ACE con un campo AceFlags. Il campo AceFlags viene usato per definire i flag di ereditarietà per il tipo ACE che corrispondono ai flag di ereditarietà per altri tipi ACE, ad esempio il tipo ACE consentito di accesso utilizzato per l'accesso discrezionale. Gli ACL dell'etichetta obbligatoria possono essere definiti come ereditabili per l'eredita del contenitore (CI) e/o l'eredita dell'oggetto (OI). Non è possibile inherit_only (I/O) dell'etichetta obbligatoria. Se è presente un ace di etichetta obbligatoria ereditabile assegnato a un contenitore, l'etichetta obbligatoria si applica al contenitore stesso e agli oggetti figlio per cui si applica l'ereditarietà.

Un esempio di etichetta obbligatoria ereditabile è l'etichetta obbligatoria bassa in una delle cartelle create in ogni profilo utente: %USERPROFILE%\AppData\LocalLow. Questa cartella viene assegnata un'etichetta obbligatoria ridotta quando il profilo viene inizializzato e destinato come cartella di primo livello che è scrivibile per impostazione predefinita da applicazioni a bassa integrità. L'immagine seguente mostra l'etichetta obbligatoria ereditabile nella cartella AppData\LocalLow visualizzata usando il comando Icacls. Per altre informazioni sul modo in cui Icacls supporta le etichette obbligatorie, vedere Appendice B: Icacls e Livelli di integrità dei file.

I flag di ereditarietà nell'etichetta obbligatoria indicano che l'ACE è (OI) e (CI) ACE con un criterio obbligatorio NO_WRITE_UP (NW). Tutte le sottocartelle create nella cartella AppData\LocalLow erediteranno l'etichetta ereditabile.

Figura 4 Etichetta bassa obbligatoria ereditabile

Quando viene creato un nuovo file o una sottocartella da un processo medio, il nuovo oggetto eredita l'etichetta obbligatoria bassa. Nell'esempio seguente il prompt dei comandi viene eseguito nel processo con livello di integrità medio. Un file, newfile.txt e una nuova cartella, Temp, viene creata nella cartella LocalLow e entrambi gli oggetti ereditano l'etichetta obbligatoria bassa dal contenitore padre. Icacls indica che l'etichetta obbligatoria viene ereditata con la designazione (I).

Figura 5 Ereditare un'etichetta obbligatoria in un oggetto figlio

L'ereditarietà per le etichette obbligatorie garantisce la coerenza nel livello di integrità di oggetti creati in una parte dello spazio dei nomi del file system.

Ereditarietà e etichette esplicite

Gli oggetti creati in un contenitore con un'etichetta obbligatoria ereditabile ereditano l'etichetta obbligatoria dal contenitore. Tuttavia, il processo che crea un nuovo oggetto, ad esempio un file, può fornire un'etichetta obbligatoria esplicita nel parametro attributi di sicurezza per la funzione di creazione, ad esempio CreateFile.

Se il processo di creazione fornisce un'etichetta esplicita come parametro per la funzione di creazione dell'oggetto, il nuovo oggetto viene assegnato all'etichetta obbligatoria esplicita fornita dal chiamante e non eredita dal contenitore padre. L'etichetta obbligatoria esplicita può avere un livello di integrità non superiore al processo soggetto che crea l'oggetto. Il livello di integrità nell'etichetta obbligatoria esplicita fornita dall'oggetto potrebbe essere superiore al livello di integrità nell'etichetta obbligatoria ereditabile del contenitore padre.

Restrizione solo eredita

Eredita solo (I/O) è un flag in una voce di controllo di accesso che indica che l'ACE non controlla l'accesso all'oggetto a cui è collegato. Gli ACL ereditabili vengono in genere assegnati agli oggetti contenitore. L'ace di sola eredita non è efficace nel contenitore stesso; si applica invece agli oggetti figlio del contenitore. Esiste una restrizione per i soggetti con un livello di integrità minore del valore predefinito per l'impostazione delle etichette INHERIT_ONLY sui nuovi oggetti. Se l'etichetta esplicita passata per un nuovo oggetto contenitore è un'etichetta INHERIT_ONLY con un livello minore del valore predefinito, l'etichetta viene considerata non valida e ignorata. La logica per questa restrizione è che un soggetto basso crea un contenitore e tenta di impostare un'etichetta INHERIT_ONLY sul contenitore a basso. Se l'etichetta INHERIT_ONLY è stata accettata, il livello di integrità effettivo per il contenitore sarebbe il livello predefinito implicito di media.

Inoltre, i soggetti non possono definire un'etichetta INHERIT_ONLY con un livello di integrità superiore al livello di integrità del soggetto. Ad esempio, un soggetto medio non può definire un'etichetta INHERIT_ONLY con un livello di integrità elevato.

Ereditarietà SACL e etichetta protetta

SDDL supporta la definizione di un SACL protetto, che potrebbe includere un'etichetta obbligatoria esplicita. SacL protetto imposta il flag di SE_SACL_PROTECTED nel campo SECURITY_DESCRIPTOR_CONTROL del descrittore di sicurezza. La separazione logica di LABEL_SECURITY_INFORMATION e SACL_SECURITY_INFORMATION rispetto ai diritti di accesso non è completa rispetto al comportamento di un SACL protetto. Le etichette obbligatorie vengono archiviate in SACL. Un SACL protetto implica che l'etichetta obbligatoria sia protetta anche.

Se il flag di SE_SACL_PROTECTED è impostato nella SECURITY_DESCRIPTOR_CONTROL, l'etichetta obbligatoria è protetta anche.

  • Se non è presente alcuna etichetta obbligatoria ACE nel SACL protetto, un'etichetta obbligatoria ereditabile ace dal contenitore non viene applicata (il nuovo oggetto ha un'etichetta obbligatoria predefinita implicita).
  • Se è presente un'etichetta obbligatoria ACE in SACL protetta, le modifiche apportate all'etichetta ereditabile ACE nel contenitore non influiscono su questo oggetto.

Per altre informazioni su SDDL, vedere Appendice A: SDDL per etichette obbligatorie o risorse del meccanismo di integrità di Windows.

Funzionamento dei controlli di accesso con criteri obbligatori

La funzione AccessCheck applica i criteri obbligatori. AccessCheck confronta il descrittore di sicurezza specificato con il token di accesso specificato e indica, nel parametro AccessStatus , se l'accesso viene concesso o negato. La funzione AccessCheck confronta prima il livello di integrità in ClientToken con l'etichetta obbligatoria nel SACL di pSecurityDescriptor per determinare quali diritti di accesso non sono disponibili, in base ai criteri obbligatori. Dopo il controllo dei criteri obbligatori, AccessCheck confronta l'accesso desiderato rispetto ai diritti di accesso concessi nell'elenco di controllo dati.

Il criterio obbligatorio predefinito impedisce ai processi di integrità inferiore di ottenere l'accesso in scrittura generico agli oggetti di integrità superiore. Per impostazione predefinita, ad esempio, viene negato l'accesso generico in scrittura a un oggetto con un livello di integrità superiore. Se pSecurityDescriptor non contiene un ACE obbligatorio, si presuppone che un ACE implicito assegna all'oggetto un livello di integrità medio. Il parametro GenericMapping determina quali diritti di accesso sono associati all'accesso in scrittura generico. Se il parametro GenericMapping è tutto zero, il controllo di integrità non concederà diritti di accesso specifici a un clientToken di integrità inferiore. Dopo il controllo di integrità determina i diritti di accesso generici disponibili per il chiamante in base ai criteri obbligatori, il descrittore di sicurezza viene confrontato con ClientToken per determinare i diritti di accesso concessi rimanenti.

Isolamento dei privilegi dell'interfaccia utente (UIPI) e integrità

L'isolamento dei privilegi dell'interfaccia utente implementa le restrizioni nel sottosistema windows che impedisce l'invio di messaggi di finestra o l'installazione di hook nei processi con privilegi più elevati. Le applicazioni con privilegi più elevati sono consentite per inviare messaggi di finestra ai processi con privilegi inferiori. Le restrizioni vengono implementate nelle funzioni di messaggio sendMessage e relative. Non tutti i messaggi di finestra inviati da un processo con privilegi inferiori a un processo con privilegi superiori vengono bloccati. In genere, i messaggi di tipo "read", ad esempio WM_GETTEXT, possono essere inviati da un privilegio inferiore a una finestra con privilegi più elevati. Tuttavia, vengono bloccati i messaggi di tipo, ad esempio WM_SETTEXT.

Il livello dei privilegi dell'interfaccia utente è a livello di processo e si applica a tutte le finestre create dal processo. Il sottosistema USER inizializza quando il processo effettua la prima chiamata all'interfaccia del dispositivo grafica Windows (GDI). Durante l'inizializzazione del processo, il sottosistema USER chiama nel sottosistema di sicurezza per determinare il livello di integrità assegnato nel token di accesso di sicurezza primario del processo. Dopo che il sottosistema USER imposta il livello di privilegi dell'interfaccia utente durante l'inizializzazione del processo, non cambia. L'impostazione di TokenIntegrityLevel per un thread su un valore inferiore non influisce sul livello dei privilegi dell'interfaccia utente del processo o di qualsiasi finestra aperta da tale processo o thread.

UIPI non interferisce con o modifica il comportamento della messaggistica delle finestre tra applicazioni allo stesso livello di privilegi (o integrità). UIPI impedisce ai processi con privilegi inferiori di accedere ai processi con privilegi più elevati bloccando il comportamento seguente. Un processo con privilegi inferiori non può:

  • Eseguire una convalida dell'handle della finestra di un processo in esecuzione con diritti superiori.
  • Usare SendMessage o PostMessage per le finestre dell'applicazione in esecuzione con diritti superiori. Queste API restituiscono esito positivo ma eliminano in modo automatico il messaggio della finestra.
  • Usare i thread hook per collegare un processo in esecuzione con diritti superiori.
  • Usare gli hook del journal per monitorare un processo in esecuzione con diritti più elevati.
  • Eseguire l'inserimento della libreria di collegamento dinamica (DLL) in un processo in esecuzione con diritti superiori.

Con l'interfaccia utente abilitata, le risorse UTENTE condivise seguenti sono ancora condivise tra processi a livelli di privilegi diversi.

  • Finestra desktop, che possiede effettivamente la superficie dello schermo
  • Memoria condivisa di sola lettura desktop
  • Tabella atom globale
  • Appunti

Il disegno sullo schermo è un'altra azione che non è bloccata da UIPI. Il modello GDI (USER/graphics device interface) non consente il controllo sulle superfici di disegno. Pertanto, è possibile che un'applicazione in esecuzione con un minor numero di diritti di disegnare sulla superficie della finestra dell'applicazione per un'applicazione in esecuzione con diritti più elevati.

UIAccess per applicazioni di automazione interfaccia utente

Automazione interfaccia utente Microsoft è il modello di Windows Vista per supportare i requisiti di accessibilità con miglioramenti rispetto al modello precedente, noto come Microsoft Active Accessibility (MSAA). Le applicazioni progettate per supportare l'esperienza utente accessibile controllano il comportamento di altre applicazioni Windows per conto dell'utente. Quando tutte le applicazioni (client di automazione e server) vengono eseguite come utente standard, ovvero a livello di integrità media, le restrizioni UIPI non interferiscono con il modello di automazione dell'interfaccia utente.

Tuttavia, potrebbe verificarsi un momento in cui un utente amministrativo esegue un'applicazione con privilegi elevati in base all'interfaccia utente in Amministrazione modalità approvazione. Il programma di automazione interfaccia utente non sarà in grado di guidare l'interfaccia utente grafica di applicazioni elevate sul desktop senza la possibilità di ignorare le restrizioni implementate dall'interfaccia utente. La possibilità di ignorare le restrizioni UIPI su SendMessage tra i livelli di privilegi è disponibile per i programmi di automazione interfaccia utente usando un attributo di sicurezza speciale nel manifesto dell'applicazione del programma, noto come UIAccess.

Di seguito è riportato un esempio di voce del manifesto dell'applicazione per un programma UIAccess.

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> 
  <security> 
    <requestedPrivileges> 
    <requestedExecutionLevel 
      level="asInvoker" 
      UIAccess="true" /> 
    </requestedPrivileges> 
  </security> 
</trustInfo>

Specificando UIAccess="true" nell'attributo requestedPrivileges, l'applicazione indica un requisito per ignorare le restrizioni UIPI per l'invio di messaggi di finestra tra livelli di privilegi. Windows Vista implementa i criteri seguenti prima di avviare un'applicazione con privilegi UIAccess.

  • L'applicazione deve avere una firma digitale che può essere verificata usando un certificato digitale che concatena fino a una radice attendibile nell'archivio certificati autorità di certificazione radice attendibile del computer locale.
  • L'applicazione deve essere installata in una directory dell'applicazione di cartelle locale che è scrivibile solo dagli amministratori, ad esempio la directory Programmi. Le directory consentite per le applicazioni di automazione interfaccia utente sono le seguenti:
    • %Programmi% e le sue sottodirectory.
    • %WINDIR% e le sue sottodirectory, ad eccezione di alcune sottodirectory escluse perché gli utenti standard hanno accesso in scrittura.

Le sottodirectory %WinDir% escluse includono:

  • \Debug
  • \Pchealth
  • \Registrazione
  • \System32\ccm
  • \System32\com
  • \System32\FxsTmp
  • \System32\Spool
  • \System32\Tasks

Windows Vista fornisce un'impostazione di sicurezza per i criteri del computer locale e per Criteri di gruppo modificare il requisito che i programmi UIAccess devono essere avviati da posizioni sicure. L'impostazione è definita in Opzioni di sicurezza in Criteri locali per i criteri di sicurezza locali. I criteri di sicurezza sono i seguenti:

Controllo account utente: solo applicazioni con accesso all'interfaccia utente e con privilegi elevati installate in percorsi sicuri

Per impostazione predefinita, questa impostazione è abilitata. Tuttavia, un amministratore può disabilitarlo se esistono situazioni in cui le applicazioni UIAccess (Tecnologia accessibile) che devono essere avviate dalle cartelle non sono protette dall'accesso in scrittura solo amministratore.

Se l'applicazione di automazione interfaccia utente che richiede UIAccess soddisfa i requisiti dell'impostazione UIAccess, Windows Vista avvia l'applicazione con la possibilità di ignorare la maggior parte delle restrizioni UIPI. Se l'applicazione di automazione interfaccia utente non soddisfa le restrizioni di sicurezza, l'applicazione verrà avviata senza diritti UIAccess e può interagire solo con le applicazioni allo stesso livello di privilegi o inferiore.

Processo avviato con diritti UIAccess:

  • Ha la possibilità di impostare la finestra in primo piano.
  • Può guidare qualsiasi finestra dell'applicazione usando la funzione SendInput.
  • Ha input di lettura per tutti i livelli di integrità usando hook di basso livello, input non elaborato, GetKeyState, GetAsyncKeyState e GetKeyboardInput.
  • Può impostare hook del journal.
  • Usa AttachThreadInput per collegare un thread a una coda di input di integrità superiore

Le applicazioni avviate con diritti UIAccess per un utente standard vengono assegnate un valore di integrità leggermente superiore nel token di accesso. Il livello di integrità del token di accesso per l'applicazione UIAccess per un utente standard è il valore di livello di integrità medio, oltre a un incremento di 0x10. Il livello di integrità superiore per le applicazioni UIAccess impedisce ad altri processi nello stesso desktop a livello di integrità medio di aprire l'oggetto processo UIAccess.