SELinux ti proteggerà dai bug creati dalla community di chromium e dalle loro "oopses" o "funzionalità nascoste" di quel browser. Non puoi mettere tutte le uova nello stesso paniere quando si tratta di sicurezza. Ecco alcuni esempi in cui disabilitare Selinux potrebbe non essere una buona idea:
-
SELinux impedisce a chrome-sandbox di accedere in scrittura al file oom_score_adj - Una regressione su Chromium gli sviluppatori cercano di incolpare selinux quando è colpa loro. È stato introdotto su un aggiornamento e Chromium stava cercando di manipolare Out-Of-Memory. Chiaramente, verrà negato da qualsiasi sistema MAC, perché è abbastanza ovvio che non è "bello" elencare se stesso come un processo per non essere killer in uno scenario di OOM.
-
SELinux impedisce l'accesso / write / google / chrome / chrome-sandbox "write" su oom_adj - In questo caso, un descrittore di file trapelato impedirebbe l'esclusione di Chromium nei casi OOM. Chiaramente, un bug che potrebbe interessare qualsiasi sistema senza SELinux. Una regressione / "funzione nascosta" che è stata bloccata da SELinux.
-
"Aw, Snap!" in openDatabase (ad esempio durante il caricamento di Twitter) in Fedora 15 con SELinux Enforcing abilitato : alcuni siti si bloccavano quando un rendering di Chromium passava i descrittori di file a chromium-sandbox. Un equivoco sulle etichette dei file che potrebbero essere corretti con
restorecon -R ~/.config
drive chromium in crash durante il rendering di alcuni siti. Chiaramente, un bug su cromo che SELinux preveniva possibili danni. Se prendi un po 'di tempo per leggere i commenti, noterai che alcuni sviluppatori non sanno nemmeno perché si blocca e altri si affrettano a dire "disabilitare SELinux". Non bello ...
-
Problemi di Fedora SELinux con l'avvio di Chrome : l'avvio di chromium senza sandbox (
google-chrome --no-sandbox
) funziona, mentre con sandbox dopo l'aggiornamento alla versione "14.0.803.0 dev" non farlo. Chromium ha aggiunto ASLR in fase di compilazione, ma SELinux ha bloccato rilocazioni di testo . SELinux non ha una sfera di cristallo per indovinare che i binari di Chromium vengono rilevati come librerie dal comando file
dopo che il browser ha aggiunto questa funzione di sicurezza, ed era dovere bloccare questo tipo di comportamento. Chromium stava cercando di migliorare la sicurezza, ma ha dimenticato che quelle rilocalizzazioni di testo sono effettivamente vettori di attacco da parte di librerie con codici errati .
-
Il migliore : SELinux impedisce a google-chrome di leggere il file / etc / passwd : Non c'è bisogno di spiegare qui. Perché quel dannato browser vorrebbe leggere il tuo passwd? Nessuna spiegazione coerente è stata fornita dagli sviluppatori di cromo riguardo al problema. Prova qui .
SELinux, infatti, migliora la sicurezza e crea un altro livello per proteggerti dalle funzionalità non funzionanti introdotte sugli aggiornamenti di Chromium.
Che cosa dovrebbe bloccare la politica predefinita?
Citerò Dan Walsh nel suo livejournal , dove spiega le basi della politica di Chrome. Questa è una spiegazione che è stata data alla data in cui questa politica è stata concepita, e in pratica:
SELinux prevents chrome-sandbox from:
Applicare il privilegio minimo e tutto ciò che non è consentito verrà bloccato. Quindi, in qualsiasi momento chromium implementa qualcosa di nuovo che coincide con le politiche di default (e ricorda, le policy di SELinux sono OLDER che tu browser), otterrà un AVC.
E questo non sta andando male con Chromium. Questo è il comportamento predefinito tra qualsiasi software che è limitato dalle politiche SELinux.
Link correlati (documenti aggiuntivi):