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.3. Contesti di sicurezza e utenti Unix

In pratica, durante l'accesso, all'utente viene assegnato un contesto di sicurezza predefinito (a seconda dei ruoli che è abilitato ad assumere). Questo definisce il dominio corrente, e di conseguenza il dominio che tutti i suoi processi figli acquisiranno. Se si vuole variare il ruolo corrente e il dominio associato, si deve eseguire newrole -r ruolo_r -t dominio_t (di solito esiste un solo dominio permesso per un dato ruolo, per cui il parametro -t si può tralasciare). Questo comando permette l'autenticazione su inserimento della propria password. Questa caratteristica impedisce ai programmi di muoversi automaticamente tra i ruoli. Tali cambiamenti possono avvenire solo se esplicitamente ammessi nella politica di SELinux.
Obviously the rights do not apply to all objects (files, directories, sockets, devices, etc.). They can vary from object to object. To achieve this, each object is associated to a type (this is known as labeling). Domains' rights are thus expressed with sets of (dis)allowed operations on those types (and, indirectly, on all objects which are labeled with the given type).
By default, a program inherits its domain from the user who started it, but the standard SELinux policies expect many important programs to run in dedicated domains. To achieve this, those executables are labeled with a dedicated type (for example ssh is labeled with ssh_exec_t, and when the program starts, it automatically switches to the ssh_t domain). This automatic domain transition mechanism makes it possible to grant only the rights required by each program. It is a fundamental principle of SELinux.
Transizioni automatiche attraverso domini

Figura 14.4. 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-default command will automatically install the packages required to configure an SELinux system.
The selinux-policy-default package contains a set of standard rules. By default, this policy only restricts access for a few widely exposed services. The user sessions are not restricted and it is thus unlikely that SELinux would block legitimate user operations. However, this does enhance the security of system services running on the machine. To setup a policy equivalent to the old “strict” rules, you just have to disable the unconfined module (modules management is detailed further in this section).
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.
The SELinux system is now ready. To enable it, you should add the selinux=1 security=selinux parameter to the Linux kernel. The audit=1 parameter enables SELinux logging which records all the denied operations. Finally, the enforcing=1 parameter brings the rules into application: without it SELinux works in its default permissive mode where denied actions are logged but still executed. You should thus modify the GRUB bootloader configuration file to append the desired parameters. One easy way to do this is to modify the GRUB_CMDLINE_LINUX variable in /etc/default/grub and to run update-grub. SELinux will be active after a reboot.
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

