Quali ruoli svolgono DAC (autorizzazioni per i file), ACL e MAC (SELinux) nella sicurezza dei file Linux?

Ho bisogno di alcuni chiarimenti / conferme / elaborazioni sui diversi ruoli che DAC, ACL e MAC svolgono nella sicurezza dei file Linux.

Dopo alcune ricerche dalla documentazione, questa è la mia comprensione dello stack:

SELinux deve consentire l'accesso all'oggetto file.
Se ACL del file (ad esempio, setfacl, getfaclper una montatura ACL) permette esplicitamente / nega l'accesso all'oggetto, quindi non è necessaria alcuna ulteriore elaborazione.
Altrimenti, dipende dalle autorizzazioni del file (modello DAC rwxrwxrwx).

Mi sto perdendo qualcosa? Ci sono situazioni in cui non è così?

— Belmin Fernandez
fonte

Penso che tu abbia ragione. Potresti pubblicare il problema che stai riscontrando?

— Kevin M,

Mi scuso per la domanda malformata. Mi sento, quando si tratta di questo, vado in modalità "prova ed errore". Sto cercando di afferrarlo con sicurezza e spero che qualcuno possa condividere un quadro più chiaro dei ruoli interpretati da ciascuna parte dello stack.

— Belmin Fernandez,

Modificata la domanda per chiarire cosa sto cercando nelle risposte.

— Belmin Fernandez,

Risposte:

Quando un processo esegue un'operazione su un file, il kernel Linux esegue il controllo nel seguente ordine:

Discretionary Access Control (DAC) o controllo di accesso dettato dall'utente. Ciò include sia i classici controlli delle autorizzazioni in stile UNIX sia gli elenchi di controllo di accesso POSIX (ACL) . I controlli UNIX classici confrontano l'attuale UID e GID del processo con l'UID e il GID del file a cui si accede per quanto riguarda le modalità impostate (Lettura / Scrittura / eXecute). L'elenco di controllo dell'accesso estende i classici controlli UNIX per consentire ulteriori opzioni per quanto riguarda il controllo delle autorizzazioni.
Controllo di accesso obbligatorio (MAC) o controllo di accesso basato su criteri. Questo è implementato usando Linux Security Modules (LSM) che non sono più moduli reali (lo erano un tempo, ma è stato eliminato). Consentono controlli aggiuntivi basati su modelli diversi dai classici controlli di sicurezza in stile UNIX. Tutti questi modelli sono basati su una politica che descrive quale tipo di opzioni sono consentite per quale processo in quale contesto.

Ecco un esempio di accesso agli inode (che include l'accesso ai file) per sostenere la mia risposta con collegamenti a un riferimento incrociato Linux online . I " function_name(nome file: linea)" indicati sono per la versione 3.14 del kernel Linux.

La funzione inode_permission( fs / namei.c: 449 ) controlla prima l'autorizzazione in lettura sul filesystem stesso ( sb_permissionin fs / namei.c: 425 ), quindi chiama __inode_permission( fs / namei.c: 394 ) per verificare la lettura / scrittura / esecuzione permessi e POSIX ACL su un inode in do_inode_permission( fs / namei.c: 368 ) (DAC) e quindi permessi relativi a LSM (MAC) in security_inode_permission( security / security.c: 550 ).

C'era solo un'eccezione a questo ordine (DAC poi MAC): è stato per i controlli mmap. Ma questo è stato risolto nella versione 3.15 del kernel Linux ( commit rilevante ).

— Siosm
fonte

Risposta estremamente dettagliata con fonti canoniche. Grazie!

— Belmin Fernandez,

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

I ACLspecifica i controlli da effettuare con il metodo di controllo, DACo MAC. MACè esplicito, controllato a livello centrale e non consente agli utenti di concedere l'autorizzazione a un oggetto a meno che non dispongano di autorizzazioni esplicite per farlo, mentre DACconsente agli utenti di concedere ad altri utenti l'accesso agli oggetti a cui possono accedere.

MAC ACLs verrà sempre applicato prima a una richiesta e, se l'accesso viene negato, l'elaborazione si interrompe. Se l'accesso è consentito DAC ACL, vengono applicati i messaggi di posta elettronica, e di nuovo se l'accesso viene negato, l'elaborazione si interrompe. Solo se l'accesso è consentito sia da MACe DAC ACLS può all'utente l'accesso all'oggetto hanno chiesto.

SELinuxè MACun'implementazione per Linux (ce ne sono altre), mentre i tradizionali rwxpermessi sui file, combinati con l'utente e il gruppo proprietari formano il completo DAC ACL. La SELinux"politica" è essenzialmente la MAC ACL.

— Mike Insch
fonte

Da dove setfaclarrivano i file ACL (ad es. )?

— Belmin Fernandez,

setaclestende i filesystem di base ACLper consentire a più di un singolo utente o gruppo di essere assegnato a ACLfile e directory. Anche questa è DACun'implementazione e quindi viene applicata dopo la SELinux MAC ACLs.

— Mike Insch,

Grazie Mike. Un'altra domanda: per quanto posso dire attraverso i miei test, gli setfaclACL esplicitamente impostati hanno la precedenza sulle autorizzazioni tradizionali. È vero in ogni caso?

— Belmin Fernandez,

Per quanto ne so, sì, il setacl/ setfacl ACLs sostituirà il tradizionale "semplice" ACLnel file.

— Mike Insch,

Mike, la tua nota su setfaclappartiene alla risposta.

— Pavel Šimerda,

Mi dispiace cavillare, ma penso che alcune delle risposte qui potrebbero essere errate. 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 : Fedora

Le regole della politica SELinux sono controllate dopo le regole DAC. Le regole della politica SELinux non vengono utilizzate se le regole DAC negano prima l'accesso.

— lmgtfy
fonte