Applicazione dei descrittori di sicurezza nell'oggetto Device

La maggior parte dei driver usa i controlli di accesso applicati dal gestore di I/O rispetto agli oggetti dispositivo per proteggersi dall'accesso inappropriato. L'approccio più semplice per la maggior parte dei driver consiste nell'applicare un descrittore di sicurezza esplicito quando viene installato il driver. In un file INF tali descrittori di sicurezza sono descritti dalla voce "Sicurezza" nella sezione AddReg. Per altre informazioni sul linguaggio completo usato per descrivere i descrittori di sicurezza, vedere Security Descriptor Definition Language nella documentazione di Microsoft Windows SDK.

Il formato di base di un descrittore di sicurezza che usa il linguaggio SDDL (Security Descriptor Definition Language) include le parti distinte seguenti di un descrittore di sicurezza standard:

• SID del proprietario.

• Il gruppo SID.

• Elenco di controllo di accesso discrezionale (DACL).

• Elenco di controllo di accesso di sistema (SACL).

Di conseguenza, la descrizione all'interno di uno script INF per un descrittore di sicurezza è:

O:owner-sidG:group-sidD:dacl-flags(ace)(ace)S:sacl-flags(ace)(ace)

Le singole voci di controllo di accesso descrivono l'accesso da concedere o negare a un determinato gruppo o utente, come specificato dall'identificatore di sicurezza (SID). Ad esempio, un file INF potrebbe contenere una riga, ad esempio:

"D:P(A;CI;GR;;;BU)(A;CI;GR;;;PU)(A;CI;GA;;;BA)(A;CI;GA;;;SY)(A;CI;GA;;;NS)(A;CI;GA;;;LS)(A;CI;CCDCLCSWRPSDRC;;;S-1-5-32-556)"

L'esempio precedente proviene da un NETTCPIP. File INF da un sistema Microsoft Windows XP Service Pack 1 (SP1).

In questa istanza non è specificato alcun proprietario o gruppo, quindi per impostazione predefinita vengono utilizzati i valori predefiniti. Il D indica che si tratta di un DACL. Il P indica che si tratta di un ACL protetto e non eredita diritti dal descrittore di sicurezza dell'oggetto contenitore. L'ACL protetto impedisce che una sicurezza più indulgente sul genitore venga ereditata. L'espressione tra parentesi indica una singola voce di controllo di accesso (ACE). Una voce di controllo di accesso che utilizza l'SDDL è costituita da diversi, distinti componenti separati da punto e virgola. In ordine, sono i seguenti:

• Indicatore di tipo per ACE. Esistono quattro tipi univoci per i DACL e quattro tipi diversi per i SACL.

• Campo flags utilizzato per descrivere l'ereditarietà di questo ACE per oggetti figlio o i criteri di controllo e allarme per i SACL.

• Il campo diritti indica quali diritti vengono concessi o negati dall'ACE. Questo campo può specificare un valore numerico specifico che indica i diritti generici, standard e specifici applicabili a questa ace o usare una descrizione di stringa dei diritti di accesso comuni.

• Un GUID dell'oggetto se il DACL è una struttura ACE specifica per l'oggetto.

• GUID dell'oggetto ereditato se il DACL è una struttura ACE specifica dell'oggetto

• Un SID che indica l'entità di sicurezza a cui si applica questa ACE.

Pertanto, interpretando il descrittore di sicurezza di esempio, "A" che precede l'ACE indica che si tratta di una voce "accesso consentito". L'alternativa è una voce "accesso negato", che viene usata raramente e viene indicata da un carattere "D" iniziale. Il campo flags specifica Container Inherit (CI), che indica che questa ACE viene ereditata da sub-oggetti.

I valori dei campi diritti codificano diritti specifici che includono diritti generici e diritti standard. Ad esempio, "GR" indica l'accesso in lettura generico e "GA" indica l'accesso "generico a tutti", entrambi diritti generici. Un certo numero di diritti speciali segue questi diritti generici. Nell'esempio precedente" "CC" indica la creazione dell'accesso figlio, specifico per i diritti di file e directory. L'esempio precedente include anche altri diritti standard dopo la stringa "CC", tra cui "DC" per l'accesso eliminazione figlio, "LC" per elenco accesso figlio, "SW" per l'accesso ai diritti personali, "RP" per l'accesso alle proprietà di lettura, "SD" per l'accesso all'eliminazione standard e "RC" per l'accesso di controllo lettura.

