Un profilo MAC troppo restrittivo (e.x. Profilo AppArmor) riduce la sicurezza dell'applicazione?
Ad esempio: potrebbe essere che l'ambiente troppo restrittivo per il browser Web protegga molto bene il sistema host disabilitando alcune funzionalità di sicurezza interne del browser (perché il browser non riceverà abbastanza supporto dal sistema host per le sue funzionalità di sicurezza)?
Questa domanda probabilmente è ancora più generica per qualsiasi applicazione.
Una politica MAC dovrebbe essere estremamente a grana fine , non necessariamente estremamente restrittiva .
Può ridurre la sicurezza in determinate condizioni. Le applicazioni, specialmente quelle complesse, hanno spesso fallimenti quando non è possibile accedere a una determinata risorsa. Le ragioni di ciò possono essere qualsiasi cosa, dall'impossibilità di accedere a un servizio di sicurezza ad entrare in una modalità di compatibilità non sicura per un sistema più vecchio e meno sicuro. A volte il problema è semplicemente che l'applicazione non è stata testata a fondo e l'impossibilità di accedere a una risorsa normalmente presente porta a bug di sicurezza.
Come menzionato in un commento, il servizio segreto su molti ambienti Linux fornisce un'API per proteggere le password , senza il quale browser e altre applicazioni possono tentare di archiviare le password internamente, potenzialmente con meno sicurezza.
LibreSSL tenta infamemente di generare il suo propria casualità dall'ambiente se non è in grado di leggere i dispositivi con carattere casuale o altri fallback, portando a risultati prevedibili. Questo problema ha in realtà portare allo sviluppo di un syscall di casualità in modo che le applicazioni possano accedere all'entropia anche in MAC o chroot eccessivamente restrittivi.
I programmi con il supporto PAM non saranno in grado di obbedire Politiche PAM se non possono accedere alle librerie e ai file di configurazione pertinenti. Breaking PAM non riduce direttamente la sicurezza poiché il fallback consiste nell'accedere alle password di sistema attraverso i metodi normali, ma può rompere le politiche complesse che aumentano la sicurezza. Ciò potrebbe, ad esempio, interrompere il riconoscimento della keycard.
Quando si sviluppa una politica di controllo accessi, è importante che nessuno dei normali tentativi di accesso alle risorse per le applicazioni autorizzate sia negato a meno che non abbia una solida comprensione di tutte le implicazioni del rifiuto della risorsa. Ad esempio, negando l'accesso a /etc/localtime è probabile che si verifichi un'applicazione che utilizza solo l'ora UTC, mentre il blocco dell'accesso a un file standard garantito per tutti i sistemi può causare errori imprevisti e gravi. Quando viene attivato un accesso negato, l'evento deve essere registrato per una revisione successiva. Se scopri che l'accesso è benigno e non è probabile che aumenti la superficie di attacco, puoi aggiungerlo alla whitelist.
Ti suggerisco di esaminare le astrazioni di AppArmor che consentono l'inclusione di sottocategorie con scopi specifici, come l'accesso audio alla whitelist. Ciò ti consente di semplificare la tua politica aggiungendo un #include <abstractions/audio> invece di dover autorizzare singoli oggetti. Ciò rende le politiche di AppArmor significativamente più semplici di quelle che sarebbero altrimenti, pur mantenendo un elevato livello di sicurezza. Molte architetture MAC supportano una funzionalità simile.
Leggi altre domande sui tag linux web-browser selinux apparmor mandatory-access-control