Quando un processo esegue un'operazione su un file, il kernel Linux esegue il controllo nel seguente ordine:
-
Controllo di accesso discrezionale (DAC) o controllo di accesso dettato dall'utente. Ciò include sia i classici controlli delle autorizzazioni in stile UNIX che gli elenchi di controllo degli accessi (ACL) POSIX. I classici controlli UNIX confrontano l'UID e il GID del processo corrente rispetto all'UID e al GID del file a cui si accede in relazione alle modalità impostate (Read/Write/eXecute). Access Control List estende i classici controlli UNIX per consentire più opzioni relative al controllo delle autorizzazioni.
-
Controllo di accesso obbligatorio (MAC) o controllo di accesso basato su criteri. Questo è implementato utilizzando Linux Security Modules (LSM) che non sono più moduli reali (lo erano ma è stato abbandonato). Consentono controlli aggiuntivi basati su modelli diversi dai classici controlli di sicurezza in stile UNIX. Tutti questi modelli si basano su una politica che descrive che tipo di operazioni sono consentite per quale processo e in quale contesto.
Ecco un esempio per l'accesso agli inode (che include l'accesso ai file) per sostenere la mia risposta con collegamenti a un riferimento incrociato Linux online. Il file "function_name (filename:line)" sono per la versione 3.14 del kernel Linux.
La funzione inode_permission (fs/namei.c:449) controlla prima i permessi di lettura sul filesystem stesso (sb_permission in fs/namei.c:425), quindi chiama __inode_permission (fs/namei.c:394) per verificare i permessi di lettura/scrittura/esecuzione e ACL POSIX su un inode in do_inode_permission (fs/namei.c:368) (DAC) e quindi autorizzazioni relative a LSM (MAC) in security_inode_permission (sicurezza/security.c:550).
Ce n'era solo uno eccezione a questo ordine (DAC poi MAC):era per i controlli mmap. Ma questo problema è stato risolto nella versione 3.15 del kernel Linux (commit rilevante).
DAC ==Discretionary Access Control , http://en.wikipedia.org/wiki/Discretionary_access_control
MAC ==Mandatory Access Control , http://en.wikipedia.org/wiki/Mandatory_access_control
ACL ==Access Control List , http://en.wikipedia.org/wiki/Access_control_list
Il ACL specifica i controlli da applicare con il metodo di controllo, DAC o MAC . MAC è esplicito, controllato centralmente e non consente agli utenti di concedere l'autorizzazione a un oggetto a meno che non dispongano di autorizzazioni esplicite per farlo, mentre DAC consente agli utenti di concedere ad altri utenti l'accesso agli oggetti a cui possono accedere.
MAC ACL s verrà sempre applicato prima a una richiesta e, se l'accesso viene negato, l'elaborazione si interrompe. Se l'accesso è consentito allora DAC ACL vengono applicati e, di nuovo, se l'accesso viene negato, l'elaborazione si interrompe. Solo se l'accesso è concesso da entrambi MAC e DAC ACL s l'utente può accedere all'oggetto che ha richiesto.
SELinux è un MAC implementazione per Linux (ce ne sono altri), mentre il tradizionale rwx i permessi sui file, combinati con l'utente proprietario e il gruppo formano il DAC completo ACL . Il SELinux 'policy' è essenzialmente il MAC ACL .
Mi dispiace cavillare, ma penso che alcune delle risposte qui potrebbero essere errato. Direttamente da http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-SELinux_Contexts_Labeling_Files.html di Fedora:
Le regole dei criteri di SELinux vengono verificate dopo le regole DAC. Le regole della politica di SELinux non vengono utilizzate se le regole DAC negano prima l'accesso.