Available SELinux modules are stored in the /usr/share/selinux/default/ directory. To enable one of these modules in the current configuration, you should use semodule -i module.pp.bz2. The pp.bz2 extension stands for policy package (compressed with bzip2).
Removing a module from the current configuration is done with semodule -r module. Finally, the semodule -l command lists the modules which are currently installed. It also outputs their version numbers. Modules can be selectively enabled with semodule -e and disabled with semodule -d.
# semodule -i /usr/share/selinux/default/abrt.pp.bz2
# semodule -l
abrt    1.5.0   Disabled
accountsd       1.1.0   
acct    1.6.0   
[...]
# semodule -e abrt
# semodule -d accountsd
# semodule -l
abrt    1.5.0
accountsd       1.1.0   Disabled
acct    1.6.0   
[...]
# semodule -r abrt
# semodule -l
accountsd       1.1.0   Disabled
acct    1.6.0   
[...]
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.
Bisogna assolutamente leggere la pagina di manuale semanage(8), anche se la sintassi del comando sembra essere simile per tutti i concetti che vengono gestiti. Si troveranno opzioni comuni a tutti i sotto-comandi: -a per aggiungere, -d per eliminare, -m per modificare, -l per elencare, e -t per indicare un tipo (o un dominio).
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         SystemLow-SystemHigh *
rhertzog             user_u               SystemLow            *
root                 unconfined_u         SystemLow-SystemHigh *
system_u             system_u             SystemLow-SystemHigh *
# 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 un prefisso di etichetta utilizzato per assegnare un tipo ai file personali (/home/utente/*). 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, con semanage user -d identità si rimuove una di tali identità.
# 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     SystemLow  SystemLow-SystemHigh  staff_r sysadm_r system_r
staff_u         staff      SystemLow  SystemLow-SystemHigh  staff_r sysadm_r
sysadm_u        sysadm     SystemLow  SystemLow-SystemHigh  sysadm_r
system_u        user       SystemLow  SystemLow-SystemHigh  system_r
test_u          staff      SystemLow  SystemLow             staff_r user_r
unconfined_u    unconfined SystemLow  SystemLow-SystemHigh  system_r unconfined_r
user_u          user       SystemLow  SystemLow             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.
Similarly, TCP/UDP ports are labeled in a way that ensures that only the corresponding daemons can listen to them. For instance, if you want the web server to be able to listen on port 8080, you should run semanage port -m -t http_port_t -p tcp 8080.
Alcuni moduli SELinux esportano opzioni booleane che si possono personalizzare per variare il comportamento delle regole predefinite. L'utilità getsebool viene usata per ispezionare tali opzioni (getsebool booleano mostra un'opzione, e getsebool -a le mostra tutte). Il comando setsebool booleano valore modifica il valore corrente di un'opzione booleana. L'opzione -P rende permanente la modifica, cioè il nuovo valore diventa il predefinito e questo rimarrà tale nei successivi riavvii. L'esempio sotto concede ai web server l'accesso alle directory home (utile quando gli utenti hanno siti web personali 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 ./
The .te file is the most important one. It defines the rules. The .fc file defines the “file contexts”, that is the types assigned to files related to this module. The data within the .fc file are used during the file labeling step. Finally, the .if file defines the interface of the module: it is a set of “public functions” that other modules can use to properly interact with the module that you're creating.

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

# l'eseguibile miaapp avrà:
# label: system_u:object_r:miaapp_exec_t
# sensibilità MLS: s0
# categorie MCS : <nessuna>

/usr/sbin/miaapp         --      gen_context(system_u:object_r:miaapp_exec_t,s0)

14.5.4.2. Scrivere un file .if

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>Miaapp policy di esempio</summary>
## <desc>
##      <p>
##              Testo maggiormente descrittivo su miaapp.  Nel tag <desc>
##              si possono usare anche i tag html <p>, <ul>, e <ol>
##              per la formattazione.
##      </p>
##      <p>
##              Questa politica fornisce le seguenti caratteristiche di miaapp:
##              <ul>
##              <li>Caratteristica A</li>
##              <li>Caratteristica B</li>
##              <li>Caratteristica C</li>
##              </ul>
##      </p>
## </desc>
#

########################################
## <summary>
##      Esegue una trasizione di dominio per lanciare miaapp.
## </summary>
## <param name="domain">
##      Dominio con permesso di transizione.
## </param>
#
interface(`miaapp_domtrans',`
        gen_require(`
                type miaapp_t, miaapp_exec_t;
        ')

        domtrans_pattern($1,miaapp_exec_t,miaapp_t)
')

########################################
## <summary>
##      Legge i file di log di miaapp.
## </summary>
## <param name="domain">
##      Domini con permessi di lettura dei file di log.
## </param>
#
interface(`miaapp_lettura_log',`
        gen_require(`
                type miaapp_log_t;
        ')

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

14.5.4.3. Scrivere un file .te

Osservare il file example.te:
policy_module(miaapp,1.0.0) 1

########################################
#
# Dichiarazioni
#

type miaapp_t; 2
type miaapp_exec_t;
domain_type(miaapp_t)
domain_entry_file(miaapp_t, miaapp_exec_t) 3

type miaapp_log_t;
logging_log_file(miaapp_log_t) 4

type miaapp_tmp_t;
files_tmp_file(miaapp_tmp_t)

########################################
#
# Policy locale di miaapp
#

allow miaapp_t miaapp_log_t:file { read_file_perms append_file_perms }; 5

allow miaapp_t miaapp_tmp_t:file manage_file_perms;
files_tmp_filetrans(miaapp_t,miaapp_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 è un'interfaccia fornita dalla politica di riferimento. Essa indica che i file etichettati con quel dato tipo sono file di log che possono beneficiare delle regole associate (per esempio concedendo i diritti a logrotate in modo che possa manipolarli).

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).
Permissions are defined as the set of allowed operations and follow this template: { operation1 operation2 }. However, you can also use macros representing the most useful permissions. The /usr/share/selinux/devel/include/support/obj_perm_sets.spt lists them.
La seguente pagina web fornisce una lista relativamente esaustiva delle classi di soggetti, e i permessi che possono essere consentiti.
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"The target object was named xconsole. Sometimes you can also have a “path” variable — with the full path — instead.
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.
Dall'osservazione di questa voce di log, è possibilie costruire una regola che può permettere questa operazione. Per esempio: allow syslogd_t device_t:fifo_file { read write }. Questo processo può essere automatizzato, ed è esattamente ciò che offre il comando audit2allow (del pacchetto policycoreutils). Questo approccio è utile solo se i vari soggetti sono già etichettati correttamente secondo ciò che dev'essere ristretto. In ogni caso, bisognerà rivedere attentamente le regole generate e validarle a seconda della propria conoscenza dell'applicazione. In effetti, questo approccio tende a concedere più diritti di quelli realmente necessari. La soluzione corretta è spesso quella di creare nuovi tipi e di concedere i diritti solo a quei tipi. Può anche accadere che negare un'operazione non sia fatale per l'applicazione, nel qual caso sarebbe meglio aggiungere una regola «dontaudit» per evitare la voce di log nonostante l'effettivo diniego.

14.5.4.4. Compilare i file

Once the 3 files (example.if, example.fc, and example.te) match your expectations for the new rules, just run make NAME=devel to generate a module in the example.pp file (you can immediately load it with semodule -i example.pp). If several modules are defined, make will create all the corresponding .pp files.