Le FAQ "ufficiali" sono sul sito della NSA o su questo sito quelle tradotte in italiano - coprono la storia e la strategia di SELinux e non molti dettagli tecnici. Non ti dicono molto su come fare le cose, cosa vogliono dire certi errori, e come risolvere determinati problemi. Sono frustrato dalla mancanza di documentazione di SELinux mentre stavo ricercando un articolo su una rivista per SysAdmin ho scritto questa FAQ chiamata UnOfficial FAQ.
Molte delle informazioni che sono qui provengono da mie ricerche personali, e dalla SELinux mailing list. Le seguenti persone hanno anche fatto un gran lavoro per contribuire a queste FAQ :

* Russell Coker
* Stephen Smalley

Dove delle persone hanno contribuito in parti significative, ho aggiunto il loro nome fra parentesi quadre [].

Questo documento può essere trovato nei seguenti siti :

* www.crypt.gen.nz/selinux/faq.html - il mio sito web personale
* SourceForge SELinux Project Docs
* WWW.SELinux.jp (Traduzione Giapponese)
* Adamantio.net SELinux FAQ (traduzione italiana)

Nota che questa FAQ è applicabile solo alle release stabili dei moduli del kernel di SELinux e relativa fascia di utenza. Questo perchè le versioni di sviluppo stanno cambiando troppo velocemente per stargli appresso. Se hai problemi con le versioni di sviluppo a cui non trovi risposte qui, allora è meglio che ti iscriva alla SELinux mailing list e posti il tuo problema li.

SELinux è un sistema operativo basato su Linux che include il Mandatory Access Control. In breve, con SELinux puoi definire regole esplicite su come i soggetti ( utenti, programmi ) possono accedere a quali oggetti ( files, periferiche ). Puoi pensare a questo sistema come ad una sorta di firewall interno, che ti da la possibilità di separare i programmi quindi assicurando un alto livello di sicurezza dal sistema operativo.

Va notato che le persone che lavorano su SE Linux tendono ad evitare il termine "Trusted Linux" o similare. Le distribuzioni Trusted sono associate con releases che prendono le distanze dalle releases principali, queste hanno problemi di compatibilità con i software comunemente usati, e generalmente causano problemi agli utenti. Nelle distribuzioni Red Hat e nelle Hardened Gentoo SE Linux funziona abbastanza bene, è aggiornato, ed ha minimi problemi di compatibilità.

Ci sono vari progetti in atto per ottenere certificvazioni EAL per SELinux, per lo più da RedHat ed IBM.

LSM ( Linux Security Modules ) è un estensione del kernel di Linux che consente ai sistemi di sicurezza di essere facilmente aggiunti al kernel. SELinux è implementato come un LSM, ed utilizza l'interfaccia del kernel LSM. La homepage dei LSM è lsm.immunix.org

SELinux è stato sviluppato dalla NSA con la cooperazione di varie aziende come MITRE e NAI Labs. E' un derivato dell'architettura di sicurezza Flask che fu parte del sistema operativo di ricerca Flux. Dopo il suo rilascio al pubblico alla fine del 2000, fu adottato dalla comunità open source ed è attualmente in lavorazione grazie ad un certo numero di persone sparse per il mondo. La NSA è ancora coinvolta nello sviluppo.

Più recentemente, RedHat e Tresys Technology hanno i ruoli principali nello sviluppo di SELinux.

Dalle FAQ NSA :
"Le nuove caratteristiche di Security-enhanced Linux sono disegnate per forzare la separazione delle informazioni basandosi su requisiti di confidenzialità ed integrità. Esse sono disegnate per prevenire che i processi possano leggere dati e programmi, alterare dati e programmi, bypassare i meccanismi di sicurezza delle applicazioni, eseguire programmi sconosciuti, o interferire con altri processi in violazione della policy di sicurezza del sistema. Inoltre aiutano a confinare il potenziale danno che può essere causato da programmi maliziosi o corrotti. Potrebbe anche essere utilizzata per abilitare un singolo sistema ad essere usato da utenti con differenti autorizzazioni di sicurezza nell'accedere a molteplici tipi di informazioni con requisiti di sicurezza differenti senza compromettere questi requisiti di sicurezza."

Ora che SE Linux è attivo per impostazione predefinita in Fedora e Red Hat Enterprise Linux esso aggiunge un livello di sicurezza extra senza alcuno sforzo per l'utente. Gli utenti desktop possono ottenere alti livelli di sicurezza senza onerosi sforzi amministrativi.

Comparato ad altri approcci per l'alta sicurezza, è facile ottenere gli stessi obbiettivi con SELinux che con molti metodi alternativi. Per esempio, se un amministratore volesse impostare un server Internet DNS, gli ci vorrà molto più sforzo per creare una macchina basata su CD-ROM che fare una semplice installazione predefinita Fedora o RHEL per ottenere i medesimi benefici.

Perchè SELinux ti da la possibilità di rendere sicuri i processi l'uno dall'altro e rispetto al sistema. Per esempio, se hai un webserver su internet che serve anche Email e DNS non vorrai che una vulnerabilità nel processo del server web permetta ad un attaccante di corrompere il tuo server DNS. SELinux è uno dei pochi sistemi operativi che in pratica può fornire questo tipo di protezione. Nelle recenti versioni di Fedora e RedHat Enterprise Linux, SELinux è abilitato per impostazione predefinita e non richiede alcuno sforzo speciale per mantenerlo.

