Implementazione del controllo degli accessi obbligatorio con SELinux o AppArmor in Linux

Per superare i limiti e aumentare i meccanismi di sicurezza forniti dai permessi standard ugo/rwx e dagli elenchi di controllo degli accessi, la National Security Agency (NSA) degli Stati Uniti ha ideato un sistema flessibile Mandatory Access Control (MAC) metodo noto come SELinux (abbreviazione di Security Enhanced Linux) per limitare, tra le altre cose, la capacità dei processi di accedere o eseguire altre operazioni sugli oggetti di sistema (come file, directory, porte di rete, ecc.) con il minor permesso possibile, consentendo comunque modifiche successive a questo modello.

Un altro MAC popolare e ampiamente utilizzato è AppArmor, che oltre alle funzionalità fornite da SELinux, include una modalità di apprendimento che consente al sistema di “imparare "come si comporta un'applicazione specifica e per impostare limiti configurando i profili per un utilizzo sicuro dell'applicazione.

In CentOS 7, SELinux è incorporato nel kernel stesso ed è abilitato in modalità Enforcing per impostazione predefinita (maggiori informazioni su questo nella sezione successiva), al contrario di openSUSE e Ubuntu che utilizzano AppArmor.

In questo articolo spiegheremo gli elementi essenziali di SELinux e AppArmor e come utilizzare uno di questi strumenti a tuo vantaggio in base alla distribuzione scelta.

Introduzione a SELinux e come usarlo su CentOS 7

Security Enhanced Linux può funzionare in due modi diversi:

1. Applicazione: SELinux nega l'accesso in base alle regole della policy SELinux, una serie di linee guida che controllano il motore di sicurezza.
2. Permissivo: SELinux non nega l'accesso, ma vengono registrati i rifiuti per azioni che sarebbero state negate se eseguite in modalità di applicazione.

SELinux può anche essere disabilitato. Sebbene non sia una modalità operativa in sé, è comunque un'opzione. Tuttavia, imparare a utilizzare questo strumento è meglio che semplicemente ignorarlo. Tienilo a mente!

Per visualizzare la modalità corrente di SELinux, utilizzare getenforce. Se desideri attivare/disattivare la modalità operativa, utilizza setenforce 0 (per impostarlo su Permissivo) o setenforce 1 (Applicazione forte>).

Poiché questa modifica non sopravviverà al riavvio, sarà necessario modificare il file /etc/selinux/config e impostare la variabile SELINUX su enforcing, permissive o disabled per ottenere la persistenza tra i riavvii:

Nota a margine, se getenforce restituisce Disabled, dovrai modificare /etc/selinux/config con la modalità operativa desiderata e riavviare. Altrimenti, non sarai in grado di impostare (o attivare/disattivare) la modalità operativa con setenforce.

Uno degli usi tipici di setenforce consiste nel passare da una modalità SELinux all'altra (da enforcing a permissive o viceversa) per risolvere i problemi di un'applicazione che si comporta male o non funziona come previsto. Se funziona dopo aver impostato SELinux sulla modalità Permissiva, puoi essere sicuro che stai riscontrando un problema di autorizzazioni di SELinux.

Due casi classici in cui molto probabilmente avremo a che fare con SELinux sono:

1. Modifica della porta predefinita su cui è in ascolto un demone.
2. Impostazione della direttiva DocumentRoot per un host virtuale esterno a /var/www/html.

Diamo un’occhiata a questi due casi utilizzando i seguenti esempi.

ESEMPIO 1: Modifica della porta predefinita per il demone sshd

Una delle prime cose che la maggior parte degli amministratori di sistema fa per proteggere i propri server è cambiare la porta su cui è in ascolto il demone SSH, principalmente per scoraggiare port scanner e aggressori esterni. Per fare ciò, utilizziamo la direttiva Port in /etc/ssh/sshd_config seguita dal nuovo numero di porta come segue (in questo caso utilizzeremo la porta 9999):

Port 9999

Dopo aver tentato di riavviare il servizio e averne verificato lo stato, vedremo che non è riuscito ad avviarsi:

systemctl restart sshd
systemctl status sshd

Se diamo un'occhiata a /var/log/audit/audit.log, vedremo che a sshd è stato impedito l'avvio sulla porta 9999 da SELinux perché è una porta riservata per il servizio JBoss Management (i messaggi di registro di SELinux includono la parola "AVC" in modo che possano essere facilmente identificato da altri messaggi):

cat /var/log/audit/audit.log | grep AVC | tail -1

A questo punto la maggior parte delle persone probabilmente disabiliterebbe SELinux ma noi non lo faremo. Vedremo che esiste un modo per SELinux e sshd in ascolto su una porta diversa, per vivere insieme in armonia. Assicurati di avere il pacchetto policycoreutils-python installato ed esegui:

yum install policycoreutils-python

Per visualizzare un elenco delle porte su cui SELinux consente l'ascolto di sshd. Nell'immagine seguente possiamo anche vedere che la porta 9999 era riservata per un altro servizio e quindi per il momento non possiamo utilizzarla per eseguire un altro servizio:

semanage port -l | grep ssh

Ovviamente potremmo scegliere un'altra porta per SSH, ma se siamo certi che non avremo bisogno di utilizzare questa macchina specifica per eventuali servizi relativi a JBoss, possiamo modificare la regola SELinux esistente e assegnare invece quella porta a SSH:

semanage port -m -t ssh_port_t -p tcp 9999

Successivamente, possiamo utilizzare il primo comando semanage per verificare se la porta è stata assegnata correttamente, oppure le opzioni -lC (abbreviazione di list custom):

semanage port -lC
semanage port -l | grep ssh

Ora possiamo riavviare SSH e connetterci al servizio utilizzando la porta 9999. Tieni presente che questa modifica sopravviverà al riavvio.

ESEMPIO 2: Scelta di una DocumentRoot esterna a /var/www/html per un host virtuale

Se devi configurare un host virtuale Apache utilizzando una directory diversa da /var/www/html come DocumentRoot (ad esempio, /websrv/sites /gabriele/public_html):

DocumentRoot “/websrv/sites/gabriel/public_html”

Apache si rifiuterà di fornire il contenuto perché index.html è stato etichettato con il tipo default_t SELinux, a cui Apache non può accedere:

wget http://localhost/index.html
ls -lZ /websrv/sites/gabriel/public_html/index.html

Come nell'esempio precedente, puoi utilizzare il comando seguente per verificare che si tratti effettivamente di un problema relativo a SELinux:

cat /var/log/audit/audit.log | grep AVC | tail -1

Per modificare ricorsivamente l'etichetta di /websrv/sites/gabriel/public_html in httpd_sys_content_t, esegui:

semanage fcontext -a -t httpd_sys_content_t "/websrv/sites/gabriel/public_html(/.*)?"

Il comando precedente garantirà ad Apache l'accesso in sola lettura a quella directory e ai suoi contenuti.

Infine, per applicare la policy (e rendere immediatamente effettiva la modifica dell'etichetta), procedi nel seguente modo:

restorecon -R -v /websrv/sites/gabriel/public_html

Ora dovresti essere in grado di accedere alla directory:

wget http://localhost/index.html

Per ulteriori informazioni su SELinux, fare riferimento alla guida Fedora 22 SELinux e Administrator.