Compensazioni di sicurezza del MAC basato sul nome (ad es. TOMOYO, grsecurity, AppArmor, ...)

Question

Compensazioni di sicurezza del MAC basato sul nome (ad es. TOMOYO, grsecurity, AppArmor, ...)

#1 da (8 voti)
#2 da (7 voti)
#3 da (2 voti)

10

Ho imparato a conoscere i sistemi MAC (Mandatory Access Control) in Linux. Spesso, ma non sempre, questi sono legati ai moduli di sicurezza Linux . Alcuni sistemi che ho visto: SELinux , Tomoyo , AppArmor , grsecurity , Smack .

Per quanto ho capito, tutti questi sistemi si basano sulla creazione di un catalogo di regole. Queste regole definiscono policy di accesso più dettagliate per file e risorse di sistema e quindi forniscono una maggiore sicurezza.

Dato l'intento di limitare l'accesso al file, è logico che dobbiamo sapere "quali" file e quindi i riferimenti ai file sono essenziali affinché tali regole abbiano un senso. Questo è ciò a cui è correlata la mia domanda.

Con l'eccezione notevole di SELinux e Smack, gli altri approcci utilizzano percorsi di file (percorsi) per identificare i file nelle regole. Ho visto altri giudicare questo approccio insicuro, perché un file poteva avere più nomi contemporaneamente (link, bind-mount, ecc.).

L'approccio all'uso dei nomi di percorso è sicuro? Quali sono i vantaggi e gli svantaggi di questi schemi basati sul nome? Sarebbe corretto affermare che "MAC basato sul nome del percorso (come TOMOYO, grsecurity, AppArmor, ...) hanno un vero difetto concettuale"?

linux apparmor file-access mandatory-access-control

posta humanityANDpeace 17.12.2012 - 09:23

fonte

3 risposte

Leggi altre domande sui tag linux apparmor file-access mandatory-access-control

Hacking etico - Test di penetrazione Book (s) [closed] Qual è la differenza tra un gemello malvagio e un access point canaglia?

score 8 · Answer 1

Quite frequently this appraoch is judged insecure stating that one file could have several names at the same time (links, bind-mounting etc).

È certamente vero che un file può avere più contesti di sicurezza, uno per ogni nome. Tuttavia, indipendentemente dal fatto che questo non sia sicuro dipende da come lo si visualizza:

Questa funzione di AppArmor non richiede che i filesystem remoti supportino AppArmor, quindi per esempio può essere implementato per i percorsi NFS.
Solitamente, il DAC Unix rimane abilitato, quindi anche applicazioni interessanti come il contenuto di /usr/bin non dovrebbero essere scrivibili. In teoria!
Potrebbero esserci controlli aggiuntivi per impedire agli utenti finali di montare o creare collegamenti simbolici.

Tuttavia, a parte questo, l'obiettivo dei progetti di tipo MAC è di limitare i processi e gli utenti, in modo che un processo venga eseguito come utente che esegue solo le autorizzazioni necessarie di cui ha bisogno. Poche applicazioni, tranne forse ln , hanno bisogno della possibilità di creare collegamenti simbolici e quelli che non li richiedono su tutte le directory e i percorsi. Quindi dovrebbe essere possibile implementare il contenimento desiderato per la maggior parte dei processi.

Pur non soffrendo del potenziale problema nei nomi dei percorsi, la sicurezza basata sugli inode ha i suoi problemi:

Le informazioni allegate alla sicurezza del file sono memorizzate in xattrs (attributi estesi), il che significa considerazioni speciali per file system di rete .
Alcune applicazioni cambiano valori di inode che può causare problemi con i contesti di sicurezza, in particolare è probabile che il file ritorni alla sicurezza predefinita contesto se lo modifichi e vim funziona in questo modo.

Penso che la differenza sia piuttosto sottile e non è il caso che uno sia più sicuro dell'altro, in quanto ognuno ha i suoi vantaggi e svantaggi. Compresi correttamente, entrambi consentono di implementare politiche sicure.

score 7 · Answer 2

Grsecurity non è un sistema MAC basato su un pathname puro come TOMOYO o AppArmor. La politica è descritta usando i nomi di percorso (come ogni altro sistema, incluso SELinux), ma questi vengono convertiti in coppie di inode / dev al tempo di attivazione e utilizzati successivamente. I pathname sono usati solo quando si abbinano le espressioni regolari dalla policy o per fornire "policy-recreation" - dato il caso nell'altro commento qui di SELinux che ripristina un file modificato da vim al contesto di sicurezza predefinito (un problema serio!), Grsecurity rileva questo caso e applica il criterio precedente su quell'oggetto a quello nuovo.

Funnily, mentre si aggrega in grsecurity con sistemi MAC puramente basati sul nome e diffusione FUD, SELinux stesso ha recentemente aggiunto l'uso delle informazioni sui file nelle ultime versioni per fare esattamente ciò che grsecurity ha fatto dal primo giorno.

Sembra vero quello che Schopenhauer ha detto: "Tutta la verità passa attraverso tre fasi: prima è ridicolizzata, in secondo luogo, è violentemente opposta, in terzo luogo è accettata come ovvia".

Discuto di ulteriori dettagli su questo argomento nella mia presentazione tutorial RBAC di grsecurity: link

-Brad

score 2 · Answer 3

Penso che, in generale, il controllo dell'accesso basato sul nome non sia imperfetto a livello concettuale, potrebbe persino avere vantaggi, ma le implementazioni correnti non sono convenienti.

Vantaggio è che puoi avere una politica più chiara e comprensibile specificata in un unico posto, e non hai complicazioni di xattr che si diffondono su tutto il filesystem. Pensabilità, dico, che è importante. Lo svantaggio è che alcune implementazioni non sono in grado di gestire il collegamento o la ridenominazione in modo facile per gli utenti .

Ci sono risposte dagli autori TOMOYO: link Sostanzialmente, si dice che è possibile proibire il collegamento / rinomina di file importanti e che per impostazione predefinita il collegamento / ridenominazione è vietato, quindi "nessun problema". Non sono d'accordo, tutto ciò che complica la creazione e il mantenimento delle politiche. Beh, dipende da quali obiettivi hai, però.