In un sistema convenzionale Unix/Linux, l'il controllo degli accessi è sotto il controllo dell'utente. L'utente sceglie se gli altri utenti possono accedere ai files che egli possiede.
SELinux è sotto il controllo dell'amministratore della sicurezza. Questo include i files posseduti dall'utente. Anche se un utente vuole che uno specifico altro utente possa accedere ad un file , se quell'utente non è sotto lo stesso dominio contenente l'utente (es, sono entrambi nello stesso dominio) allora l'altro utente non potrà accedere comunque al file. La differenza è nel mandatory access contro discretionary access.
Finchè i files di sistema eseguiti, sono tutti forniti accuratamente delle appropriate ACLs, allora sono protetti. Comunque, se l'account di root viene violato, tutti i files sono ancora vulnerabili.
Se un sistema SELinux viene violato, a meno che l'hack in se stesso non contenga un etichetta/dominio veramente potente, l'hack ancora non avrà accesso a tutti i files.. ma solo a quelli che sono sotto il dominio del demone violato.
[Jesse Pollard]

Nessuno ufficialmente. Ma se hai bisogno di aiuto, ci sono abbondanti risorse in giro. Ricercare con Google il tuo problema è un buon inizio. Cerca anche nell'archivio della SELinux mailing list. Se hai ancora problemi, entra nel gruppo di posta di SELinux ed invia la tua domanda li.

Certo che c'è. E sono anche un mucchio di gente amichevole! Puoi sottoscriverti spedendo un email a Majordomo@tycho.nsa.gov con le parole 'subscribe selinux' nel corpo del messaggio.
C'è un archivio su cui poter fare ricerche della SELinux mailing su http://marc.theaimsgroup.com/?l=selinux

Si ! Corri! Ora! Finchè ce la fai! Seriamente, non è affatto così difficile. Se hai scaricato un qualsiasi tipo di pacchetto di codice sorgente, e compilato su Linux ( o Solaris, etc. ) allora non avrai problemi ad installare ed eseguire SELinux. Abbi solo cura su come configurare questi kernels nel boot manager, e quando stai facendo esperimenti scientifici paga avere un affidabile kernel non-SELinux sul quale fare il boot, in ogni caso.

Ci sono pochi servers SELinux su Internet, sui quali puoi eseguire il login, e come utente root men che meno. Attenzione - la sicurezza del sistema dipende completamente dalla definizione delle policy di SELinux.

Fa riferimento a queste pagine per accedere a delle macchine SELinux demo/gioco:

* Fedora macchina demo Fedora di Russell Coker
* Gentoo la macchina demo del Hardened Gentoo Team
* Debian La macchina demo Debian di Ed Street's

Il team Hardened Gentoo produce anche un liveCD bootabile che è ottimo per le dimostrazioni. L'immagine ISO si può trovare qui.

SELinux è stato adottato rapidamente da molte compagnie per sistemi in produzione da quando RedHat lo ha abilitato per impostazione predefinita per Enterprise Linux. E' divenuto parte di Fedora dalla Fedora Core 2 con cui è stato rilasciato, ed ora è divenuto largamente accettato per sistemi in produzione.

Quando esegui il comando newrole per cambiare su un diverso ruolo SELinux, ti verrà richiesto di digitare la password per l'utente di cui vuoi fare login. La differenza con il normale comando login newgrp usato per cambiare gruppo predefinito in Unix è che quest'ultimo non ti chiede la password. La ragione di ciò è quella di prevenire che programmi maliziosi che puoi eseguire inavvertitamente possano scalare verso ruoli più privilegiati.

Attualmente, le sovraccarico di prestazioni è approssimativamente del 7%. Ci sono stati pochi sforzi nell'ottimizzare il codice di SELinux per le prestazioni, ed in alcuni casi come il networking l'impatto può essere maggiore. Il team di sviluppo di SELinux sta cercando di migliorare le prestazioni. Se imposti "selinux=0" come opzione di boot del kernel, SELinux non avrà alcun impatto sulle prestazioni.

C'è stato un bel po di lavoro sulle prestazioni di SE Linux. All'inizio del 2005, SE Linux è stato ottimizzato per le macchine a 32 o più CPUs. Recentemente sono stati fatti cambiamenti al codice del kernel per ridurre l'uso di memoria (non ancora in kernel.org o nei kernels in distribuzione).

La "targeted" policy (predefinita per Fedora ed Red Hat Enterprise Linux) blocca i demoni ma non restringe le sessioni utente. Così per le macchine desktop non vi è perdita di funzionalità, ma SE Linux ancora fornisce protezione per i programmi di sistema.

Di gran lunga il modo più semplice è di installare Fedora Core versione 3 o superiori o Red Hat Enterprise Linux versione 4 o superiori. Fedora Core 2 è stata la prima distribuzione ad avere il supporto SE Linux, ma non è stato attivato per impostazione predefinita e non funziona bene come su FC3 e FC4.

Il kernel SELinux è stato tradizionalmente reso disponibile, dal sito della NSA, qui. Da quando SELinux è stato adottato dal kernel 2.6 si può tovare molto più diffusamente. Vedi la prossima sezione.

Per far funzionare SELinux, devi almeno installare quanto segue:

• Un kernel linux SE-enabled. Puoi anche usare la versione stabile del kernel 2.6 che non richiede nessuna patch addizionale dal seguente link:
  • Codice sorgente da kernel.org
  Nota che se vuoi usare un kernel 2.6 su una distro basata sul kernel 2.4, allora ti raccomando di eseguire l'installazione del kernel e di farla funzionare senza abilitare le caratteristiche di SELinux prima di tentare di proseguire.
  
  Se vuoi usare un kernel 2.4, prendi i vecchi kernels 2.4 con le patch SELinux dal sito della NSA.


