Fedora Core 3 SELinux FAQ

SELinux (Security-Enhanced Linux) in Fedora Core è un implementazione del mandatory access control nel kernel di Linux che usa il Linux Security Modules (LSM) framework. La sicurezza standard di Linux è basata su un modello definito come discretionary access control.

In un modello DAC, i file e le risorse decisionali sono basate solamente sull'identità utente e il proprietario degli oggetti.  Ogni utente e programma eseguito da quell'utente ha completa discrezione sugli oggetti dell'utente. Software malizioso o difettoso può fare qualsiasi cosa con i files e le risorse controllate attraverso l'utente che ha avviato i processi. Se l'utente è il super-user o l'applicazione è setuid o setgid root, il processo può avere un livello di controllo root sull'intero file system.

Un sistema MAC non soffre di questi problemi.  Primo, puoi definire-amministrativamente una policy di sicurezza su tutti i processi ed oggetti.  Secondo, puoi controllare tutti i processi e gli oggetti, nel caso di SELinux mediante il kernel.  Terzo, le decisioni sono basate su tutte le informazioni di sicurezza rilevanti disponibili, e non solo sulla identità utente autenticata.

Il MAC sotto SELinux permette di fornire permessi granulari per tutti i soggetti (utenti, programmi, processi) ed oggetti (files, devices). In pratica, pensa ai soggetti come processi, ed gli oggetti come lo scopo di un operazione di un processo. Puoi garantire con sicurezza ad un processo solo i permessi che gli occorrono per eseguire la sua funzione, e niente di più.

L'implementazione di SELinux usa un role-based access control (RBAC), che fornisce un astrazione di controllo a livello-utente basata su ruoli, e sui Type Enforcement® (TE). TE usa una tabella (matrice) per manipolare i controlli di accesso, applicando le regole della policy basate sui tipi di processi ed oggetti.  I tipi di processo sono chiamati domini, ed un riferimento incrociato sulla matrice dei domini dei processi e del tipo degli oggetti definisce la loro interazione. Questo può fornire un controllo estremamente granulare per gli attori in un sistema Linux.

La policy SELinux descrive i permessi di accesso per tutti i soggetti e gli oggetti, esempio, l'intero sistema degli utenti, programmi, e processi ed i files ed i devices su cui agiscono. La policy di Fedora Core è contenuta in un pacchetto, con una pacchetto sorgente associato. Attualmente i pacchetti che contengono le policy sono:

I sorgenti delle policy risiedono in /etc/selinux/policyname/src/policy, quando sono installati, ed i files binari delle policy in /etc/selinux/policyname/policy. Il sorgente delle policy non è necessario per le installazioni ultra-minimali. La policy per i tipi ed i domini è configurata separatamente dal contesto di sicurezza per i soggetti e gli oggetti.

Inizialmente, quando SELinux fu incluso in Fedora Core, la policy strict di NSA fu applicata. A scopo di prova, ciò aiutò a trovare centinaia di problemi nella strict policy. In seguito, è divenne ovvio che applicare una singola strict policy ai molti ambienti degli utenti Fedora non era fattibile. Amministrare una singola strict policy per qualsiasi cosa diversa dall'installazione standard avrebbe richiesto un esperienza locale superiore.

A questo punto, gli sviluppatori SELinux rividero le loro scelte, e decisero di adottare una strategia differente. Fu deciso di creare una policy che puntasse a bloccare specifici demoni, specialmente quelli più vulnerabili agli attacchi o più devastanti per il sistema se corrotti o compromessi. Al resto del sistema è consentita l'esecuzione come fosse sotto la sicurezza standard di Linux, esempio, funzionare lo stesso se SELinux è abilitato o meno.

Sotto la policy targeted, molti processi sono eseguiti nel dominio unconfined_t. Come implica il nome, questi processi non sono per lo più confinati dalla policy SELinux. Questi sono comunque ancora governati dalla sicurezza standard di Linux/UNIX.

