Fedora Core 5 SELinux FAQ

SELinux (Security-Enhanced Linux) in Fedora Core è un implementazione del mandatory access control nel kernel di Linux usando il framework Linux Security Modules (LSM). La sicurezza standard di Linux è un modello 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, potete definire amministrativamente una policy di sicurezza su tutti i processi ed oggetti. Secondo, potete 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, pensate ai soggetti come processi, ed gli oggetti come lo scopo di un operazione di un processo. Potete 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 o matrice per manipolare i controlli di accesso, forzando le regole della policy basate sui tipi di processo ed oggetto. 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 sistema fornisce 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, ovvero, 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:

Maggiori informazioni sulle differenti policies disponibili in SELinux possono essere trovate su http://fedoraproject.org/wiki/SELinux/Policies.

Inizialmente, quando SELinux fu incluso in Fedora Core, fu forzato l'uso della policy strict di NSA. A scopo di prova, questo espose effettivamente centinaia di problemi nella strict policy. In più, dimostrò che applicare una singola strict policy ai molteplici ambienti degli utenti Fedora non era fattibile. Per amministrare una singola strict policy per qualsiasi cosa diversa dall'installazione standard richiederebbe una perizia locale.

A questo punto, gli sviluppatori SELinux rividero le loro scelte, e decisero di provare una strategia differente. Decisero di creare una policy targeted che bloccasse specifici demoni, specialmente quelli più vulnerabili agli attacchi o più devastanti per il sistema se corrotti o compromessi. Il resto del sistema è eseguito esattamente come se fosse sotto la sicurezza standard DAC di Linux.

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, comunque, sono ancora governati dalla sicurezza standard DAC di Linux.

Quei demoni di rete che sono indirizzati nella policy targeted transitano nella policy targeted quando le applicazioni vengono avviate. Per esempio, al boot del sistema, init viene eseguito sotto la policy unconfined_t, ma quando named viene avviato, transita sotto il dominio named_t ed è bloccato dalla policy appropriata.

Per maggiori informazioni sull'abilitazione e disabilitazione della policy targeted per ognuno dei specifici demoni, fate riferimento a How to use system-config-securitylevel.

Maggiori informazioni sulle differenti policies disponibili in SELinux possono essere trovate su http://fedoraproject.org/wiki/SELinux/Policies.

Attualmente, l'elenco dei programmi è approssimativamente:

accton, amanda, httpd (apache), arpwatch, pam, automount, avahi, named, bluez, lilo, grub, canna, comsat, cpucontrol, cpuspeed, cups, cvs, cyrus, dbskkd, dbus, dhcpd, dictd, dmidecode, dovecot, fetchmail, fingerd, ftpd (vsftpd, proftpd, and muddleftpd), gpm, hald, hotplug, howl, innd, kerberos, ktalkd, openldap, auditd, syslog, logwatch, lpd, lvm, mailman, module-init-tools, mount, mysql, NetworkManager, NIS, nscd, ntp, pegasus, portmap, postfix, postgresql, pppd, pptp, privoxy, procmail, radiusd, radvd, rlogin, nfs, rsync, samba, saslauthd, snmpd, spamd, squid, stunnel, dhcpc, ifconfig, sysstat, tcp wrappers, telnetd, tftpd, updfstab, user management (passwd, useradd, etc.), crack, uucpd, vpnc, webalizer, xend, xfs, zebra

La policy strict su Fedora Core funziona. E' sfidata dagli ambienti unici dei differenti utenti. Per usare la strict policy nel vostro ambiente, avrete bisogno di calibrare finemente sia la policy che i sistemi.

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

Maggiori informazioni sulle differenti policies disponibili in SELinux possono essere trovate su http://fedoraproject.org/wiki/SELinux/Policies.

La policy mls è simile alla policy strict, ma aggiunge ulteriori campi ai contesti di sicurezza per separarne i livelli. SELinux può usare questi livelli per separare i dati in un ambiente che richieda una stretta separazione gerarchica. Un tipico esempio è l'ambiente militare, dove i dati ad un certo livello sono classificati. Questa policy è rivolta a questa sorta di ambienti, e probabilmente non vi è utile a meno di non ricadere in questa categoria.