• I pacchetti utente di SELinux da:
  • Sito NSA per i pacchetti source/SRPM - anche se stai pianificando di installare i pacchetti RPM/DEB, è una buona idea prendere questi pacchetti di sorgenti poichè contengono preziose documentazioni ed istruzioni per l'installazione a cui vorrai dare un occhiata prima di installare.
  • Gli RPMs di Daniel Walsh per RedHat/Fedora che includono uno script veramente utile selUpgrade che automaticamente scarica ed installa i pacchetti in un sistema Fedora Core.
  • Il sito web di Russell Coker per i pacchetti Debian Russell da istruzioni su come avere i pacchetti mediante l'utility Debian apt-get.

Dovrai usare il kernel 2.6.

Il supporto per il vecchio kernel 2.4 di SELinux è diminuito e potrebbe interamente cessare nel prossimo futuro.

trulux - Lorenzo Hernandez Garcia-Hierro ( lorenzo /at/ gnu.org ) è ora la sola persona che fornisce qualsiasi supporto per SE Linux su un kernel 2.4.x kernel. Perciò la sola opzione è un kernel 2.6. [Russell Coker]

Selinux in se stesso non è una distribuzione - è un insieme di caratteristiche che le distribuzioni linux possono includere nelle loro installazioni. Attualmente, le seguenti distribuzioni comuni Linux che includono SELinux, sono:

• Fedora Core - a cominciare da Fedora Core 2
• RedHat Enterprise Linux - dalla versione 4
• Debian - disponibile come pacchetti aggiuntivi
• Gentoo - disponibile come pacchetti aggiuntivi ( Hardened Gentoo )
• Ubuntu - disponibile come pacchetti aggiuntivi
• SuSE - parzialmente integrato in SuSE Linux 9.x e SLES 9
• SlackWare - potrebbe .....

L'ultimo codice si può ottenere via CVS eseguendo questo comando:
cvs -d:pserver:anonymous@cvs.selinux.sourceforge.net:/cvsroot/selinux -z3 co nsa

La versione di NSA icluderà un gruppo di files di policy usabile. Anche, Russell Coker ha ottimi ed aggiornati gruppi di files di policy su www.coker.com.au

Fedora Core 3 e superiori, e RedHat Enterprise Linux 4 e superiori, vengono distribuiti con pieno supporto per SELinux abilitato per impostazione predefinita. Installa una di queste distribuzioni ed avrai installato SELinux.

Per le altre distribuzioni Linux che non hanno supporto SELinux, comincia dall'installare un sistema Linux normale. Tieni presente quanto segue:

• usa i filesystems ext2/ext3
• installa il compilatore C
• installa le librerie di sviluppo
• installa i sorgenti del kernel ( i files di configurazione del kernel in particolare sono molto utili)

• Getting Started HOWTO Un grande HOWTO su come cominciare con il nuovo (kernel 2.6) SELinux su Debian, di Faye Coker.
• Gentoo Linux Quick Start Guide.

