Ragioni per disabilitare / abilitare SELinux

In linea con questa domanda su StackOverflow e la folla completamente diversa che abbiamo qui, mi chiedo: quali sono i motivi per disabilitare SELinux (supponendo che la maggior parte delle persone lo faccia ancora)? Vuoi tenerlo abilitato? Quali anomalie hai riscontrato lasciando SELinux acceso? Oltre a Oracle, quali altri fornitori danno problemi a supportare i sistemi con SELinux abilitato?

Domanda bonus: qualcuno è riuscito a far funzionare Oracle su RHEL5 con SELinux in modo mirato? Voglio dire, rigoroso sarebbe fantastico, ma non è ancora possibile farlo da remoto, quindi restiamo prima col bersaglio ;-)

RedHat attiva SELinux di default perché è più sicuro. Quasi tutti i fornitori che utilizzano prodotti derivati ​​da Redhat disattivano SELinux perché non vogliono impiegare tempo (e quindi denaro) per capire perché la cosa non funziona. Le persone di Redhat / Fedora hanno impiegato moltissimo tempo e sforzi per rendere SELinux più un'opzione praticabile in Azienda, ma non molte altre organizzazioni tengono davvero alla tua sicurezza. (Si preoccupano della loro sicurezza e della reputazione di sicurezza del loro prodotto, che è una cosa totalmente diversa.)

Se riesci a farlo funzionare, allora fallo. Se non ci riesci, non aspettarti molta assistenza dai venditori. Probabilmente puoi ottenere aiuto dai ragazzi di Redhat / Fedora, dalle mailing list di selinux e dal canale #selinux su freenode. Ma da aziende come Oracle - beh, SELinux non tiene conto del loro piano aziendale.

In genere è meglio eseguire SELinux in Permissive piuttosto che disabilitarlo del tutto. È quindi possibile controllare (via audit2why) dopo un po 'per vedere quali tipi di violazioni sarebbero state negate durante il normale utilizzo e creare criteri personalizzati tramite audit2allowse tali "violazioni" sono falsi positivi per la configurazione.

Ho trovato che il comportamento di SELinux su sistemi non derivati ​​da Fedora è significativamente più tocchi rispetto a quello che si ottiene con un tipico sistema Fedora / RHEL di default.

Se non l'hai già visto, potresti trovare educativo il Manuale dell'utente di Fedora SELinux .

Ragioni per:

• Maggiore livello di sicurezza attraverso il controllo dell'accesso obbligatorio
• Hai bisogno di un motivo oltre il più alto livello di sicurezza? :-)

Ragioni contro:

• Difficile da capire
• Difficile da gestire
• Difficile da risolvere

Detto questo, se stai considerando SELinux, ti consiglio il libro SELinux con l'esempio .

Ho lavorato per un'azienda che aveva SELinux abilitato, in modalità esecutiva, su ogni sistema. La chiave per noi era capire e usare il programma audit2allow che può essere usato per creare nuove regole di contesto.

Innanzitutto, genereremmo un modello con audit2allow, quindi utilizzeremo uno script per crearlo, in questo modo:

export NAME="my_serviced"
sudo audit2allow -m "${NAME}" -i /var/log/audit/audit.log > ${NAME}.te
sudo setup_semodule ${NAME}

Lo script setup_semodule:

#!/bin/sh

# Where to store selinux related files
SOURCE=/etc/selinux/local
BUILD=/etc/selinux/local
NAME=$1

/usr/bin/checkmodule -M -m -o ${BUILD}/${NAME}.mod ${SOURCE}/${NAME}.te
/usr/bin/semodule_package -o ${BUILD}/${NAME}.pp -m ${BUILD}/${NAME}.mod
/usr/sbin/semodule -i ${BUILD}/${NAME}.pp

/bin/rm ${BUILD}/${NAME}.mod ${BUILD}/${NAME}.pp

Ciò crea il modulo dal modello (file .te), genera un pacchetto e quindi carica il modulo.

Abbiamo usato Puppet per il nostro sistema di gestione della configurazione e abbiamo scritto la configurazione per Puppet per gestire tutto questo.

Modulo fantoccio SELinux:

• http://github.com/sansnoc/puppet/tree/master/selinux

Il motivo per disattivarlo è perché può essere un problema per il debug.

Tuttavia non lo disattiviamo ora. Quasi sempre lo facciamo funzionare. Di tanto in tanto lo spengo per verificare rapidamente se SElinux è un problema o meno.

E 'molto più facile eseguire il debug ora, specialmente se ti fai familiarizzare con audit2allow. Non è necessario capirlo con audit2allow, ma a volte si può finire per aprirli più largamente di quanto si pensi con audit2allow. Detto questo, SELinux è meglio di niente.

Non sono affatto un esperto SELinux e lo uso solo da un paio d'anni. Ancora non capisco davvero le basi, ma ne so abbastanza per far funzionare le app, tra quelle incluse con la distribuzione e cose casuali compilate della 'rete.

La cosa principale che ho avuto per l'uso sono il ls -lZ(contesto di SELinux spettacolo), audit2allow, chcon, semodule, getenforce, setenforcee booleani. Con quegli strumenti sono riuscito a ottenere tutte le app di cui avevo bisogno per funzionare con SELinux.

Trovo che uno dei suoi maggiori problemi con il debug dei problemi di SELinux, sia semplicemente ricordare di verificare i problemi di SELinux quando ho altri saggi inspiegabili problemi. Di solito mi serve un po 'di astuzia per andare "h! Controlla SELinux !!".

Secondo la pagina man di bind SELinux è molto più sicuro che eseguire bind in un carcere chroot. Un sacco di altre persone che hanno molte più indicazioni di quelle che consiglio anche io, quindi ora lo eseguo alla cieca. E sospetto, nonostante il problema occasionale, probabilmente vale la pena farlo.

Ho disabilitato SELinux per AppArmor , l'ho trovato molto più semplice e facile da gestire rispetto a SELinux.

Non c'è motivo di spegnerlo quando è possibile eseguirlo in modalità Permissive. Non interferirà con l'applicazione in esecuzione e fornirà comunque utili registrazioni di sicurezza. L'unica eccezione riguarda i contesti utente: se stai cambiando tra utenti diversi che vivono all'interno di un'altra istanza di Linux in esecuzione in un chroot potresti avere dei problemi.

SE Linux non è così irrimediabilmente ostile come una volta, almeno non è nelle distribuzioni supportate commercialmente come RHEL5. Per la maggior parte puoi lasciarlo acceso e andrà bene con tutto ciò che viene fornito da RedHat. Con qualsiasi altra cosa può essere variabile. Il problema è che il servizio di assistenza professionale per far funzionare le applicazioni con SE Linux è un buon flusso di entrate per aziende come RedHat e Oracle, quindi non hanno incentivi per far funzionare tutto in modo perfetto.