Specifici demoni di rete hanno policy scritte per loro, e la policy unconfined_t transita su queste policies quando l'applicazione viene avviata. Per esempio, al boot del sistema, init viene eseguito sotto la policy unconfined_t, ma quando viene avviato named, è transitato sotto il dominio named_t ed è bloccato dalla policy appropriata.

Per maggiori informazioni sull'abilitazione e disabilitazione delle policy targeted per ogni demone specifico, fate riferimento a How to use system-config-securitylevel.

Attualmente, la lista dei demoni è dhcpd, httpd (apache.te), named, nscd, ntpd, portmap, snmpd, squid, and syslogd. I files di policy per questi demoni si trovano in /etc/selinux/targeted/src/policy/domains/program.

In futuro, molti demoni saranno aggiunti alla policy di protezione targeted.

Gli sviluppatori di SELinux vorrebbero aggiungere eventualmente ftp e gli agenti di posta elettronica alla targeted policy. Ad esempio, vsftpd potrebbe funzionare in modo simile a login: dopo il log-in, un nuovo processo è eseguito sotto il contesto dell'utente (contesto utente reale o anonimo).

Un problema con gli agenti di posta elettronica è che hanno spesso hanno bisogno di manipolare files nelle home directory utente. Un obbiettivo della targeted policy è quello di evitare problemi di etichettatura nelle home directory degli utenti. Ci si sta ancora lavorando su.

La policy strict su Fedora Core funziona. La sfida è con gli ambienti unici di utenti differenti. Per farla funzionare nel tuo ambiente, avrai bisogno di aggiustare sia la policy che i tuoi sistemi.

Per aiutare a rendere semplice l'uso della strict policy, gli sviluppatori di SELinux hanno lavorato sul rendere il cambiamento da un policy all'altra semplice. Per esempio, system-config-securitylevel fa una rietichettatura negli scripts di avvio.

I file contexts sono usati dal comando setfiles per rendere persistenti le etichette che descrivono il contesto di sicurezza per un file o una directory.

Fedora Core è rilasciato con lo script fixfiles che supporta tre opzioni: check, restore, e relabel. Questo permette agli utenti di rietichettare il file system senza aver installato il pacchetto selinux-policy-targeted-sources. L'uso della linea di comando è molto più amichevole rispetto al comando setfiles standard.

La nuova opzione -Z è il metodo più immediato per mostrare il contesto di un soggetto o di un oggetto:

ls -alZ file.foo 
id -Z 
ps -eZ

Non c'è differenza fra un dominio ed un tipo, comunque il dominio è qualche volta usato per riferirsi al tipo di un processo. L'uso del dominio in questo modo discende dal tradizionale modello TE, dove i domini ed i tipi sono separati.

Il programma di installazione si comporta basandosi sulle scelte che fai nella schermata di Configurazione del Firewall. Di base la policy applicata è la targeted, che per scelta predefinita è attiva.

	Cambiare policy non è una cosa da prendere alla leggera.
	A meno che tu non stia provando una nuova policy su una macchina test a scopo di ricerca, dovresti seriamente considerare la situazione prima di cambiare policy su un sistema in produzione. Il modo di cambiare policy è semplice. Questo è un metodo abbastanza sicuro, ma deve prima essere provato su un sistema test.

Un metodo è quello di usare system-config-securitylevel per cambiare la policy e impostare il filesystem da rietichettare.

La seguente è la procedura manuale:

Puoi usare l'utilità star, che supporta gli attributi estesi che contengono le etichette dei contesti di sicurezza. Specifica il formato -xattr e exustar quando creai gli archivi.

ls -Z /var/log/maillog
-rw-------  root   root    system_u:object_r:var_log_t   /var/log/maillog
cd /var/log
star -xattr -H=exustar -c -f maillog.star ./maillog*

I percorsi assoluti possono sovrascrivere i dati esistenti

