Product SiteDocumentation Site

14.5. Introduzione a SELinux

14.5.1. Princìpi

SELinux (Security Enhanced Linux) è un sistema di controllo degli accessi obbligatorio costruito sull'interfaccia LSM (Linux Security Modules) di Linux. In pratica, il kernel interroga SELinux prima di ogni chiamata di sistema per sapere se il processo è autorizzato ad eseguire una data operazione.
SELinux sfrutta una serie di regole, note comunemente come politiche (policy), per autorizzare o vietare operazioni. Queste regole sono difficili da creare. Fortunatamente vengono fornite due politiche standard (targeted e strict) per evitare il grosso del lavoro di configurazione.
Con SELinux, la gestione dei diritti è completamente diversa dai sistemi Unix tradizionali. I diritti di un processo dipendono dal proprio contesto di sicurezza. Il contesto è definito dall'identità dell'utente che ha avviato il processo, il ruolo e il dominio che l'utente presentava in quel momento. I diritti in realtà dipendono dal dominio, ma le transizioni attraverso i domini sono controllate dai ruoli. Infine, le possibili transizioni tra i ruoli dipendono dall'identità.
Contesti di sicurezza e utenti Unix

Figura 14.1. Contesti di sicurezza e utenti Unix

In practice, during login, the user gets assigned a default security context (depending on the roles that they should be able to endorse). This defines the current domain, and thus the domain that all new child processes will carry. If you want to change the current role and its associated domain, you must call newrole -r role_r -t domain_t (there is usually only a single domain allowed for a given role, the -t parameter can thus often be left out). This command authenticates you by asking you to type your password. This feature forbids programs to automatically switch roles. Such changes can only happen if they are explicitly allowed in the SELinux policy.
Ovviamente i diritti non si applicano a tutti i soggetti (file, directory, socket, dispositivi, ecc.). Possono variare da oggetto a oggetto. Per applicare i diritti, ad ogni oggetto viene associato un tipo (questo processo è conosciuto come etichettatura). I diritti del dominio allora si esprimono come insiemi di operazioni permesse(vietate) su quei tipi (e, indirettamente, su tutti gli oggetti etichettati con quel tipo).
Per impostazione predefinita, un programma eredita il relativo dominio dall'utente che lo ha eseguito, ma la politica standard di SELinux si aspetta che i programmi più importanti vengano eseguiti in domini dedicati. Per ottenere ciò, questi eseguibili sono etichettati con un tipo univoco (per esempio ssh è etichettato come ssh_exec_t, e quando il programma parte, automaticamente passa al dominio ssh_t). Questo meccanismo automatico di transizione di dominio permette di concedere esclusivamente i diritti richiesti da ciascun programma. Si tratta di un principio fondamentale di SELinux.
Transizioni automatiche attraverso domini

Figura 14.2. Transizioni automatiche attraverso domini

14.5.2. Impostare SELinux