Sui sistemi senza TCL/TK installate, su cui state eseguendo il quickinstall o avete selezionato di installare il pacchetto setools, potresti avere i seguenti errori:

    cd apol; make install
    make[3]: Entering directory `/home/installs/selinux/tools/setools/apol'
    gcc -Wall -g -I/usr/include -DUSE_SORTING -c apol_gui.c
    apol_gui.c:14:17: tcl.h: No such file or directory
    apol_gui.c:15:16: tk.h: No such file or directory

    # @echo "Building and installing SELinux tools"
    # cd tools && make install

Il problema molto probailmente è che non avete incluso il file 'mta.te' nella policy. Muovete semplicemente il file nella directory delle policy:

    cd policy/domains/program
    mv unused/mta.te .

Per xfs, la grandezza predefinita dell'Inode è 256 bytes, che non è abbastanza per poter contenere la sicurezza dei nomi "security.selinux" XATTR ed i suoi dati (all'incirca 200 bytes usati per altre cose). Così l'XATTR non potrà entrare nell'Inode ed avrà bisogno di un blocco di sua proprietà della grandezza di 4096 bytes su piattaforma i386. Avere 4096 bytes per file per l'uso di SE Linux XATTR è causa uno spreco eccessivo di spazio su disco.
Se userai l'opzione "-isize=512" alla creazione del filesystem XFS allora gli attributi SE Linux XATTR entreranno nell'Inode. Su alcuni Inodes lo spazio extra potrà essere utilizzato anche per altre cose, cosi da non avere necessariamente 256 - (XATTR size) bytes di spazio disco inutilizzato.
[Russell Coker]

Per reiserfs, gli attributi estesi non sono supportati a meno che tu non esegua una patch di supporto, es. usando le patch di Jeff Mahoney dal suo repositorio. Hans ha indicato in precedenza che non aggiungerà nuove caratteristiche a reiser3, così non accetterà queste patches nella linea di sviluppo di reiserfs. Se avete veramente bisogno di usare ReiserFS con SELinux, l'opzione di mount "-o context=" farà il lavoro ragionevolmente bene per le directory contenute come mail spools.

In modo similare alla domanda precedente, se hai un filesystem molto grande, come ad esempio decine di migliaia di files nella mail spool, o la cache di squid, etc. allora è molto più efficiente mettere questi oggetti in un filesystem separato montandolo con l'opzione "-o context=". Così facendo, potrai evitare di rietichettare ogni singolo file nel grande filesystem che è un processo veramente lento.

Usa i normali comandi Linux useradd e groupadd per creare rispettivamente utenti e gruppi. Questi creeranno l'account utente/gruppo ed assegneranno un identità SELinux. Gli accounts che non hanno identità SELinux otterranno l'identità user_u che gli permetterà di eseguire i compiti base per un utente.

Usa il normale comando Linux passwd per impostare la password di un utente. Come useradd, passwd è stato modificato per SELinux per impostare una password senza cambiare il contesto dei files /etc/passwd ed /etc/shadow in qualche altro che possa impedire alle cose di funzionare.

E' importante che i demoni dei servizi siano avviati con in giusto contesto. Se vengono avviati eseguendo /etc/init.d/nome probabilmente essi non verranno eseguiti in modo appropriato.

Per Fedora e RedHat Enterprise Linux, usate il normale comando , service (name) start/stop

Per Debian e Gentoo, usate il comando run_init per eseguire gli scripts in /etc/init.d con il contesto giusto, per esempio sshd:

run_init /etc/init.d/sshd start

che avvierà il demone sshd. Nota che run_init chiederà all'utente la loro password prima di performare la funzione: questo è per prevenire accessi non autorizzati alla funzionalità come ad esempio essere eseguita da un programma troiano.

Si. Il modo per ottenere questo è quello di cambiare l'ordine in /etc/security/default_contexts, cambia questo:

system_r:local_login_t user_r:user_t staff_r:staff_t sysadm_r:sysadm_t

in questo:

system_r:local_login_t sysadm_r:sysadm_t user_r:user_t staff_r:staff_t

Alternativamente, potresti creare un file /root/.default_contexts per prevaricare con questa stringa le impostazioni di sistema, affinché solo root abbia come possibilità predefinita di loggarsi come sysadm_r, e gli altri utenti che sono autorizzati per entrambe staff_r e sysadm_r rimarranno ancora su staff_r. Dovrai essere sicuro che local_login_t possa leggere il file /root/.default_contexts, etichettandolo con il default_context_t type o permettendo a local_login_t di leggere sysadm_home_t:file.
[Stephen Smalley]

Usa enforcing=0 nella linea di boot del tuo kernel per avviare nel modo permissive. Vedi /boot/grub/grub.conf per i sistemi che utilizzano il grub bootloader. Al contrario, impostando enforcing=1 avvierai il sistema nel modo enforcing.

Fedora Core ha una nuovo file sysconfig per fare questo molto più facilmente. Aggiungendo

SELINUX=permissive

nel file /etc/sysconfig/selinux. Altre opzioni sono enforcing e disabled. Nota che disabled qui non disabilita pienamente il kernel SELinux ( vedi la prossima domanda ) ma semplicemente avvia il sistema in modo permissivo e salta il caricamento della policy.

Questo assume che il tuo kernel è stato compilato con il flag CONFIG_SECURITY_SELINUX_DEVELOP che permette di avviare in modo permissive.

Il miglior modo è semplicemente quello di aggiungere selinux=0 alla linea di boot del kernel. In RedHat/Fedora usando il grub bootloader, dovrai editare /boot/grub/grub.conf ed aggiungere il parametro selinux=0 alla linea del kernel.

Nota comunque, che se farai questo i nuovi files che verranno creati saranno privi delle informazioni di contesto di sicurezza. Se riabiliterai SELinux con files di questo tipo probabilmente vorrai rietichettare l'intero filesystem, e potresti comunque avere dei problemi nell'avvio.

Questo assume che il tuo kernel è stato compilato con il parametro CONFIG_SECURITY_SELINUX_BOOTPARAM che abilita questo parametro di boot.

Ci sono un certo numero di modi. Il più veloce è eseguire

echo "1" >/selinux/enforce

che passa il kernel nella modalità enforcement. Contrariamente,

echo "0" >/selinux/enforce

passa alla modalità permissive.

In Fedora Core, puoi usare il comando setenforce con una opzione 0 o 1 per impostare il modo permissive o enforcing.

Nelle versioni più vecchie di SELinux, veniva usato il comando avc_toggle.

Ci sono un paio di modi per farlo. Primo, potresti editare policy/macros/admin_macros.te e rimuovere (o commentate) la seguente linea :

can_setenforce($1)

Se rimuoverai questa linea e ricaricherai la policy, non sarà possibile tornare indietro dalla modalità enforcing ( non senza cambiare almeno la policy, e probabilmente potresti aver bloccato anche questa ). Negando avc_toggle non potrà fermarti dal transitare in modo enforcing se hai avviato in modo permissive.
Un'altro modo è quello di compilare il kernel di SELinux senza il supporto Development. Questo creerà un kernel che verrà eseguito solo in modo enforcement che non potrà essere cambiato. Comunque per rendere veramente sicuro il tuo sistema dovrai rimuovere ogni kernel non-SELinux dalla configurazione di avvio, e assicurare fisicamente il sistema affinchè un attaccante non possa eseguire l'avvio da un media alternativo come un CD-Rom.
[Russell Coker]

Perchè il modo enforcement può far si di fermare l'esecuzione di un sacco di cose. Il modo permissive è buono per testare le applicazioni per identificare cosa stanno facendo che sarà negato in modo enforcement. L'idea è che dovresti eseguire il tuo sistema in modo permissive e raffinare le etichette dei tuoi files e le regole della tua policy. Quando avrai abbassato il livello degli errori ad un limite accettabile, allora cambierai nella modalità enforcement e continuerai a provare fino a che il sistema funzioni in modo appropriato senza garantire troppi permessi alle applicazioni.

Comincia leggendo il documento della NSA, Configuring the SELinux Policy, ed in particolare la sezione "Building and Applying the Policy" e la sezione "Customizing the Policy". Questo documento sarà veramente una buona partenza.

Faye Coker ha anche scritto un documento eccellente, Writing SE Linux Policy HOWTO ( versione PDF ).

Da qui, prova ad editare alcuni files di policy esistenti e guarda cosa succede quando fai i cambiamenti. Prova a impostare o editare le policies per alcuni semplici programmi server come ntpd e BIND.

Le policies di SELinux sono tutte scritte in un linguaggio macro chiamato m4. Per avere maggiori informazioni su come scrivere macro m4, eseguite info m4.

Ci sono un po di strumenti per aiutarti ad amministrare le policies di SELinux:

• La Hitachi Software Engineering Company in Giappone ha sviluppato alcuni tools basati su Webmin ottenibili qui.
• La Computer Privacy and Security Lab presso la University of North Texas sembrerebbe avere in progetto di disegnare strumenti per editare ed analizzare le policy di SELinux. Attualmente hanno in lista un analizzatore con GUI, qui.
• La Tresys ha SETools ed in particolare lo strumento sepcut che hanno sviluppato per editare le policy di SELinux.

Esegui make load per caricare la policy nel kernel se credi che la policy debba essere caricata ( es. la nuova policy è differente da quella che è già nel kernel ). Alternativamente, eseguendo make reload verrà ricaricata la nuova policy senza alcuna cura. Questo è utile se hai caricato la policy da alcuni altri files e vuoi ritornare alla policy di /etc/security/selinux/.
[Russell Coker]

Esegui make relabel dalla directory delle policy. Questo comando rietichetta tutti i files dell'intero sistema, il comando ci metterà un po anche su un piccolo server. Usando il comando SELinux setfiles con l'opzione "-s" puoi restringere la rietichettatura ad uno specifico gruppo di files.

Comincia eseguendo il programma su un sistema che è in modo permissivo, e annota tutte le voci delle violazioni di sicurezza dal file syslog ( /var/log/messages in molti casi ). Analizza con cura i messaggi di violazione della policy concernenti la tua applicazione e quali restrizioni dovrebbe avere e scrivi adeguate regole di policy.
Alternativamente, puoi far questo mediante un programma in perl chiamato audit2allow (chiamato newrules.pl nelle vecchie versioni di SELinux) che è nella directory della distribuzione SELinux - questo genererà le regole Type Enforcement che possono essere aggiunte alla tua policy. Comunque, c'è il rischio che audit2allow generi regole di policy che siano eccessivamente permissive per quello che stai facendo - il risultato delle definizione delle policy dovrà essere controllato con cura prima di installarlo.
Avrai bisogno di configurare una rietichettatura per i files dell'applicazione, e sarebbe meglio farlo prima di eseguire l'applicazione in modo permissive affinché le regole TE generate da audit2allow abbiano la corretta specifica dell'etichettatura del file.
Eventualmente riuscissi a eseguire l'applicazione ottenendo un piccolo numero di violazioni della policy, potresti passare il sistema in modo enforcement per verificare che l'applicazione funzioni correttamente.

Le ggi la relazione Configuring the SELinux Policy, che si trova nella distribuzione (selinux/doc/policy) o sul sito web di SELinux della NSA. Puoi anche leggere la documentazione su Type Enforcement (TE).
Un dominio è un attributo di sicurezza associato ad un processo. I processi con lo stesso dominio hanno lo stesso gruppo di permessi sullo stesso gruppo di oggetti. Una transizione di dominio avviene quando un processo cambia il suo dominio, convenzionalmente eseguendo un programma con un particolare tipo di ingresso. La transizione di dominio prevede un meccanismo di controllo per cambiare i permessi, quando ottenere i permessi, condividere permessi, o cambiare verso un gruppo di permessi completamente ortogonale. E' difficile evitare le transizioni di dominio. Se lo faceste, sarebbe meglio che non usaste SELinux.
[Stephen Smalley]

Nei sorgenti della distribuzione di selinux, il file policy/users specifica il gruppo di ruoli autorizzati per ogni utente. Ottenere l'intero gruppo di ruoli non è propriamente una cosa semplice perchè le dichiarazioni di ruolo sono ora distribuite trai files di dominio .te. I ruoli per i processi utente sono tipicamente definiti in policy/domains/user.te o policy/domains/admin.te. Potresti dare un occhiata agli strumenti di policy della Tresys come modo per vedere più facilmente la policy o amministrare gli utenti.
Quando sono installati, i sorgenti delle policy sono tipicamente posti in /etc/security/selinux/src/policy.
[Stephen Smalley]

L'utente sarà limitato ai ruoli autorizzati per quell'utente come specificato in policy/users. Se autorizzerete l'utente per ruoli multipli, allora egli potrà scegliere uno di questi ruoli al momento del login o successivamente via newrole. Qual'è il motivo di limitare l'utente ad un singolo ruolo al momento del login se potrà cambiarlo successivamente via newrole? Ovvio, potrai limitare il login a transitare verso un singolo dominio utente se vorrai forzare tutti gli utenti ad accedere inizialmente con un certo ruolo/dominio.
[Stephen Smalley]

allow - specifica il gruppo di permessi che sono garantiti, nessuno come impostazione predefinita (deny di ogni cosa a meno di essere esplicitamente permesso da una regola allow).
auditallow - specifica il gruppo di permessi che devono essere sottoposti ad auditing quando garantiti, nessuno come impostazione predefinita (non eseguire audit sui permessi garantiti a meno di essere specificatamente abilitati da una regola auditallow).
auditdeny - specifica il gruppo di permessi che dovranno essere sottoposti ad auditing quando negati, tutti come impostazione predefinita (esegui l'audit di tutti i dinieghi a meno che non sia stata esplicitata una regola dontaudit, complementare a quanto precedentemente manipolato dalle regole auditdeny).
[Stephen Smalley]

I programmi PHP sono difficili da rendere sicuri perchè sono eseguiti sotto lo stesso processo del server Apache : SELinux può cambiare i contesti di processo solamente quando avviene l'esecuzione di un processo. Questo vuol dire che i programmi PHP possono essere eseguiti solo sotto le regole di policy di Apache. Mentre questo scenario è significativamente più sicuro rispetto a un sistema non-SE, ci sono ovvie problematiche in quei programmi PHP che possono interferire con parti del web server che non dovrebbero toccare. Ciò potrebbe impattare sia sulla sicurezza del web server che del programma PHP. Eseguendo i programmi PHP come processi di tipo CGI esterni consentirebbe un cambiamento di contesto e permetterebbe un controllo via policy finemente granulare. Comunque, questo metodo ha ovvi problemi di prestazioni.

Se vuoi fare un cambiamento di policy generale sulle tue policy installate, un buon posto è nella directory domains/misc ( su un sistema RedHat/Fedora, /etc/security/selinux/src/policy/domains/misc/ ).
Create un file qui chiamato "local.te" e ponetevi le regole di policy locali. Questo renderà semplice incollare i tuoi cambiamenti locali con i nuovi rilasci delle policy di base. Il processo per compilare e caricare la policy prenderà automaticamente il tuo nuovo file.

Può un tentativo di caricamento di una policy o il caricamento di una nuova policy rimanere a metà strada fra un controllo di accesso o una decisione di rietichettatura?

I caricamenti delle policy sono atomici. La nuova policy è caricata inizialmente in una struttura temporanea, quindi vengono effettuati alcuni controlli di integrità, e poi viene installata come policy attiva, con il compimento dell'ultimo passaggio mentre viene tenuta bloccata la policy scrittura. La cache del vettore di accesso è quindi resettato e viene fornito un nuovo numero di sequenza della policy.
[Stephen Smalley]

C'è una nuova caratteristica in SELinux che consente di modificare una policy in esecuzione. Basilarmente puoi definire booleano in una policy quello che l'admin puo decidere di accendere o spegnere. Per permettere agli utenti di pingare puoi eseguire il seguente comando:

    > ping 4.2.2.2
    ping: icmp open socket: Permission denied
    > show_bools
    user_ping --> active: 0 pending: 0

    # change_bool user_ping 1

    > show_bools
    user_ping --> active: 1 pending: 1

    >ping 4.2.2.2
    PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data.
    64 bytes from 4.2.2.2: icmp_seq=0 ttl=248 time=10.0 ms
    64 bytes from 4.2.2.2: icmp_seq=1 ttl=248 time=10.6 ms

    show_bools
    user_ping --> active: 0 pending: 0

Potete considerare la possibilità di patchare un mail server per eseguire procmail per il recapito in uno speciale contesto utente. Quindi procmail potrà accedere con sicurezza al file .procmailrc e recapitare la posta nella home directory dell'utente, ma esso non potrà accedere alla home directory di un utente in un altro ruolo.

Comunque se usassi molteplici ruoli? Per un sistema come questo, sarebbe bello che tu avessi tre ruoli, staff_r (per i compiti amministrativi meno importanti), sysadm_r (per i compiti amministrativi seri - mkfs, fdisk, etc), e user_r (per gli utenti). Ora se vorrai che tutte le persone in staff_r abbiano anche un account in user_r per le loro email, allora potrai semplicemente resctingere procmail ad accedere solo a user_r.
[Russell Coker]

SELinux spedisce un sacco di messaggi alla console di sistema per scelta predefinita. Questo protrebbe essere molto noioso se sei impegnato sulla console per provare a risolvere qualche problema importante. Il seguente comando manderà via tutti i messaggi della priorità predefinita dalla console. Il valore predefinito è "7 4 1 7". Il secondo numero è la priorità del messaggio predefinito, impostandola a 7 renderà i messaggi predefiniti di una priorità troppo bassa per poter essere inviati in console.

echo "7 7 1 7" >/proc/sys/kernel/printk

Alternativamente, il comando

dmesg -n 1

sembrerebbe funzionare bene sui sistemi Fedora.

Quando sei in modo permissivo, SELinux logga ogni diniego una sola volta quindi aggiunge il permesso corrispondente alla cache affinché tu non debba essere sommerso da messaggi identici. Il diniego non sarà mostrato nuovamente fino a che l'inserimento nella cache non è riutilizzato. Puoi resettare la cache ricaricando la tua policy (es. eseguendo 'make reload' nella directory delle policy) o cambiando in modalità enforcing (e quindi opzionalmente ritornando in modo permissivo) usando echo 1 >/selinux/enforce (avc_toggle nelle vecchie versioni), assumendo che tu sia in un dominio che possa farlo.
Quando sei in modo enforcing, SELinux applica un limite di frequenza ai messaggi di audit per evitare attacchi di tipo flooding. Ciò è necessario anche con applicazioni benigne, poichè molte applicazioni non si preoccupano di controllare gli errori di codice in certe chiamate generando un abbondante flusso di dinieghi ripetuti. A lungo termine, ci piacerebbe vedere i dati di audit di SELinux amministrati da un sottosistema di audit del kernel separato piuttosto che il sistema di logging esistente.
[Stephen Smalley]

Il server DHCP ( dhcpd ) usa un socket di pacchetto che spesso riceve ogni pacchetto dell'interfaccia di rete. Può filtrare i pacchetti via socket filter dopo che è stato eseguito il controllo dei permessi.
La miglior soluzione è quella di aggiungere la seguente regola di policy:

dontaudit dhcpd_t domain:packet_socket recvfrom;

- oppure -

allow dhcpd_t domain:packet_socket recvfrom;

Così, ti sei ricordato di tenerti vicino un kernel non-SELinux non è vero? Con SELinux puoi sempre eseguire il boot del tuo sistema da un kernel standard ( o dal CD di installazione ) e correggere i problemi. Molti problemi provengono da installazioni incomplete ( come installare un programma /bin/login non patchato ), o da fallaci installazioni di policy.
Ad un certo punto, in passato, ho upgradato il kernel SELinux senza installare i tools e ricaricare la policy - questo ha causato un brutto pasticcio dove /bin/login si lamentava con questo messaggio "No SIDs found" e non mi permetteva di entrare. Ho visto che potevo riavviare con un kernel non-SELinux e rifare l'installazione.

Virtualmente ogni programma che normalmente viene eseguito sotto Linux sarà eseguito anche sotto SELinux ( in modo permissivo, è così ). Devi risolvere i problemi dell'applicazione eseguendo il programma con un kernel in modo permissivo dando un occhiata ai messaggi "denied" nei files di log. Puoi risolvere queste problematiche eseguendo l'utilità audit2allow per generare le nuove regole di policy che permetteranno che queste funzioni siano permesse dal kernel.

Succedono cose cattive se esegui l'aggiornamento ad una nuova versione del kernel che ha policy incompatibili con il precedente. Probabilmente hai dimenticato di installare la e/o rietichettare i filesystems prima di riavviare alla nuova versione. Esegui il boot del tuo sistema da un kernel non-SELinux e torna indietro a fare queste cose.
Se installi un kernel con una nuova versione di policy, allora avrai bisogno di una policy ed utilities corrispondente, in tal caso avrai bisogno di eseguire make install per caricare le nuove utilities e policy.
[Russell Coker]

La tavola dei SID è corrotta. Prova a loggarti con un metodo differente ( come una connessione via SSH ), altrimenti avrai bisogno di ripristinare avviando da un kernel non-SELinux kernel, quindi rietichettare il filesystem e ricaricare la policy ( make reset e make load ).

Non hai applicato la patch di SELinux al kernel LSM. Torna indietro e leggi il file README sull'applicazione della patch del kernel.

Prima di tutto, non eseguire il server X come root con o senza SELinux. Se eseguirai il server X come utente non-root allora tutto dovrebbe funzionare bene. Altrimenti, se rietichetti la home directory di root come user_home_dir_t allora andrà bene anche per root ( ma è una cattiva idea ). Se esegui X come sysadm_r:sysadm_t role allora anche questo funzionerà bene.
[Russell Coker]

Si. Ma hai bisogno di abilitare i domini relativi ad X (via sepcut o direttamente muovendo i files i files .te da policy/domains/program/unused) e ricaricando la policy. Avrai anche bisogno di un [xgk]dm patchato se vorrai eseguire un X Display Manager; la release dell'NSA non ne fornisce uno, ma altri hanno fornito le patches. Per quanto riguarda il sapere quando è sicuro passare alla modalità enforcing, dovrai studiare i tuoi logs (l'output di dmesg o /var/log/messages) per vedere cosa avrà il diniego se cambiassi in modalità enforcing. Tieni a mente che questo diniego è tipicamente registrato una sola volta quando sei in modalità permissiva (quindi ritenuto nella cache fino al ricaricamento della policy o ad un cambiamento in modo enforcing), perciò dovrai controllare l'intero log da quando hai avviato.
[Stephen Smalley]

SELinux include una copia di vixie-cron che è stata modificata per essere eseguita su un sistema SELinux. Se i files della crontable non sono propriamente etichettati, allora il crond non li eseguirà anche se il kernel è in modalità permissiva. Ciò può accadere in RedHat Linux, che pone i cron jobs in /var/spool/cron, invece di come ci si dovrebbe aspettare in un sistema normale unix /var/spool/cron/crontabs. Per correggere questo, edita il file file_contexts/program/crond.fc e controlla l'etichettatura dei tuoi files di cron, per RedHat 7.3 ci dovrebbero essere le linee:

/var/spool/cron system_u:object_r:cron_spool_t
/var/spool/cron/crontabs system_u:object_r:cron_spool_t
/var/spool/cron/.* system_u:object_r:user_cron_spool_t
/var/spool/cron/root system_u:object_r:sysadm_cron_spool_t
/var/spool/cron/crontabs/.* system_u:object_r:user_cron_spool_t
/var/spool/cron/crontabs/root system_u:object_r:sysadm_cron_spool_t

Il server sshd che ha SELinux è stato modificato per guardare ai SID degli utenti appena compiono il login, esso riporta questo errore se non può trovare il SID per l'utente che entra. Ci sono tre cause principali per questo errore:

• Non hai creato l'utente in modo appropriato. Ricorda di usare suseradd per creare utenti con SELinux. Controlla se puoi loggarti nella console con quel nome utente. Controlla che la password sia stata definita. Controlla che tu stia passando il corretto nome utente ad ssh.
• Il demone sshd non viene eseguito nel giusto contesto. Arrestalo con il comando:
  
  run_init /etc/init.d/sshd stop
  
  Quindi riavvialo con il comando:
  
  run_init /etc/init.d/sshd start
  
  
• Se l'utente è stato configurato per avere solo il ruolo sysadm_r allora il risultato è che sshd non permetterà all'utente di loggarsi. Il codice di sshd non può essere modificato per permettere ciò, ma sarà più facile configurare l'utente per avere un altro ruolo ( come staff_r o user_r ).

Questo accade su alcuni sistemi Debian quando il pacchetto expect non è installato. Installa il pacchetto Debian expect.

La causa più comune per questo è che lo script /etc/init.d/(name) non è stato etichettato correttamente; ha bisogno di essere del tipo initrc_exec_t. Usate questo comando:

chcon -t initrc_exec_t /etc/init.d/(name)

Per esempio,

    root@trillian:/etc/security/selinux/src/policy# execcon root:sysadm_r:sysadm_t make relabel

    /usr/sbin/setfiles: read 425 specifications
    /usr/sbin/setfiles: labeling files under /
    /: Operation not supported
    /usr/sbin/setfiles: unable to obtain attribute for file /
    /usr/sbin/setfiles: error while labeling files under /

Esegui id -c, e se ottieni questo:

system_u:system_r:sysadm_t

allora probabilmente non stai eseguendo il programma di login patchato, o non hai abilitato il modulo PAM, pam_selinux. Nota dal comando id che la porzione di contesto di identità utente non è stata impostata, ecco perchè newrole è confuso. In una shell non potrai mai ottenere l'identità system_u del contesto system_r. newrole controlla l'identità nel file passwd, e tu non hai nessun account system_u qui (e non dovrai averne).

Aggiungi una voce per questo tipo di file nella tua configurazione file_contexts con la notazione speciale "<>" al posto del contesto di sicurezza. Questo dice a setfiles di ignorarli.

Sembra che l'X server provi ad accedere a /dev/mem anche se non ne ha bisogno. Questo può essere fissato cambiando una linea in macros/program/xserver_macros.te da

dontaudit $1_xserver_t memory_device_t:chr_file read;

a

allow $1_xserver_t memory_device_t:chr_file rw_file_perms;

La policy di esempio proibisce la transazione diretta da sshd_t a sysadm_t, ma dovresti essere in grado di eseguire il login come staff_r:staff_t quindi cambiare ruolo via newrole a sysadm_r:sysadm_t.

sshd (via libselinux) chiede kernel quali contesti siano caricabili dal suo dominio per la tua identità utente (il kernel determina ciò basandosi sulla policy) quindi prende uno dei contesti raggiungibili basandosi su /etc/security/default_contexts oppure $HOME/.default_contexts. Non c'è un modo per specificare un contesto dal client.

Nota che è necessario un sshd patchato per i sistemi SELinux, se avete problemi, prima controllate di avere un installazione ssh che supporti SELinux. Prima veniva usato un modulo pam_selinux che supportava ssh, ma ora è deprecato.

Potresti vedere il seguente messaggio all'avvio:

There is already a security framework initialized, register_security failed.
Failure registering capabilities with the kernel
selinux_register_security: Registering secondary module capability
Capability LSM initialized

Questo non è un errore. Vuole solo dire che il modulo Capability non può registrarsi come modulo primario in LSM ( Linux Security Modules ) nel kernel. La terza linea indica che SELinux registra il modulo Capability come secondo modulo. Questo è abbastanza normale.

Il purging dei files in /tmp è stato aggiunto all'utility fixfiles per evitare problemi con i tipi sulle voci come /tmp/orbit* e /tmp/.ICE-unix - esso li rimuove durante la rietichettatura iniziale causando problemi ai desktops come KDE che potrebbero crashare ed uscire. I files saranno ricreati nel corretto dominio quando il software desktop li ricreerà (quando KDE sarà nuovamente avviato). Per questa ragione, siate prudenti ad usare fixfiles su un sistema in esecuzione. Speriamo che un messaggio di avviso sarà aggiunto all'utility ed alla sua pagina man.

SE Linux quando combinato con Exec-Shield controlla l'accesso allo stack di un eseguibile. Ogni binario ed oggetto shared necessita di avere una sezione una sezione che lo etichetti in termini di quando possa richiedere uno stack eseguibile. Generalmente il compilatore le genera automaticamente eccettuato il caso di codice assembler dove l'etichetta è omessa per impostazione predefinita (che indica che uno stack eseguibile è richiesto).

avc: denied { execstack } for pid=1234 comm="simpress.bin"
scontext=admin:staff_r:staff_t tcontext=admin:staff_r:staff_t tclass=process

ooimpress file.sxi
/usr/lib/openoffice.org2.0/program/simpress.bin: error while loading shared
libraries: libicudata.so.34: cannot enable executable stack as shared object
requires: Permission denied

Bene, se hao letto il README, e non c'è nulla che ti aiuti, allora ti suggerisco di controllare la pagina SELinux resources, se sei ancora bloccato, entra a far parte della SELinux mailing list e posta un messaggio al gruppo. Se troverai risposte utili, allora mettimi a conoscenza del tuo problema (e se possibile anche la risposta) ed io la aggiungerò a questa FAQ.