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.