Se usi un percorso assoluto, come /var/log/maillog, quando decompatti l'archivio con star -c -f, i files verranno ripristinati nello stesso percorso in cui erano stati archiviati.  Il file maillog tenterà di scriverli in /var/log/maillog.  Potresti ricevere un avviso da star se i files che stanno per essere sovrascritti hanno una data più recente, ma non potrai contare su questo comportamento. Considera attentamente come costruire gli argomenti d'archiviazione.

Usa system-config-securitylevel per controllare i valori Booleani di specifici demoni. Per esempio, se ritieni di aver bisogno di disabilitare SELinux per Apache per eseguirlo correttamente nel tuo ambiente, puoi disabilitare il valore in system-config-securitylevel. Questo disattiva la transizione della policy definita in apache.te, lasciando rimanere httpd sotto la regolare sicurezza Linux.

Questo processo presume che hai abilitato le directories HTML pubbliche per gli utenti nella configurazione HTTP di Apache (/etc/httpd/conf/httpd.conf).  Questo processo copre solo il servizio di contenuti Web statici.  Per maggiori informazioni su Apache HTTP e SELinux, riferitevi a http://fedora.redhat.com/docs/selinux-apache-fc3/.

Aggiungi selinux=0 alla linea di comando del tuo kernel.

Sta attento quando disabiliti SELinux

Sta veramente attento nell'usare questa opzione.  Se esegui l'avvio con selinux=0, ogni file che hai creato mentre SELinux è disabilitato non avrà le informazioni di contesto SELinux. Dovrai come minimo rietichettare il file system, ed è possibile che non sarai in grado di avviare il sistema con selinux=1, necessitando un avvio in modalità single-user per il ripristino. Come alternativa a selinux=0, prova ad usare SELINUX=disabled in /etc/selinux/config.

Puoi specificare la modalità SELinux usando il file di configurazione /etc/sysconfig/selinux.

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= type of policy in use. Possible values are:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.
SELINUXTYPE=targeted

Impostando il valore su enforcing è uguale ad aggiungere enforcing=1 alla linea di comando quando avvii il kernel per attivare l'enforcing, mentre impostando il valore su permissive è come aggiungere enforcing=0 per disattivare l'enforcing. Nota che il parametro della linea di comando del kernel prevarica il file di configurazione.

Comunque, impostare il valore su disabled non è lo stesso di selinux=0 nel parametro di avvio del kernel.  Invece di disabilitare pienamente SELinux nel kernel, l'impostazione disabled disabilita l'enforcing e salta il caricamento della policy.

Questa situazione solitamente insorge quando non puoi eseguire un operazione che viene prevenuta dalla policy.  Esegui il comando setenforce 0 per disabilitare la modalità di enforcing in tempo reale.  Quando hai terminato, esegui setenforce 1 per riattivare l'enforcing.

	E' richiesto il ruolo sysadm_r
	Devi lanciare il comando setenforce con il ruolo sysadm_r; per farlo, usa il comando newrole. Alternativamente, se cambi su root usando su -, otterrai il ruolo sysadm_r automaticamente.

Aggiungi audit=1 alla linea di comando del kernel per attivare l'auditing alle system-call.  Aggiungi audit=0 alla linea di comando del kernel per disattivare l'auditing alle system-call.

L'auditing alle system-call è disattivato per impostazione predefinita. Quando è attivato, fornisce informazioni sulle system-call che erano in esecuzione quando SELinux genera un messaggio denied.  Questo può essere d'aiuto quando fai il debugging della policy.

Questa opzione al momento non è supportata. In futuro, verrà fornita un utilità per amministrare l'auditing.

Come root, esegui il comando /usr/sbin/sestatus -v.  Per maggiori informazioni, fa riferimento alla pagina di manuale di sestatus(8).

Questo messaggio vuol dire che l'attuale policy SELinux non permette all'applicazione di fare qualcosa. C'è un numero di ragioni per cui ciò può succedere.

Primo, uno dei files a cui l'applicazione prova ad accedere potrebbe essere etichettato male.  Se il messaggio AVC si riferisce ad un file specifico, controlla la sua etichetta corrente con ls -alZ /path/to/file.  Se vi sembra sbagliata, potrete provare ad usare restorecon -v /path/to/file. Se hai un gran numero di dinieghi relativi a files, potresti voler usare fixfiles relabel, o eseguire restorecon con l'opzione -R per rietichettare recursivamente il percorso di una directory.