Le stringhe di immissione SID nell'esempio precedente includono "PU" per gli utenti esperti, "BU" per gli utenti predefiniti, "BA" per gli amministratori predefiniti, "LS" per l'account del servizio locale, "SY" per il sistema locale e "NS" per l'account del servizio di rete. Quindi, nell'esempio precedente, agli utenti viene concesso l'accesso generico in lettura sull'oggetto. Al contrario, agli amministratori predefiniti, all'account del servizio locale, al sistema locale e al servizio di rete viene concesso l'accesso generico (lettura, scrittura ed esecuzione). Il set completo di tutti i diritti possibili e le stringhe SID standard sono documentati in Windows SDK.

Questi elenchi di controllo di accesso verranno applicati a tutti gli oggetti dispositivo creati da un determinato driver. Un driver può anche controllare le impostazioni di sicurezza di oggetti specifici usando la nuova funzione IoCreateDeviceSecure durante la creazione di un oggetto dispositivo denominato. La funzione IoCreateDeviceSecure è disponibile in Windows XP Service Pack 1 e Windows Server 2003 e versioni successive. Usando IoCreateDeviceSecure, il descrittore di sicurezza da applicare all'oggetto dispositivo viene descritto usando un subset del linguaggio di definizione del descrittore di sicurezza completo appropriato per gli oggetti dispositivo.

Lo scopo dell'applicazione di descrittori di sicurezza specifici agli oggetti dispositivo consiste nel garantire che vengano eseguiti controlli di sicurezza appropriati sul dispositivo ogni volta che un'applicazione tenta di accedere al dispositivo stesso. Per gli oggetti dispositivo che contengono una struttura dei nomi (ad esempio lo spazio dei nomi di un file system), i dettagli relativi alla gestione dell'accesso a questo spazio dei nomi del dispositivo appartengono al driver, non al gestore di I/O.

Un problema interessante in questi casi è come gestire la sicurezza al limite tra il gestore di I/O responsabile del controllo dell'accesso all'oggetto dispositivo driver e al driver di dispositivo, che implementa i criteri di sicurezza appropriati per il driver. Tradizionalmente, se l'oggetto aperto è il nome del dispositivo stesso, il gestore di I/O eseguirà un controllo di accesso completo sull'oggetto dispositivo direttamente usando il descrittore di sicurezza. Tuttavia, se l'oggetto aperto indica un percorso all'interno del driver stesso, il gestore di I/O verificherà solo che l'accesso di attraversamento sia concesso all'oggetto dispositivo. In genere, questo diritto di attraversamento viene concesso perché la maggior parte dei thread ha ricevuto il privilegio SeChangeNotifyPrivilege, che corrisponde alla concessione del diritto di attraversamento della directory. Un dispositivo che non supporta la struttura dei nomi richiede normalmente che il gestore di I/O esegua un controllo di sicurezza completo. Questa operazione viene eseguita impostando il bit FILE_DEVICE_SECURE_OPEN nel campo caratteristiche del dispositivo. Un driver che include una combinazione di tali oggetti dispositivo deve impostare questa caratteristica per i dispositivi che non supportano la struttura dei nomi. Ad esempio, un file system imposta questa opzione sull'oggetto dispositivo denominato (che non supporta una struttura di denominazione), ma non imposta questa opzione sugli oggetti dispositivo senza nome ,ad esempio un volume, che supportano la struttura di denominazione. Se non si imposta correttamente questo bit, si tratta di un bug comune nei driver e può consentire l'accesso inappropriato al dispositivo. Per i driver che usano l'interfaccia degli allegati (IoAttachDeviceToDeviceStackSafe, ad esempio), il bit FILE_DEVICE_SECURE_OPEN viene impostato se questo campo è impostato nel dispositivo a cui è collegato il driver. Pertanto, i driver di filtro non devono preoccuparsi di questo particolare aspetto del controllo di sicurezza.