Maggiori informazioni sulle differenti policies disponibili in SELinux possono essere trovate su http://fedoraproject.org/wiki/SELinux/Policies.

La Reference Policy è un nuovo progetto mantenuto da Tresys Technology (http://www.tresys.com/) disegnato per riscrivere l'intera policy SELinux in modo che sia più facile da usare e comprendere. Per fare questo, usa i concetti di modularità, astrazione, ed ben definite interfacce. Fate riferimento a http://serefpolicy.sourceforge.net/ per maggiori informazioni sulla Reference Policy.

Nota che la Reference Policy non è un nuovo tipo di policy, come la targeted o la strict. Piuttosto, è una nuova base da cui poter costruire quelle policies. Le policies targeted, strict, e mls possono essere compilate dalla Reference Policy. Infatti uno degli obbiettivi del disegno della Reference Policy è quello di avere un singolo, unificato albero dei sorgenti per le differenti varianti di policy.

Le policies di Fedora nella versione 1.x sono basate sull'esempio della policy tradizionale. Le policies della versione 2.x (usate in Fedora Core 5) sono basate sulla Reference Policy.

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

Fedora Core viene distribuita con lo script fixfiles, che supporta tre opzioni: check, restore, e relabel. Questo script 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 è talvolta usato per riferirsi al tipo di processo. L'uso del dominio in questo modo discende dal modello Domain and Type Enforcement (DTE), dove i domini ed i tipi sono separati.

Prima di Fedora Core 5, le policies SELinux erano monolitiche, significando che erano compilate in un singolo binario di policy. Per fare dei cambiamenti o aggiunte a quella policy, un amministratore doveva cambiare l'intera policy. Con Fedora Core 5, la policy è ora modulare. Ciò significa che sviluppatori di terze parti possono rilasciare moduli di policy con le loro applicazioni, che possono poi essere aggiunte alla policy senza dover cambiare l'intera policy un po come si fa per i moduli del kernel che possono aggiungere funzionalità al kernel senza dover riavviare l'intero sistema.

Attualmente, questo funziona, separando i passi di compilazione e link nella procedura di creazione della policy. I moduli della policy sono compilati dal sorgente, e linkati quando installati nel deposito del modulo (vedete Managed Policy). Questa policy linkata è quindi caricata nel kernel per l'enforcement.

Il comando primario per trattare con i moduli è semodule, che vi permetterà di eseguire le funzioni di base come installare, aggiornare, o rimuovere moduli. Altri comandi utili includono checkmodule, che è il compilatore di moduli ed è installato con il checkpolicy rpm, ed il semodule_package, che crea un file di pacchetto policy package (.pp) da un modulo di policy compilato.

I moduli sono di solito immagazzinati come files di pacchetto policy (estensione .pp) in /usr/share/selinux/policyname/. Li troverete almeno il base.pp, che è il modulo base.

Per vedere come scrivere un semplice modulo di policy, controllate su Local Policy Customizations.

Prima di Fedora Core 5, le policies SELinux erano gestite come files di configurazione editabili dall'utente in etc. Sfortunatamente, questo rende difficile sopperire a molte delle problematiche di usabilità insorte con SELinux. Così, una nuova libreria, libsemanage, fu aggiunta per fornire strumenti in userspace, un interfaccia per rendere più facile l'amministrazione della policy. Tutta l'amministrazione della policy dovrebbe usare questa libreria per accedere al deposito della policy. Il deposito della policy contiene tutte le informazioni della policy, e si trova in /etc/selinux/policyname/modules/.

Non dovreste mai editare il deposito direttamente. Invece, dovreste usare strumenti che puntino verso libsemanage. Un esempio di strumento è semanage, che è uno strumento a linea di comando per amministrare gran parte della policy tipo le mappature utente SELinux, le mappature di porta SELinux, e le voci di contesto dei file. Altri strumenti ad esempio che usano libsemanage includono semodule che lo usa per amministrare i moduli di policy SELinux installati nel repositorio della policy e setsebool che lo usa per amministrare le booleane di SELinux. In più, strumenti grafici sono attualmente in fase di sviluppo per utilizzare le funzionalità fornite da libsemanage.

Il programma di installazione segue le scelte che fate nella schermata Configurazione del Firewall. La policy prescelta in esecuzione è la policy targeted, ed è attiva per impostazione predefinita.

La risposta potrebbe essere di nulla. Ci sono molti utenti Fedora che non sanno neanche che stanno usando SELinux. SELinux fornisce la protezione per i loro sistemi con una configurazione out-of-the-box. Detto questo, ci sono un paio di cose che un amministratore potrebbe fare per configurare il proprio sistema. Queste includono:

Usate system-config-securitylevel conosciuta anche come lo strumento grafico Configurazione del livello di sicurezza, per controllare i valori booleani di specifici demoni. Per esempio, se ritenete di aver bisogno di disabilitare SELinux per Apache, per eseguirlo correttamente nel vostro ambiente, potete disabilitarne il valore in system-config-securitylevel. Questo cambiamento disattiva la transizione alla policy definita in apache.te, permettendo ad httpd di rimanere sotto la regolare sicurezza DAC Linux.

Siccome Fedora Core 5 usa una policy modulare, non potrete più avere i sorgenti completi della policy. Ora, potrete creare solo un modulo di policy per la vostra locale personalizzazione di policy. Per farlo, seguite i seguenti passi.

	I moduli sono identificati unicamente dal nome
	Questo vuol dire che se dopo inserite un altro local.pp, sostituirà quello appena caricato. Perciò, dovete tenere questo local.te a disposizione, e farci delle aggiunte se necessitate fare ulteriori personalizzazioni della policy. Se lo perdete, ma volete comunque mantenere la vostra policy precedente, chiamate il nuovo modulo di policy locale in qualche altro modo (diciamo local2.te).

Se avete specifici messaggi AVC potete usare audit2allow per generare un file Type Enforcement che sia pronto ad essere caricato come modulo della policy.

audit2allow -M local < /tmp/avcs

Questo crea un local.pp che potete caricare nel kernel usando semodule -i local.pp. Potete anche editare il local.te per fare personalizzazioni aggiuntive. Per creare un modulo che permetta tutti i dinieghi dall'ultimo riavvio che potete poi personalizzare, eseguite quanto segue:

audit2allow -m local -l -i /var/log/messages > local.te

Notate che quanto riportato sopra assume che voi non stiate usando il demone audit. Se state usando il demone audit, allora dovete usare /var/log/audit/audit.log invece di /var/log/messages come vostro file di log. Questo genera un file local.te, che è simile al seguente:

module local 1.0;

require {
        class file { append execute execute_no_trans getattr ioctl read write };
        type httpd_t;
        type httpd_w3c_script_exec_t;
 };


allow httpd_t httpd_w3c_script_exec_t:file { execute execute_no_trans getattr ioctl read };

Potete editare a mano questo file, rimuovendo le istruzioni allow che non volete permettere, quindi ricompilatelo e ricaricatelo usando

	Importante
	Per poter caricare questo pacchetto di policy appena creato nel kernel, dovrete necessariamente eseguire semodule -i local.pp Notate che se installate un altro modulo chiamato local, esso sostituirà questo modulo. Se volete mantenere queste regole, allora dovrete appendere ulteriori personalizzazioni future a questo local.te, o dare alle ulteriori personalizzazioni un nome differente.

Il tuo aiuto è veramente apprezzato.

Inoltre, da Fedora Core 5 la policy è basata sulla Reference Policy, potreste dare un occhiata alla documentazione sulla sua pagina di progetto. Un'altra sorgente di informazione eccellente sono i files di esempio della policy in /usr/share/doc/selinux-policy->version< e /usr/share/selinux/devel.

Se volete creare un nuovo dominio di policy, potete guardare ai files di interfaccia nelle sub-directory /usr/share/selinux/devel. Li c'è anche uno strumento per aiutarvi a cominciare. La seguente procedura è un esempio:

Ora potrete cominciare a collezionare messaggi avc. Potrete usare audit2allow per tradurre i messaggi avc in regole allow e cominciare ad aggiornare il vostro file mydaemon.te. Dovrete cercare quindi le macro di interfaccia nella directory /usr/share/selinux/devel/include ed usarle direttamente, audit2allow -R tenterà di trovare le interfacce che coincidano con la regola allow. Se volete più esempi di policy, potete sempre installare l'rpm src selinux-policy, che contiene tutti i files policy te per la policy reference.

	Siate cauti quando cambiate policy
	A meno che non stiate provando una nuova policy su una macchina test a scopo di ricerca, dovreste seriamente considerare la situazione prima di passare ad una policy differente su un sistema in produzione. Il modo di cambiare è lineare. Questo metodo è abbastanza sicuro, ma deve prima essere provato su un sistema test.

Per usare il metodo automatico, eseguite lo strumento Configurazione del livello di sicurezza. Dal menù principale della GUI, selezionate Desktop → Amministrazione → Livello di sicurezza, o da un terminale, eseguite system-config-securitylevel. Cambiate la policy come desiderate ed assicuratevi che l'opzione Rietichetta al prossimo riavvio sia abilitata.

Potete anche eseguire questi passi manualmente con la seguente procedura:

Potete usare l'utilità star, che supporta gli attributi estesi che contengono le etichette dei contesti di sicurezza. Specificate le opzioni -xattr e -H=exustar quando create 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 usate un percorso assoluto, tipo /var/log/maillog, quando decompattate 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. Potreste 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. Considerate attentamente come costruire gli argomenti d'archiviazione.

Questo processo presume che avete abilitato le directories HTML pubbliche per gli utenti nel file di configurazione di Apache, /etc/httpd/conf/httpd.conf. Questo processo concerne solo il servizio di contenuti Web statici. Per maggiori informazioni su Apache HTTP e SELinux, fate riferimento a http://fedora.redhat.com/docs/selinux-apache-fc3/.

Impostate SELINUX=disabled in /etc/selinux/config.

In alternativa, potete aggiungere selinux=0 ai parametri del kernel. Comunque questa opzione non è raccomandata.

	Fate attenzione quando disabilitate SELinux
	Se avviate con selinux=0, qualsiasi file creato mentre SELinux è disabilitato non avrà le informazioni di contesto SELinux. Il file system è segnato per la rietichettatura al prossimo avvio. Se un problema imprevisto vi impedisce di riavviare normalmente, potreste aver bisogno di avviare in modalità single-user per il ripristino. Aggiungete l'opzione emergency ai parametri di avvio del kernel.

Potete 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

Impostare il valore ad enforcing è come aggiungere enforcing=1 nei parametri di avvio del kernel. Impostare il valore a permissive è come aggiungere enforcing=0 nei parametri di avvio del kernel.

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

	Precedenza di configurazione SELinux
	I parametri della linea di comando del kernel prevaricano il file di configurazione.

Occasionalmente potreste aver necessità di eseguire un operazione non permessa dalla policy. Eseguite il comando setenforce 0 per disabilitare la modalità di enforcing in tempo reale. Quando avete terminato, eseguite setenforce 1 per riattivare l'enforcing.

	Il ruolo sysadm_r è necessario per la policy strict
	Dovete lanciare il comando setenforce con il ruolo sysadm_r se state usando la policy strict. Se state usando la policy targeted standard, allora non è necessario. Usate il comando newrole per assumere questo ruolo.

Aggiungete audit=1 alla linea di comando del kernel per attivare l'auditing delle chiamate di sistema. Aggiungete audit=0 alla linea di comando del kernel per disattivare l'auditing delle chiamate di sistema.

L'auditing delle chiamate di sistema è on per impostazione predefinita. Quando è attivo, fornisce informazioni sulle chiamate di sistema che erano in esecuzione quando SELinux ha generato un messaggio denied. Il messaggio d'errore è d'aiuto quando si esegue il debugging della policy.

Per farlo, eseguite auditctl -e 0. Notate che questo comando non avrà effetto sull'auditing dei dinieghi SELinux AVC.

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

A pochissimi domini nel mondo SELinux è permesso di leggere il file /etc/shadow. Ci sono delle regole restrittive che prevengono gli scrittori di policy dallo scrivere codice come

allow mydomain_t shadow_t:file read;

In RHEL4 potete impostare il vostro dominio per usare il comando unix_chkpwd. Il modo più semplice è usare l'attributo unix_chkpwd. Così se state scrivendo una policy per un demone ftpd dovrete scrivere qualcosa come

daemon_domain(vsftpd, `auth_chkpwd')

Questo creerà un contesto dove vsftpd_t -> chkpwd_exec_t -> system_chkpwd_t potrà leggere /etc/shadow, mentre vsftpd_t non sarà capace di leggerlo.

In Fedora Core 5/RHEL5, aggiungete la regola

auth_domtrans_chk_passwd(vsftpd_t)

Dovete eseguire il comando semodule -i myapp.pp. Questo modifica la policy registrata sulla vostra macchina. Il vostro modulo di policy è ora caricato con il resto della policy. Potete anche rimuovere il file pp dal sistema.

semodule -l elenca i moduli attualmente caricati.

#semodule -i 
myapp   1.2.1

Se successivamente volete rimuovere il pacchetto della policy, potete eseguire semodule -r myapp.

In Fedora Core 2 e 3, i messaggi AVC di SELinux si potevano trovare in /var/log/messages. In Fedora Core 4, è stato aggiunto il demone audit, e questi messaggi sono stati spostati in /var/log/audit/audit.log. In Fedora Core 5, il demone audit non è installato per impostazione predefinita, di conseguenza questi messaggi si trovano in /var/log/messages a meno che non abbiate scelto di installare il demone audit, nel qual caso i messaggi AVC si troveranno in /var/log/audit/audit.log.

Questo messaggio significa che la policy SELinux attuale non permette all'applicazione di fare qualcosa. Ci sono un certo numero di ragioni per cui ciò può accadere.

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, controllate la sua etichetta corrente con ls -alZ /path/to/file. Se vi sembra sbagliata, potrete provare ad usare restorecon -v /path/to/file per ripristinare il contesto predefinito del file. Se avete un gran numero di dinieghi relativi a files, potreste voler usare fixfiles relabel, o eseguire restorecon -R /path per rietichettare recursivamente il percorso di una directory.

Delle volte, i dinieghi sono causati da un cambiamento nella configurazione del programma che fa scattare il messaggio di diniego. Per esempio, se volete che Apache ascolti anche sulla porta 8800, dovrete cambiare anche la policy di sicurezza, apache.te. Fate riferimento a Elenco link esterni per maggiori informazioni sulla scrittura delle policy.

Se avete difficoltà nel far funzionare un'applicazione specifica come Apache, fate riferimento a How to use system-config-securitylevel per sapere come disabilitare l'enforcement solo per quell'applicazione.

La vostra partizione /home non è etichettata correttamente. Potete facilmente risolvere questo problema in due modi differenti.

Se volete solamente rietichettare /home ricorsivamente:

/sbin/restorecon -v -R /home

Se volete essere sicuri che non ci siano altri files non correttamente etichettati, potete rietichettare l'intero filesystem:

/sbin/fixfiles relabel

Dovrete avere installato il pacchetto policycoreutils per usare fixfiles.

Potete 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. Dovrete rietichettare la /home quando riavvierete il sistema Fedora Core con SELinux abilitato.

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

Quando montate un file system non-SELinux via NFS, per impostazione predefinita SELinux tratterà tutti i files nella condivisione come avessero contesto nfs_t. Potrete prevaricare il contesto predefinito impostandolo manualmente usando l'opzione context=. Il seguente comando 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.

Potete creare il nuovo utente con il comando standard useradd. Prima dovrete diventare root. Sotto la policy strict avrete bisogno di cambiare al ruolo sysadm_r con il seguente comando:

newrole -r sysadm_r

Per la policy targeted non avrete 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.)

In precedenti versioni di Fedora Core, le transizioni dei contesti di sicurezza erano integrate nel su via pam_selinux. Questo ha generato più difficoltà che benefici, e non è abbastanza necessario su un sistema che esegue la targeted policy. Perciò, questo non è più il caso. Adesso, su/sudo cambiano la sola identità Linux. Dovrete usare newrole per cambiare l'identità, il ruolo o il livello SELinux.

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

Per esempio, se volevate escludere l'audit di dmesg, potreste inserire questo nel vostro file dmesg.te:

dontaudit dmesg_t userdomain:fd { use };

Questo eliminerà l'output dell'errore dal terminale per tutti i domini utente, inclusi user, staff e sysadm.

In modalità non-enforcing, riceverete più messaggi che in modalità enforcing. Il kernel logga ogni diniego di accesso come foste in modalità enforcing. Siccome non siete ristretti dalla forzosità della policy, potete fare più azioni, che risultano in maggiori log di diniego.

Se un applicazione eseguita in modalità enforcing ha il divieto di leggere un certo numero di files in una directory, essa verrà fermata una volta cominciata l'azione. In modalità non-enforcing, l'applicazione non viene fermata dal traversare l'albero della directory, e genererà un messaggio di diniego per ogni file letto nella directory.

La ragione più comune per un diniego silenzioso è quando la policy contiene una regola esplicita dontaudit per sopprimere i messaggi audit. La regola dontaudit è spesso usata in questo modo quando un diniego benigno sta riempiendo i log di audit.

Per cercare il tuo particolare diniego, abilitate l'auditing di tutte le regole dontaudit:

semodule -b /usr/share/selinux/targeted/enableaudit.pp

	Abilitato dontaudit l'output è verboso
	Abilitando l'auditing di tutte le regole dontaudit produrrà un gran numero di informazioni di audit, gran parte delle quali è irrilevante per il tuo diniego. Usate questa tecnica solo se state cercando specificatamente un messaggio audit per un diniego che sembra avvenire silenziosamente. Dovete ri-abilitare le regole dontaudit al più presto possibile.

Una volta trovato il vostro problema potrete resettare alle impostazioni predefinite eseguendo

semodule -b /usr/share/selinux/targeted/base.pp

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 usare questo buco causando seri problemi.

Ci sono un po di altri modi per catturare lo standard output dai demoni. Un metodo è quello di eseguire il pipe dell'output al comando cat.

snmpd -v | cat

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

Un opzione finale è quella di disabilitare la modalità enforcing durante il debugging. Impartite il seguente comando setenforce 0 per disabilitare la modalità enforcing ed usate il comando setenforce 1 per riabilitare SELinux quando avete terminato il debugging.

La policy si ricarica da sola quando il pacchetto è aggiornato. Questo comportamento sostituisce il comando manuale make load.

In certe situazioni, potreste dover rietichettare il file system. Questo potrebbe accadere per fissare gli errori di SELinux qualora i contesti dei files divenissero non validi, o quando l'aggiornamento della policy fa dei cambiamenti al file /etc/selinux/targeted/contexts/files/file_contexts.

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

Per rietichettare, avete diverse opzioni. Potreste usare il comando fixfiles:

fixfiles relabel reboot

In alternativa, usate il meccanismo /.autorelabel:

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 messi su disco.

Quando installate un pacchetto policy, i files binari pre-compilati della policy sono inseriti direttamente in /etc/selinux. I differenti ambienti di compilazione creeranno files finali che hanno differenti dimensioni ed MD5 checksums.

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. Potete scoprire quale pacchetto causa il problema ripristinando policy e pacchetti applicativi uno alla volta. Se non volete tornare ad una pacchetto precedente, i files di configurazione della vecchia versione sono salvati con l'estensione .rpmsave. Usate le mailing lists, bugzilla, ed IRC per aiutarvi a lavorare al problema. Se ne siete capaci, scrivete o fissate la policy per risolvere il problema.

Per riottenere il controllo, disattivate i messaggi del kernel alla console con questo comando:

dmesg -n 1

Potete provare la policy predefinita di SELinux installando solamente i pacchetti selinux-policy-policyname e policycoreutils. Senza i sorgenti della policy installati, 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. Il comando fixfiles non accetta una lista di directories come argomento, poichè il suo scopo è rietichettare l'intero filesystem. Se avete bisogno di rietichettare una specifica directory, usate restorecon.

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

I problemi spesso insorgono 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.

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

Abbiamo cominciato a confinare in qualche modo il dominio unconfined_t. SELinux restringe certe operazioni di protezione della memoria. La seguente è una lista sia di quei dinieghi, che delle possibili ragioni e soluzioni a questi dinieghi. Per maggiori informazioni su queste restrizioni, guardate http://people.redhat.com/drepper/selinux-mem.html.

Queste sono visibili in /var/log/messages (o /var/log/audit/audit.log se usate il demone audit) come dinieghi avc. Queste sono anche mostrate quando vengono eseguiti programmi con errori come

error while loading shared libraries: /usr/lib/libavutil.so.49:
cannot restore segment prot after reloc: Permission denied

che indica che la libreria sta tentando di eseguire una text relocation e fallisce. Le text relocation sono malfatte, ma possono essere permesse mediante il suggerimento riportato in seguito. Sotto vediamo sia i permessi sulla memoria SELinux che sono negati, sia i suggerimenti per risolvere questi dinieghi.

restorecon reset /etc/modprobe.conf context system_u:object_r:etc_runtime_t->system_u:object_r:modules_conf_t
restorecon reset /etc/cups/ppd/homehp.ppd context user_u:object_r:cupsd_etc_t->system_u:object_r:cupsd_rw_etc_t

Durante il processo di aggiornamento, il pacchetto selinux esegue restorecon sulle differenze fra il file_context della policy installata in precedenza ed il nuovo contesto della policy installata. Questo mantiene la correttezza dei contesti dei file su disco.

libsepol.sepol_genbools_array: boolean hidd_disable_trans no longer in policy

Questo indica che la policy aggiornata ha rimosso la booleana dalla policy.

Potete usare il comando semanage per definire porte aggiuntive. Diciamo ad esempio che volete consentire ad httpd di ascoltare sulla porta 8082. Potreste inserire il comando.

semanage port -a -p tcp -t http_port_t 8082

Le traduzioni sono gestite attraverso libsemanage. Usate semanage translation -l per elencare alcune delle traduzioni correnti.

# semanage translation -l
Level                     Translation

s0
s0-s0:c0.c255             SystemLow-SystemHigh
s0:c0.c255                SystemHigh

Ora selezionate una categoria non utilizzata. Diciamo che volete aggiungere Payroll come traduzione, e s0:c6 non è utilizzato.

# semanage translation -a -T Payroll s0:c6
# semanage translation -l
Level                     Translation

s0
s0-s0:c0.c255             SystemLow-SystemHigh
s0:c0.c255                SystemHigh
s0:c6                     Payroll

Potete modificare la gamma delle categorie con cui un utente può loggarsi usando semanage, come si vede in questo esempio.

# semanage login -a -r s0-Payroll csellers
# semanage login -l

Login Name                SELinux User              MLS/MCS Range            

__default__               user_u                    s0                       
csellers                  user_u                    s0-Payroll               
root                      root                      SystemLow-SystemHigh

Nel precedente esempio, all'utente csellers è stato dato accesso alla categoria Payroll con il primo comando, come indicato nell'elenco dell'output dal secondo comando.

Primo, non dovete mai permettere ad un servizio di sistema di eseguire nulla di ciò che scrive. Questo da ad un attaccante la capacità di uploadare codice malizioso sul server ed eseguirlo, che è qualcosa che volete prevenire.

Se avete la mera necessità di permettere ai vostri script di creare files (non-eseguibili), questo è possibile. Detto questo, dovreste evitare di avere applicazioni di sistema che scrivono nella directory /tmp, poichè anche gli utenti tendono ad usare la directory /tmp. Sarebbe meglio creare una directory da qualche altra parte che possa essere posseduta dal processo apache e permettere al vostro script di scriverci. Dovrete etichettare la directory httpd_sys_script_rw_t, che permetterà ad apache di leggere e scrivere files in quella directory. Questa directory potrà essere locata ovunque apache possa raggiungerla (anche $HOME/public_html/).

Avete bisogno di far identificare lo swapfile a SELinux impostando il suco contesto di file a swapfile_t.

chcon -t swapfile_t SWAPFILE

Per i files, relabelfrom significa "Può il dominio D rietichettare un file da (es. attualmente in) tipo T1?" e relabelto significa "Può il dominio D rietichettare un file al tipo T2?", così entrambe i controlli sono applicati sula rietichettatura di un file, dove T1 è il tipo originale e T2 è il nuovo tipo specificato dal programma.

Documentazione utile da vedere:

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

Notate che il supporto SELinux XFS non funziona nella serie di kernel 2.6.14 e 2.6.15, ma è stato fissato (aggirando il problema) nella 2.6.16. Il vostro kernel dovrà includere questo fix se scegliete di usare XFS con SELinux.

Questa è una variabile difficile da quantificare, ed è pesantemente dipendente dall'affinamento e dall'uso 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 affinato. Successivi cambiamenti in componenti di sistema come il networking sembrerebbero aver peggiorato la situazione in alcuni casi. Le prestazioni e l'affinamento di SELinux continuano ad essere una priorità del team di sviluppo.

Inizialmente, SELinux è stato usato per i server affacciati su Internet che eseguono poche, funzioni specializzate, dove è critico mantenere una sicurezza estremamente stretta. Gli amministratori tipicamente privano una simile macchina di software e servizi extra, ed eseguono un gruppo di servizi ristrettissimo, molto mirato. Un Web server o un mail server sono un buon esempio.

In questi servers di nicchia, potrete bloccare la policy molto strettamente. Questo sarà facilitato dal piccolo numero di interazioni con gli altri componenti. Una macchina dedicata che esegue un applicazione specialistica di terze parti sarà anch'essa un buon candidato.

In futuro, SELinux sarà indirizzato a tutti gli ambienti. Per poter raggiungere questo obbiettivo, la comunità e gli independent software vendors (ISVs) dovranno lavorare con gli sviluppatori SELinux per produrre le policy necessarie. Finora, sono state scritte una strict policy molto restrittiva, ed una targeted policy che mira a specifici, demoni vulnerabili.

Per maggiori informazioni su queste policies, fate riferimento a What is SELinux policy? e What is the SELinux targeted policy?.

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. 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. Voi od un altro fornitore dovrete scrivere una policy per proteggere queste applicazioni con la sicurezza MAC.

E' impossibile predire come si comporterebbe ogni applicazione di terze parti con SELinux, anche eseguendo la targeted policy. Potreste essere in grado di risolvere problematiche insorgenti cambiando la policy. Potreste trovare che SELinux esponga problemi di sicurezza sconosciuti con la vostra applicazione. Potreste dover modificare l'applicazione per farla funzionare sotto SELinux.

Notate che con l'aggiunta di Policy Modules, è ora possibile per gli sviluppatori di terze parti includere moduli di policy con le loro applicazioni. Se siete uno sviluppatore si terze pari o un manutentore di pacchetti, siete pregati di considerare l'inclusione di un modulo di policy nel vostro pacchetto. Questo permetterà di rendere sicuro il comportamento della vostra applicazione con la potenza di SELinux per ogni utente che installa il pacchetto.

Un valore importante che i testers e gli utenti di Fedora Core portano alla comunità è l'estensivo prova di applicativi di terze parti. Con questo a mente, siete pregati di portare le vostre esperienze alla mailing list appropriata per le discussioni, come la mailing list fedora-selinux. Per maggiori informazioni su questa lista, fate riferimento a http://www.redhat.com/mailman/listinfo/fedora-selinux-list/.