Altre volte, i dinieghi possono essere dovuti ad un cambiamento nella configurazione del programma non ammesso dalla policy. Per esempio, se vuoi far si che Apache ascolti anche sulla port 8800, questo richiederà un cambiamento nella policy di sicurezza, apache.te. Vedi Lista Link Esterni per maggiori informazioni sulla scrittura delle policy.

Se hai difficoltà nel far funzionare un'applicazione specifica come Apache, vedi How to use system-config-securitylevel to work, see How to use system-config-securitylevel per sapere come disabilitare l'enforcement solo per quell'applicazione.

La tua partizione /home non è etichettata correttamente.  Puoi facilmente risolvere questo problema in due modi.

Se vuoi solamente rietichettare /home ricorsivamente:

/sbin/restorecon -v -R /home

Se vuoi essere sicuro che non ci siano altri files non correttamente rietichettati, puoi rietichettare l'intero filesystem:

/sbin/fixfiles relabel

Dovrai avere installato il pacchetto policycoreutils per usare fixfiles.

Puoi leggere i files da una distribuzione senza SELinux, o una con SELinux disabilitato. Comunque, i files creati dal sistema privo di SELinux non avranno un contesto di sicurezza, nemmeno l'avrà qualsiasi files che rimuoverai e ricreerai. Questo potrebbe essere un problema con files tipo ~/.bashrc. Dovrai rietichettare la tua /home quando ritornerai a Fedora Core.

NFS supporta in modo trasparente molti tipi di file system, e può essere usato per condividere directories tra sistemi SELinux e non-SELinux.

Quando monti un file system non-SELinux via NFS, per impostazione predefinita SELinux tratterà tutti i files nella condivisione come avessero contesto nfs_t. Potrai prevaricare il contesto predefinito impostandolo manualmente usando l'opzione context=.  Ad esempio, questo farà apparire i files nella directory NFS montata con un contesto di system_u:object_r:tmp_t in SELinux:

mount -t nfs -o context=system_u:object_r:tmp_t server:/shared/foo /mnt/foo

Quando SELinux esporta un file system via NFS, i files creati avranno il contesto della directory dove sono stati creati. In altre parole, la presenza di SELinux sul sistema remoto che ha montato la condivisione non ha effetto sui contesti di sicurezza locali.

Puoi creare il nuovo utente con il comando standard useradd. Prima dovrai diventare root; sotto la policy strict avrai bisogno di cambiare al ruolo sysadm_r. Questo cambio di contesto è stato incorporato nel comando su ed avviene automaticamente. Per la policy targeted, non avrai bisogno di cambiare ruolo, rimanendo in unconfined_t:

su - root
id -Z
root:system_r:unconfined_t
useradd auser
ls -Z /home
drwx------  auser   auser   root:object_r:user_home_dir_t /home/auser  

Il contesto iniziale per una nuova directory utente ha un identità di root.  In seguito la rietichettatura del file system cambierà l'identità a system_u.  Queste sono funzionalmente le stesse poichè il ruolo ed il tipo sono identici (object_r:user_home_dir_t.)

Il team di sviluppo di Fedora Core ha preso una direzione leggermente differente rispetto alla pratica di SELinux esistente.  Le transizioni del contesto di sicurezza adesso sono integrate in su via pam_selinux.  Questo semplifica enormemente l'uso del sistema.

In pratica, è come combinare il tradizionale su con il newrole di SELinux, in un singolo passo invece di due.

Altre forme di cambio d'identità di Linux/UNIX®, per esempio setuid(2), non causano un cambio d'identità SELinux.

Per esempio, se volevi escludere l'audit di dmesg, potresti inserire questa riga nel tuo file /etc/selinux/targeted/src/policy/dmesg.te

dontaudit dmesg_t userdomain:fd { use };

