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.