Il supporto di SELinux è incluso nei kernel standard forniti da Debian. Gli strumenti di base in Unix supportano SELinux senza alcuna modifica. Abilitare SELinux quindi è relativamente semplice.
The apt install selinux-basics selinux-policy-defaulti auditd command will automatically install the packages required to configure an SELinux system.
Il pacchetto selinux-policy-default fornisce un insieme di regole standard. Per impostazione predefinita, questa politica limita l'accesso ad alcuni servizi fortemente esposti. Le sessioni utente non sono limitate ed è perciò improbabile che SELinux possa bloccare operazioni utente legittime. Comunque, questo aumenta la sicurezza per i servizi in esecuzione sulla macchina. Per installare un insieme di politiche equivalenti alle vecchie regole "restrittive", basta disabilitare il modulo unconfined (la gestione dei moduli è descritta in dettaglio più avanti in questa sezione).
Una volta che la politica è stata installata, bisogna etichettare tutti i file presenti (il che significa assegnare loro un tipo). Questa operazione dev'essere intrapresa manualmente con fixfiles relabel.
Il sistema SELinux a questo punto è pronto. Per abilitarlo, bisogna aggiungere il parametro selinux=1 security=selinux al kernel Linux. Il parametro audit=1 abilita la registrazione dei log di SELinux che memorizzano tutte le operazioni negate/non permesse. Da ultimo, il parametro enforcing=1 mette le regole in applicazione: senza di esso SELinux lavora nella modalità predefinita permissiva dove le azioni bloccate vengono raccolte nei log ma comunque eseguite. Bisogna perciò modificare il file di configurazione del bootloader GRUB per aggiungere i parametri desiderati. Un modo semplice per farlo è quello di modificare la variabile GRUB_CMDLINE_LINUX in /etc/default/grub e di lanciare update-grub. SELinux verrà attivato al riavvio.
Vale la pena notare che lo script selinux-activate automatizza queste operazioni e forza l'etichettatura all'avvio successivo (che evita la creazione di nuovi file non etichettati mentre SELinux non è ancora attivo e mentre l'etichettatura è in corso).

14.5.3. Gestire un sistema SELinux

La politica di SELinux corrisponde ad un insieme modulare di regole, e la loro installazione rileva e abilita i moduli in base ai servizi già presenti. Il sistema è così immediatamente operativo. Comunque, quando un servizio viene installato dopo l'applicazione della politica di SELinux, deve essere possibile abilitare manualmente il modulo corrispondente. Questo è lo scopo del comando semodule. Inoltre, dev'essere possibile definire i ruoli che ogni utente può assumere, che può essere fatto con il comando semanage.
Questi due comandi quindi vengono usati per apportare modifiche all'attuale configurazione di SELinux, che è memorizzata in /etc/selinux/default/. Diversamente da altri file di configurazione che si trovano in /etc/, tutti questi file non devono essere modificati manualmente. Si devono utilizzare i programmi dedicati a questo scopo.

14.5.3.1. Gestione dei moduli SELinux

I moduli disponibili per SELinux sono situati nella directory /usr/share/selinux/default/. Per abilitare uno di questi nella configurazione corrente, si usa semodule -i modulo.pp.bz2. L'estensione pp.bz2 sta per policy package(compressa con bzip2).
Si può rimuovere un modulo dalla configurazione corrente con semodule -r modulo. Infine, il comando semodule -l elenca i moduli che sono attualmente installati. Visualizza anche i loro numeri di versione. I moduli possono essere attivati selettivamente con semodule -e e disabilitai con semodule -d.
# semodule -i /usr/share/selinux/default/abrt.pp.bz2
libsemanage.semanage_direct_install_info: abrt module will be disabled after install as there is a disabled instance of this module present in the system.
# semodule -l
accountsd
acct
[...]
# semodule -e abrt
# semodule -d accountsd
# semodule -l
abrt
acct
[...]
# semodule -r abrt
libsemanage.semanage_direct_remove_key: abrt module at priority 100 is now active.
semodule carica immediatamente la nuova configurazione tranne nel caso si usi la sua opzione -n. Vale la pena notare che per impostazione predefinita il programma agisce sulla configurazione corrente (riportata nella variabile SELINUXTYPE in /etc/selinux/config), ma si può anche modificarne un'altra specificandola con l'opzione -s.

14.5.3.2. Gestione delle identità

Ogni volta che un utente effettua l'accesso, assume una determinata identità SELinux. Questa identità definisce i ruoli che egli può assumere. Queste due corrispondenze (utente-identità e identità-ruoli) sono configurabili con il comando semanage.
You should definitely read the semanage(8) manual page. All the managed concepts have their own manual page; for instance, semanage-login(8). Even if the command's syntax tends to be similar for all the concepts which are managed, it is recommended to read its manual page. You will find common options to most subcommands: -a to add, -d to delete, -m to modify, -l to list, and -t to indicate a type (or domain).
semanage login -l elenca la corrispondenza in uso degli identificatori degli utenti con le identità SELinux. Gli utenti che non hanno un riferimento esplicito acquisiscono l'identità riportata nella voce __default__. Il comando semanage login -a -s user_u utente associa l'identità user_u al dato utente. Infine, semanage login -d utente rimuove la voce corrispondente assegnata all'utente.
# semanage login -a -s user_u rhertzog
# semanage login -l

Login Name           SELinux User         MLS/MCS Range        Service

__default__          unconfined_u         s0-s0:c0.c1023       *
rhertzog             user_u               s0                   *
root                 unconfined_u         s0-s0:c0.c1023       *
# semanage login -d rhertzog
semanage user -l elenca la corrispondenza delle identità degli utenti in SELinux con i ruoli assegnati. L'aggiunta di una nuova identità richiede la definizione sia dei ruoli corrispondenti sia di un prefisso di etichetta utilizzato per assegnare un tipo ai file personali (/home/utente/*). Il prefisso deve essere preso da user, staff, e sysadm. Il prefisso «staff» ha come risultato file di tipo «staff_home_dir_t». Per creare una nuova identità per l'utente in SELinux basta lanciare semanage user -a -R ruoli -P prefisso identità. Infine, è possibile rimuovere un'identità di SELinux con semanage user -d identity.
# semanage user -a -R 'staff_r user_r' -P staff test_u
# semanage user -l

                Labeling   MLS/       MLS/                          
SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles

root            sysadm     s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r
staff_u         staff      s0         s0-s0:c0.c1023                 staff_r sysadm_r
sysadm_u        sysadm     s0         s0-s0:c0.c1023                 sysadm_r
system_u        user       s0         s0-s0:c0.c1023                 system_r
test_u          staff      s0         s0                             staff_r user_r
unconfined_u    unconfined s0         s0-s0:c0.c1023                 system_r unconfined_r
user_u          user       s0         s0                             user_r
# semanage user -d test_u

14.5.3.3. Gestire i contesti dei file, le porte e i booleani

Ogni modulo SELinux fornisce un insieme di regole per l'etichettatura dei file, ma è anche possibile aggiungerne di personalizzate per far fronte a casi specifici. Per esempio, se si vuole che il server web possa leggere i file dentro la gerarchia /srv/www/, si deve lanciare semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?" seguito da restorecon -R /srv/www/. Il primo comando registra le nuove regole sull'etichettatura e il secondo reimposta i tipi di file in base alle regole di etichettatura correnti.
In modo del tutto simile, le porte TCP/UDP sono etichettate in modo da assicurare che solo il rispettivo demone possa rimanere in ascolto su di esse. Per esempio, se si vuole che il server web rimanga in ascolto su porta 8080, è consigliabile seguire semanage port -m -t http_port_t -p tcp 8080.
Some SELinux modules export Boolean options that you can tweak to alter the behavior of the default rules. The getsebool utility can be used to inspect those options (getsebool boolean displays one option, and getsebool -a them all). The setsebool boolean value command changes the current value of a Boolean option. The -P option makes the change permanent, it means that the new value becomes the default and will be kept across reboots. The example below grants web servers an access to home directories (this is useful when users have personal websites in ~/public_html/).
# getsebool httpd_enable_homedirs
httpd_enable_homedirs --> off
# setsebool -P httpd_enable_homedirs on
# getsebool httpd_enable_homedirs
httpd_enable_homedirs --> on

14.5.4. Adattare le regole

Dato che la politica di SELinux è modulare, potrebbe essere interessante sviluppare nuovi moduli per le applicazioni (eventualmente personalizzate) che ne sono prive. Questi nuovi moduli quindi completerebbero la politica di riferimento.
Per creare nuovi moduli, è richiesto il pacchetto selinux-policy-dev oltre a selinux-policy-doc. Quest'ultimo contiene la documentazione delle regole standard (/usr/share/doc/selinux-policy-doc/html/) e file di esempio che possono essere usati come modelli per creare nuovi moduli. Installiamo questi file ed esaminiamoli più da vicino:
$ cp /usr/share/doc/selinux-policy-doc/Makefile.example Makefile
$ cp /usr/share/doc/selinux-policy-doc/example.fc ./
$ cp /usr/share/doc/selinux-policy-doc/example.if ./
$ cp /usr/share/doc/selinux-policy-doc/example.te ./
Il file .te è il più importante. Definisce le regole. Il file .fc definisce i "contesti dei file", che sono i tipi assegnati ai file relativi a questo modulo. I dati all'interno del file .fc sono usati durante la fase di etichettatura dei file. Infine, il file .if definisce l'interfaccia del modulo: si tratta di una serie di "funzioni pubbliche", che altri moduli possono utilizzare per interagire correttamente con il modulo che si sta creando.

14.5.4.1. Scrivere un file .fc

Analizzare l'esempio sotto dovrebbe essere sufficiente per capire la struttura di un file di questo tipo. Si possono usare espressioni regolari per assegnare lo stesso contesto di sicurezza a file multipli, oppure anche a un intero albero di directory.

Esempio 14.2. File example.fc

# myapp executable will have:
# label: system_u:object_r:myapp_exec_t
# MLS sensitivity: s0
# MCS categories: <none>

/usr/sbin/myapp         --      gen_context(system_u:object_r:myapp_exec_t,s0)

14.5.4.2. Scrivere un file .if benutze

Nell'esempio sotto, la prima interfaccia («miaapp_domtrans») controlla chi può eseguire l'applicazione. La seconda («miaapp_lettura_log») concede i diritti di lettura sui file di log dell'applicazione.
Ogni interfaccia deve generare un insieme valido di regole che può essere incluso in un file .te. Si deve perciò dichiarare tutti i tipi che si usano (con la macro gen_require), e usare direttive standard per concedere i diritti. Da notare, comunque, che si possono utilizzare le interfacce fornite dagli altri moduli. Nella prossima sezione si approfondirà maggiormente come esprimere questi diritti.

Esempio 14.3. File example.if

## <summary>Myapp example policy</summary>
## <desc>
##      <p>
##              More descriptive text about myapp.  The desc
##              tag can also use p, ul, and ol
##              html tags for formatting.
##      </p>
##      <p>
##              This policy supports the following myapp features:
##              <ul>
##              <li>Feature A</li>
##              <li>Feature B</li>
##              <li>Feature C</li>
##              </ul>
##      </p>
## </desc>
#

########################################
## <summary>
##      Execute a domain transition to run myapp.
## </summary>
## <param name="domain">
##      <summary>
##      Domain allowed to transition.
##      </summary>
## </param>
#
interface(`myapp_domtrans',`
        gen_require(`
                type myapp_t, myapp_exec_t;
        ')

        domtrans_pattern($1,myapp_exec_t,myapp_t)
')

########################################
## <summary>
##      Read myapp log files.
## </summary>
## <param name="domain">
##      <summary>
##      Domain allowed to read the log files.
##      </summary>
## </param>
#
interface(`myapp_read_log',`
        gen_require(`
                type myapp_log_t;
        ')

        logging_search_logs($1)
        allow $1 myapp_log_t:file read_file_perms;
')

14.5.4.3. Scrivere un file .te

Osservare il file example.te:
policy_module(example,1.0.0) 1 # a non-base module name must match the file name

########################################
#
# Declarations
#

type myapp_t; 2
type myapp_exec_t;
domain_type(myapp_t)
domain_entry_file(myapp_t, myapp_exec_t) 3

type myapp_log_t;
logging_log_file(myapp_log_t) 4

type myapp_tmp_t;
files_tmp_file(myapp_tmp_t)

########################################
#
# Myapp local policy
#

allow myapp_t myapp_log_t:file { read_file_perms append_file_perms }; 5

allow myapp_t myapp_tmp_t:file manage_file_perms;
files_tmp_filetrans(myapp_t,myapp_tmp_t,file)

1

Il modulo dev'essere identificato da nome e numero di versione. Questa direttiva è obbligatoria.

2

Se il modulo introduce nuovi tipi, deve dichiararli con direttive come questa. Non bisogna esitare a creare tanti tipi quanti necessari piuttosto che concedere troppi inutili diritti.

3

Queste interfacce definiscono il tipo miaapp_t come un dominio di processo che deve essere usato da ogni eseguibile etichettato con miaapp_exec_t. Implicitamente, ciò aggiunge l'attributo exec_type a tutti questi soggetti, che a loro volta permettono ad altri moduli di concedere i diritti di esecuzione su questi programmi: per esempio, il modulo userdomain concede ai processi con dominio user_t, staff_t e sysadm_t di eseguirli. I domini di altre applicazioni circoscritte non avranno i diritti di eseguirli, finché le regole non concedono loro diritti simili (è questo il caso, per esempio, di dpkg con il relativo dominio dpkg_t).

4

logging_log_file is an interface provided by the reference policy. It indicates that files labeled with the given type are log files which ought to benefit from the associated rules (for example, granting rights to logrotate so that it can manipulate them).

5

La direttiva allow è la direttiva base per autorizzare un'operazione. Il primo parametro è il dominio del processo a cui è concessa l'esecuzione dell'operazione. Il secondo definisce l'oggetto che un processo del primo dominio può manipolare. Questo parametro si definisce come «tipo:classe» dove tipo è il proprio tipo SELinux e classe descrive la natura dell'oggetto (file, directory, socket, fifo, ecc.). Infine, l'ultimo parametro descrive i permessi (le operazioni consentite).
I permessi sono definiti come un insieme di operazioni consentite e seguono questo modello: { operazione1 operazione2 }. Si possono usare comunque anche macro che rappresentano i permessi più comuni. L'elenco si trova in /usr/share/selinux/devel/include/support/obj_perm_sets.spt.
The following web page provides a relatively exhaustive list of object classes, and permissions that can be granted.
Ora si deve trovare l'insieme minimo di regole necessarie per assicurare che l'applicazione o il servizio in questione funzioni correttamente. Per ottenere ciò, bisogna avere una buona conoscenza di come funziona l'applicazione e di che genere di dati vengono gestiti e/o prodotti.
È comunque possibile un approccio empirico. Una volta che i soggetti rilevanti sono stati correttamente etichettati, si può usare l'applicazione in modalità permissiva: che verrebbero bloccate vengono registrate ma vengono comunque eseguite. Analizzando i log, si possono identificare le operazioni da consentire. Questo è un esempio di una di queste voci di log:
avc:  denied  { read write } for  pid=1876 comm="syslogd" name="xconsole" dev=tmpfs ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=fifo_file permissive=1
Per comprendere meglio questo messaggio, studiamolo pezzo per pezzo.

Tabella 14.1. Analisi di un tracciamento di SELinux

MessaggioDescrizione
avc: deniedUn'operazione è stata negata.
{ read write }Questa operazione ha richiesto i permessi di lettura e scrittura.
pid=1876Il processo con PID 1876 ha eseguito l'operazione (o ha tentato di eseguirla).
comm="syslogd"Il processo era un'istanza del programma syslogd.
name="xconsole"L'oggetto di destinazione è stato chiamato xconsole. A volte invece si può avere - con il percorso completo - anche un "percorso" variabile.
dev=tmpfsThe device hosting the target object is a tmpfs (an in-memory filesystem). For a real disk, you could see the partition hosting the object (for example, “sda3”).
ino=5510L'oggetto è identificato dall'inode numero 5510.
scontext=system_u:system_r:syslogd_t:s0Questo è il contesto di sicurezza del processo che ha eseguito l'operazione.
tcontext=system_u:object_r:device_t:s0Questo è il contesto di sicurezza dell'oggetto di destinazione.
tclass=fifo_fileL'oggetto di destinazione è un file FIFO.
By observing this log entry, it is possible to build a rule that would allow this operation. For example, allow syslogd_t device_t:fifo_file { read write }. This process can be automated, and it is exactly what the audit2allow command (of the policycoreutils package) offers. This approach is only useful if the various objects are already correctly labeled according to what must be confined. In any case, you will have to carefully review the generated rules and validate them according to your knowledge of the application. Effectively, this approach tends to grant more rights than are really required. The proper solution is often to create new types and to grant rights on those types only. It also happens that a denied operation isn't fatal to the application, in which case it might be better to just add a “dontaudit” rule to avoid the log entry despite the effective denial.

14.5.4.4. Compilare i file

Una volta che i 3 file (example.if, example.fc e example.te) corrispondono alle proprie aspettative per le nuove regole, rinominateli in myapp.extension e lanciare make NAME=devel per generare un modulo nel file myapp.pp (può essere immediatamente caricato con semodule -i myapp.pp). Se sono definiti diversi moduli, make creerà tutti i rispettivi file .pp.