Questo eliminerà l'output d'errore dal terminale per tutti gli userdomains (user, staff e sysadm).

In modalità non-enforcing, avrai più messaggi che in modalità enforcing. Ciò avviene poichè il kernel sta loggando ogni diniego di accesso come fossi in modalità enforcing. Siccome non hai restrizioni, puoi fare più cose, che danno come risultato più log di diniego.

Per esempio, se un applicazione eseguita sotto la modalità enforcing ha il divieto provare a leggere un certo numero di files in una directory, essa verrà fermata all'inizio dell'azione. In modalità non-enforcing, l'applicazione non viene fermata dal traversare l'albero della directory, e riceverà un messaggio di diniego per ogni file letto nella directory.

La ragione più comune per un diniego silenzioso è quando la policy contiene un esplicita regola di dontaudit per sopprimere i messaggi di audit. La regola di dontaudit è spesso usata quando un segnale di diniego benigno riempie gli audit logs.

Per vedere il tuo particolare diniego, dovrai abilitare l'auditing di tutte le regole dontaudit:

cd /etc/selinux/targeted/src/policy 
make enableaudit
make load

	Abilitare l'output di dontaudit è verboso
	Abilitare l'auditing di tutte le regole dontaudit produrrà un gran numero di informazioni audit, molte delle quali irrilevanti per il tuo diniego. Usa questa tecnica solo se stai cercando un messaggio di diniego che sembra avvenire silenziosamente. Probabilmente desidererai ri-abilitare le regole dontaudit il più presto possibile.

Per ri-abilitare le regole dontaudit, fai così:

cd /etc/selinux/targeted/src/policy
make clean 
make load

SELinux disabilita intenzionalmente l'accesso ai dispositivi tty per impedire ai demoni la comunicazione verso il terminale di controllo. Questa comunicazione è un potenziale buco nella sicurezza poichè questi demoni possono inserire comandi nei terminali di controllo.  Un programma bacato o compromesso potrebbe causare seri problemi con questo.

Ci sono alcuni modi per permetterti di catturare lo STDOUT da questi demoni.  Un metodo è quello di eseguire il pipe dell'output al comando cat.

snmpd -v | cat

Quando fai il debug di un demone, potresti voler disattivare la transizione del demone al suo dominio specifico.  Puoi farlo usando system-config-securitylevel o setsebool dalla linea di comando.

Un opzione finale è quella di disattivare la modalità di enforcing durante il debug. Puoi farlo con setenforce 0, usando setenforce 1 per ri-abilitare SELinux quando hai terminato il debug.

Le policy si ricaricano da sole quando il pacchetto è aggiornato. Questo sostituisce il comando manuale make load.

In certe situazioni, può essere necessario rietichettare il file system. Questo potrebbe accadere per fissare gli errori di SELinux qualora i contesti dei files divenissero invalidi, o quando l'update della policy fa dei cambiamenti ai file_contexts.

Dopo aver rietichettato il filesystem, un reboot non è necessario, ma è utile per assicurare che ogni processo e programma sia eseguito nel dominio appropriato. Questo è altamente dipendente dai cambiamenti nella policy aggiornata.

Se hai installato i pacchetti sorgente delle policy, es. selinux-policy-strict, puoi eseguire questi comandi per rietichettare il file system.

cd /etc/selinux/targeted/src/policy
make
make relabel
reboot

Se non stai usando i sorgenti delle policy, un altro approccio è usare il comando fixfiles o avvantaggiarsi del meccanismo /.autorelabel:

fixfiles relabel
reboot

touch /.autorelabel
reboot

Si. I contesti di sicurezza per i files posseduti dal pacchetto sono immagazzinati nei dati dell'header del pacchetto. I contesti dei files sono impostati direttamente dopo la copia cpio, appena i files del pacchetto sono poggiati sul disco.

Un pacchetto policy come selinux-policy-targeted è un requisito per un installazione SELinux funzionante, mentre un pacchetto sorgente come selinux-policy-targeted-sources è richiesto se vuoi modificare la policy predefinita.

