Difesa approfondita con controlli di sicurezza comuni

4

Molti sistemi operativi implementano funzionalità di sistema, controlli di accesso Posix (DAC / ACL) e controlli di accesso obbligatori (SELinux), ciascuno utilizzando diversi controlli di sicurezza sottostanti per fornire singoli livelli di sicurezza, implementando così il principio della difesa in profondità.

Che cosa accadrebbe se le funzionalità di sistema, DAC e MAC fossero implementate utilizzando un meccanismo di sicurezza sottostante comune, sarebbe ancora possibile raggiungere la difesa anche se tutti e tre i controlli di sicurezza hanno almeno una superficie di attacco comune?

    
posta Whome 29.04.2016 - 15:17
fonte

3 risposte

2

would defense-in-depth still be achieved even though all three security controls have at least one common attack surface?

No, lo si può vedere molto bene con il software antivirus, ad esempio: assomigliano alla difesa in profondità poiché mettono i sistemi di protezione su diversi livelli (firewall di rete, plug-in del browser, monitoraggio dei processi, analisi dei file, ecc.), tuttavia, un hacker deve solo sconfiggere una singola cosa, il software anti-virus stesso, per far crollare l'intero sistema di protezione.

Come correttamente notato, il kernel di Linux non implementa i suoi controlli di autorizzazione in modo monolitico, invece usa un modo modulare dove i moduli di sicurezza (chiamati LSM, vedi qui e ci per ulteriori informazioni) possono provenire da diversi provider e si completano a vicenda (da qui il sistema DAC in-kernel può essere completato con funzionalità e un sistema MAC entrambi disponibili come moduli).

Questo offre diversi vantaggi, sia in termini di libertà che è al centro della filosofia e sicurezza GNU / Linux:

  • Più libertà perché un modulo di sicurezza non è strettamente integrato al kernel, questo consente a un utente (o più probabilmente un manutentore della distribuzione) di selezionare l'LSM in modo più adeguato alle proprie esigenze (il che, alla fine, porta più sicurezza alla fine -utente). Ad esempio alcuni preferiscono il modello di sicurezza di AppArmor, altri preferiscono quello di SELinux, ecc .: la scelta non è imposta dal team di sviluppo del kernel di Linux. Questo è esplicitamente indicato nella pagina di Wikipedia precedentemente collegata :

    Linus Torvalds rejected SELinux at that time, because he observed that there are many different security projects in development, and since they all differ, the security community has not yet formed consensus on the ultimate security model. Instead, Linus charged the security community to "make it a module".

  • Sicurezza a causa di due motivi, che risultano entrambi benefici dell'isolamento del codice:

    • Una correzione effettuata su una funzione di sicurezza non dovrebbe causare alcun problema su un altro. Un aggiornamento su SELinux, ad esempio, non dovrebbe influire sui sistemi di autorizzazione DAC o sulle capacità poiché ognuno utilizza un codice e strutture dati distinti. Questo non sarebbe il caso se tutto questo fosse implementato come un unico software monolitico.

    • Una vulnerabilità che interessa una caratteristica di sicurezza non dovrebbe mettere in pericolo le altre. In caso di vulnerabilità che interessano SELinux, ad esempio, tale vulnerabilità non renderà nulla il DAC e i sistemi di sicurezza delle funzionalità come nell'esempio anti-virus mostrato sopra, laddove una vulnerabilità del software anti-virus annulla molto probabilmente tutti i suoi vantaggi in termini di sicurezza.

La difesa in profondità non dovrebbe essere concepita come semplice con diversi livelli di controlli di sicurezza, ma dovrebbe semplicemente essere vista come dotata di diversi livelli di sistemi di sicurezza. È infatti l'isolamento tra ogni sistema che ti darà una buona garanzia che ci vorrà del tempo perché un attaccante possa sconfiggere la tua infrastruttura di sicurezza.

    
risposta data 28.08.2016 - 10:05
fonte
0

Ho il sospetto che dac e mac siano abbastanza distinti che se si tentasse di minimizzare il codice usando l'infrastruttura comune, la quantità di codice condiviso sarebbe piccola. Personalmente li farei separatamente, quindi rivedere e contrassegnare qualsiasi cosa che sembrava troppo simile ...

    
risposta data 30.04.2016 - 01:35
fonte
0

Hanno una superficie di attacco comune: il kernel. DAC, MAC e funzionalità si basano tutti sul kernel per la loro implementazione. Quindi, i difetti nel kernel che consentono l'esecuzione remota del codice falliranno tutti questi meccanismi, ovviamente. Questo vale anche per gli spazi dei nomi di Linux.

Fortunatamente, questi meccanismi di sicurezza riducono l'esposizione alle API del kernel per i processi non privilegiati e, quindi, i rischi associati alle vulnerabilità del kernel. La difesa in profondità dovrebbe essere che i confini multipli devono essere infranti / i sistemi devono essere compromessi, uno dopo l'altro, affinché un avversario possa beneficiare di un attaccante. Nel caso di sistemi operativi e processi non privilegiati, è meglio ragionare sulla misura in cui ciascun livello protegge le API, piuttosto che in un formato binario.

Ad esempio, se la tua sandbox namespace e le policy di SELinux consentono l'accesso diretto alla memoria su GPU, le vulnerabilità relative ai driver GPU potrebbero essere più facili da accedere in modo da far cadere l'intero sistema come se non lo fossero. Quindi, in definitiva, c'è un single point of failure (il kernel qui), ci sono molti modi per interagire con esso (alcuni pericolosi, altri no), ci sono vulnerabilità, ed è politica e configurazione che stabiliscono la facilità di attacco piuttosto che la semplice presenza di meccanismi di sicurezza.

    
risposta data 27.10.2016 - 11:37
fonte