Diritti di accesso e sicurezza dei file
Poiché i file sono oggetti a protezione diretta, l'accesso è regolamentato dal modello di controllo di accesso che regola l'accesso a tutti gli altri oggetti a protezione diretta in Windows. Per una spiegazione dettagliata di questo modello, vedere Controllo di accesso.
È possibile specificare un descrittore di sicurezza per un file o una directory quando si chiama la funzione CreateFile, CreateDirectory o CreateDirectoryEx. Se si specifica NULL per il parametro lpSecurityAttributes , il file o la directory ottiene un descrittore di sicurezza predefinito. Gli elenchi di controllo di accesso (ACL) nel descrittore di sicurezza predefinito per un file o una directory vengono ereditati dalla directory padre. Si noti che un descrittore di sicurezza predefinito viene assegnato solo quando viene appena creato un file o una directory e non quando viene rinominato o spostato.
Per recuperare il descrittore di sicurezza di un file o di un oggetto directory, chiamare la funzione GetNamedSecurityInfo o GetSecurityInfo. Per modificare il descrittore di sicurezza di un file o di un oggetto directory, chiamare la funzione SetNamedSecurityInfo o SetSecurityInfo.
I diritti di accesso validi per file e directory includono i diritti di accesso standard DELETE, READ_CONTROL, WRITE_DAC, WRITE_OWNER e SYNCHRONIZE standard. La tabella in Costanti diritti di accesso file elenca i diritti di accesso specifici per file e directory.
Anche se il diritto di accesso SYNCHRONIZE è definito all'interno dell'elenco dei diritti di accesso standard come diritto di specificare un handle di file in una delle funzioni di attesa, quando si utilizzano operazioni di I/O di file asincrone, è necessario attendere l'handle di evento contenuto in una struttura OVERLAPPED configurata correttamente anziché usare l'handle di file con il diritto di accesso SYNCHRONIZE per la sincronizzazione.
Di seguito sono riportati i diritti di accesso generico per file e directory.
| Diritto di accesso | Descrizione |
|---|---|
| FILE_GENERIC_EXECUTE |
FILE_READ_ATTRIBUTES STANDARD_RIGHTS_EXECUTE SINCRONIZZARE |
| FILE_GENERIC_READ |
FILE_READ_DATA FILE_READ_EA STANDARD_RIGHTS_READ SINCRONIZZARE |
| FILE_GENERIC_WRITE |
FILE_WRITE_ATTRIBUTES FILE_WRITE_DATA FILE_WRITE_EA STANDARD_RIGHTS_WRITE SINCRONIZZARE |
Windows confronta i diritti di accesso richiesti e le informazioni nel token di accesso del thread con le informazioni contenute nel descrittore di sicurezza del file o dell'oggetto directory. Se il confronto non impedisce la concessione di tutti i diritti di accesso richiesti, viene restituito un handle all'oggetto e vengono concessi i diritti di accesso. Per altre informazioni su questo processo, vedere Interazione tra thread e oggetti a protezione diretta.
Per impostazione predefinita, l'autorizzazione per l'accesso a un file o a una directory è controllata rigorosamente dagli elenchi di controllo di accesso nel descrittore di sicurezza associato a tale file o directory. In particolare, il descrittore di sicurezza di una directory padre non viene usato per controllare l'accesso a qualsiasi file o directory figlio. Il diritto di accesso FILE_TRAVERSE può essere applicato rimuovendo il privilegio BYPASS_TRAVERSE_CHECKING dagli utenti. Questo non è consigliato nel caso generale, poiché molti programmi non gestiscono correttamente gli errori di attraversamento della directory. L'uso principale per il diritto di accesso FILE_TRAVERSE nelle directory consiste nell'abilitare la conformità a determinati standard IEEE e ISO POSIX quando l'interoperabilità con i sistemi Unix è un requisito.
Il modello di sicurezza di Windows consente a una directory figlio di ereditare o di ereditare uno o più degli ACL nel descrittore di sicurezza della directory padre. Ogni ACE contiene informazioni che determinano come possono essere ereditate e se avranno un effetto sull'oggetto directory che eredita. Ad esempio, alcuni ACL ereditati controllano l'accesso all'oggetto directory ereditato e questi sono denominati ACL effettivi. Tutti gli altri ACL sono denominati ACL di sola eredita.
Il modello di sicurezza di Windows applica anche l'ereditarietà automatica degli ACL agli oggetti figlio in base alle regole di ereditarietà ACE. Questa ereditarietà automatica, insieme alle informazioni di ereditarietà in ogni ace, determina il modo in cui le restrizioni di sicurezza vengono passate nella gerarchia di directory.
Si noti che non è possibile usare un ace di accesso negato per negare solo GENERIC_READ o solo GENERIC_WRITE l'accesso a un file. Ciò è dovuto al fatto che per gli oggetti file, i mapping generici per entrambi i GENERIC_READ o GENERIC_WRITE includono il diritto di accesso SYNCHRONIZE . Se un ace nega GENERIC_WRITE l'accesso a un trustee e le richieste del trustee GENERIC_READ l'accesso, la richiesta avrà esito negativo perché la richiesta include implicitamente l'accesso SYNCHRONIZE negato in modo implicito dall'ace e viceversa. Anziché usare gli ACL negati dall'accesso, usare gli ACL consentiti per l'accesso per consentire in modo esplicito i diritti di accesso consentiti.
Un altro mezzo per gestire l'accesso agli oggetti di archiviazione è la crittografia. L'implementazione della crittografia del file system in Windows è il file system crittografato o EFS. EFS crittografa solo i file e non le directory. Il vantaggio della crittografia è che fornisce una protezione aggiuntiva ai file applicati ai supporti e non tramite il file system e l'architettura standard di controllo di accesso di Windows. Per altre informazioni sulla crittografia dei file, vedere Crittografia file.
Nella maggior parte dei casi, la possibilità di leggere e scrivere le impostazioni di sicurezza di un oggetto file o directory è limitata ai processi in modalità kernel. Chiaramente, non si vuole che alcun processo utente sia in grado di modificare la proprietà o la restrizione di accesso nel file o nella directory privata. Tuttavia, un'applicazione di backup non sarà in grado di completare il processo di backup del file se le restrizioni di accesso inserite nel file o nella directory non consentono al processo in modalità utente dell'applicazione di leggerlo. Le applicazioni di backup devono essere in grado di eseguire l'override delle impostazioni di sicurezza degli oggetti file e directory per garantire un backup completo. Analogamente, se un'applicazione di backup tenta di scrivere una copia di backup del file tramite la copia residente su disco e si negano esplicitamente privilegi di scrittura al processo dell'applicazione di backup, l'operazione di ripristino non può essere completata. In questo caso, l'applicazione di backup deve anche essere in grado di eseguire l'override delle impostazioni di controllo di accesso del file.
I privilegi di accesso SE_BACKUP_NAME e SE_RESTORE_NAME sono stati creati in modo specifico per consentire il backup delle applicazioni. Se questi privilegi sono stati concessi e abilitati nel token di accesso del processo dell'applicazione di backup, è possibile chiamare CreateFile per aprire il file o la directory per il backup, specificando lo standard READ_CONTROL diritto di accesso come valore del parametro dwDesiredAccess. Tuttavia, per identificare il processo chiamante come processo di backup, la chiamata a CreateFile deve includere il flag FILE_FLAG_BACKUP_SEMANTICS nel parametro dwFlagsAndAttributes . La sintassi completa della chiamata di funzione è la seguente:
HANDLE hFile = CreateFile( fileName, // lpFileName
READ_CONTROL, // dwDesiredAccess
0, // dwShareMode
NULL, // lpSecurityAttributes
OPEN_EXISTING, // dwCreationDisposition
FILE_FLAG_BACKUP_SEMANTICS, // dwFlagsAndAttributes
NULL ); // hTemplateFile
Ciò consentirà al processo dell'applicazione di backup di aprire il file ed eseguire l'override del controllo di sicurezza standard. Per ripristinare il file, l'applicazione di backup userà la sintassi di chiamata CreateFile seguente all'apertura del file da scrivere.
HANDLE hFile = CreateFile( fileName, // lpFileName
WRITE_OWNER | WRITE_DAC, // dwDesiredAccess
0, // dwShareMode
NULL, // lpSecurityAttributes
CREATE_ALWAYS, // dwCreationDisposition
FILE_FLAG_BACKUP_SEMANTICS, // dwFlagsAndAttributes
NULL ); // hTemplateFile
In alcuni casi un'applicazione di backup deve essere in grado di modificare le impostazioni di controllo di accesso di un file o di una directory. Un esempio è quando le impostazioni di controllo di accesso della copia residente su disco di un file o di una directory sono diverse dalla copia di backup. Ciò si verifica se queste impostazioni sono state modificate dopo il backup del file o della directory o se è danneggiato.
Il flag FILE_FLAG_BACKUP_SEMANTICS specificato nella chiamata a CreateFile concede all'applicazione di backup l'autorizzazione per leggere le impostazioni di controllo di accesso del file o della directory. Con questa autorizzazione, il processo dell'applicazione di backup può quindi chiamare GetKernelObjectSecurity e SetKernelObjectSecurity per leggere e quindi reimpostare le impostazioni di controllo di accesso.
Se un'applicazione di backup deve avere accesso alle impostazioni di controllo di accesso a livello di sistema, il flag ACCESS_SYSTEM_SECURITY deve essere specificato nel valore del parametro dwDesiredAccess passato a CreateFile.
Le applicazioni di backup chiamano BackupRead per leggere i file e le directory specificate per l'operazione di ripristino e BackupWrite per scriverli.
Argomenti correlati