Il pacchetto policy ha i files minimi necessari per definire la policy di sicurezza di SELinux. Viene tenuto di ridotte dimensioni per avere minimi requisiti di installazione.

Il pacchetto dei sorgenti della policy contiene le definizioni sorgente in /etc/selinux/policyname/src/policy che sono richiesti per creare i files /etc/selinux/policyname/contexts/* e /etc/selinux/policyname/policy/policy.version. version è il numero di versione della policy.

La scelta di quali pacchetti installare è basata sul tipo di installazione. Se intendi usare solo la configurazione di sicurezza predefinita dagli sviluppatori Fedora Core, avrai bisogno solo del pacchetto policy. Se vorrai adattare la tua policy di sicurezza in qualsiasi modo, o vorrai eseguire setools, avrai bisogno di installare il pacchetto di sorgenti della policy.

Installando o aggiornando i pacchetti della policy, la nuova policy verrà caricata non appena installati i nuovi files. In modo analogo, installando o aggiornando il pacchetto di sorgenti della policy ricreerà sia il file policy.version che il file file_contexts, quindi verranno ricaricati come policy attuale effettiva.

Quando installi un pacchetto policy, i files binari pre-compilati della policy sono inseriti direttamente in /etc/selinux. Quando un pacchetto sorgente policy è installato o aggiornato, i files binari della policy vengono compilati in /etc/selinux/policyname/src/policy, quindi spostati in /etc/selinux/policyname/policy/.  I differenti ambienti di compilazione creeranno files finali che hanno differenti dimensioni, md5sums, e date.

C'è la possibilità che cambiamenti nei pacchetti della policy o nella policy rilasciata con un pacchetto applicativo possano causare errori, più dinieghi, o altri comportamenti sconosciuti. Per rimediare, puoi scoprire quale pacchetto causa il problema ripristinando policy e pacchetti applicativi uno alla volta. Se non vuoi tornare ad una pacchetto precedente, i files di configurazione della vecchia versione sono salvati con l'estensione di .rpmsave. Assicurati di consultare le mailing lists, bugzilla, ed IRC per aiutarti ad uscire dal problema. Se sei capace, scrivi un fix o una policy per risolvere il problema.

Il tuo aiuto è apprezzato infinitamente.  Puoi cominciare entrando a far parte della SELinux mailing list, fedora-selinux-list@redhat.com; puoi sottoscriverti e leggere gli archivi su http://www.redhat.com/mailman/listinfo/fedora-selinux-list.  Le FAQ non ufficiali hanno qualche informazione generica su come scrivere le policy (http://sourceforge.net/docman/display_doc.php?docid=14882&group_id=21266#BSP.1).  Un'altra nuova risorsa è il Writing SE Linux policy HOWTO (https://sourceforge.net/docman/display_doc.php?docid=21959&group_id=21266).

Il meglio su cui puoi scommettere è dare un occhiata ai files di policy in /etc/selinux/policyname/src/policy/ e provare a sperimentare. Osserva i messaggi avc denied in /var/log/messages per avere degli indizi.

Uno strumento utile per uno scrittore di policy è /usr/bin/audit2allow, che traduce i messaggi avc provenienti da /var/log/messages in regole che possono essere usate da SELinux.  Queste regole dovranno ovviamente essere rifinite.

Il comando audit2allow può ricevere l'input con tre metodi.  Il metodo predefinito è dallo standard input (STDIN).  Usando l'opzione -i legge l'input da /var/log/messages, e con l'opzione -d legge l'input dall'output di dmesg.

Per riottenere il controllo, disattiva i messaggi del kernel nella console usando dmesg -n 1.

Puoi provare la policy predefinita di SELinux installando solamente i pacchetti selinux-policy-policyname e policycoreutils. Senza il pacchetto dei sorgenti della policy installato, il comando fixfiles automatizzerà la rietichettatura del file system.

Il comando fixfiles relabel è l'equivalente di make relabel. Durante la rietichettatura, cancellerà tutti i files in /tmp, ripulendo i files che potrebbero avere vecchie etichette di contesto.

Altri comandi sono fixfiles check, che controlla i files con etichette errate, e fixfiles restore, che fissa i files mal etichettati ma non cancella i files in /tmp.  fixfiles non accetta una lista di directories come argomento, il suo scopo è rietichettare l'intero filesystem.  Se hai bisogno di rietichettare un percorso specifico di directory, usa restorecon.

Gli eseguibili KDE appaiono sempre come kdeinit, che limita ciò che può essere fatto con la policy di SELinux. Questo perchè ogni applicazione KDE viene eseguita nel dominio per kdeinit.

I problemi spesso vengono fuori quando si installa SELinux perchè non è possibile rietichettare /tmp e /var/tmp.  Non c'è un buon metodo di determinare quale file dovrebbe avere quale contesto.

La soluzione è quella di eseguire un pieno log out da KDE e rimuovere tutti i files temporanei di KDE:

rm -rf	/var/tmp/kdecache-<username>
rm -rf /var/tmp/<other_kde_files>

Al prossimo login, il problema dovrebbe essere risolto.

Fa attenzione agli spazi vuoti nel file /etc/sysconfig/selinux.  Il codice è molto sensibile agli spazi vuoti, anche ai tabulatori.

Il file system deve supportare le etichette xattr nel giusto namespace security.*.  Oltre a ext2/ext3, XFS ha recentemente aggiunto il supporto per le necessarie etichette.

Questa è una variabile difficile da quantificare, ed è pesantemente dipendente dalla grandezza del sistema su cui SELinux sta girando. L'ultima volta che le prestazioni sono state misurate, l'incidenza era circa del 7% per codice completamente non raffinato. I cambiamenti da allora sembrerebbero essere peggiorati in alcuni casi, tipo nel networking. Le performance e l'affinamento di SELinux sono una priorità del team di sviluppo.

Inizialmente, SELinux servirà ai server affacciati su Internet che eseguono poche, funzioni specializzate, dove è critico mantenere una sicurezza estremamente stretta. Una simile macchina è tipicamente priva di software extra e servizi, ed esegue un servizio molto mirato od un gruppo di servizi, come un Web server o un mail server.

In questi servers di nicchia, potrai bloccare la policy molto strettamente. Questo sarà facilitato dal piccolo numero di interazioni con gli altri componenti. In modo simile, una macchina dedicata che esegue un applicazione specialistica di terze parti sarà un buon candidato.

In futuro, SELinux è orientato a tutti gli ambienti. Per questo, la comunità e gli ISVs (independent software vendors) dovranno lavorare con gli sviluppatori SELinux per produrre le policy necessarie. Finora, è stata scritta una strict policy molto restrittiva, analogamente ad una targeted policy che mira a specifici, demoni vulnerabili.

Uno degli scopi nell'implementare la policy targeted di SELinux in Fedora Core è quello di permettere ad applicazioni di terze parti di funzionare senza modifiche. Questo funziona perchè la targeted policy è trasparente a quelle applicazioni che non prova a controllare e che ricadono nella sicurezza di Linux standard.  Queste applicazioni non saranno eseguite in maniera extra sicura.  Una policy deve essere scritta per far si che queste applicazioni siano protette dal MAC.

Ci sono talmente tante variazioni nelle applicazioni di terze parti che è impossibile predire come si comporterebbero con SELinux, anche eseguendo la targeted policy. Le problematiche insorgenti possono talvolta essere fissate nella policy.  Puoi capitare che SELinux ti mostri problemi di sicurezza con la tua applicazione che non sapevi di avere, richiedendo una modifica dell'applicazione per poter funzionare sotto SELinux.

Un importante valore che i testers ed utenti di Fedora Core porteranno alla comunità è l'estensivo testing di applicazioni di terze parti. Tenendo questo a mente, sei pregato di riportare le tue esperienze sull'appropriata mailing list (fedora-selinux-list@redhat.com) per discuterne.