Durante questa serie abbiamo esplorato in dettaglio almeno due metodi di controllo degli accessi: le autorizzazioni standard ugo/rwx (Gestione Utenti e Gruppi – Parte 3) e le liste di controllo degli accessi (Configurare ACL sui File System – Parte 7).
Sebbene necessari come permessi di primo livello e meccanismi di controllo degli accessi, presentano alcune limitazioni che vengono affrontate da Security Enhanced Linux (detto anche SELinux per brevità).
Una di tali limitazioni è che un utente può esporre un file o una directory a una violazione della sicurezza attraverso un comando chmod poco elaborato e causare così una propagazione inaspettata dei diritti di accesso. Di conseguenza, qualsiasi processo avviato da quell’utente può fare ciò che vuole con i file di proprietà dell’utente, dove infine un software malintenzionato o altrimenti compromesso può ottenere l’accesso a livello di root all’intero sistema.
Tenendo presenti tali limitazioni, l’United States National Security Agency (NSA) ha ideato per prima Security Enhanced Linux (SELinux), un metodo flessibile di controllo degli accessi obbligatorio, per limitare la capacità dei processi di accedere o eseguire altre operazioni sugli oggetti di sistema (come file, directory, porte di rete, ecc) al modello di permessi minimi, che può essere modificato successivamente secondo necessità. In poche parole, ogni elemento del sistema riceve solo l’accesso necessario per funzionare.
In RHEL 7, SELinux è incorporato nel kernel stesso ed è abilitato in modalità Enforcing per impostazione predefinita. In questo articolo spiegheremo brevemente i concetti di base associati a SELinux e al suo funzionamento.
Modalità SELinux
SELinux può operare in tre modi diversi:
- Enforcing: SELinux nega l’accesso in base alle regole della policy SELinux, un insieme di linee guida che controllano il motore di sicurezza.
- Permissive: SELinux non nega l’accesso, ma i rifiuti vengono registrati per le azioni che sarebbero state negate se in esecuzione in modalità enforcing.
- Disabled (autoesplicativo).
Il comando getenforce visualizza la modalità corrente di SELinux, mentre setenforce (seguito da un 1 o un 0) viene utilizzato per cambiare la modalità in Enforcing o Permissive, rispettivamente, solo durante la sessione corrente.
Per ottenere la persistenza tra le disconnessioni e i riavvii, è necessario modificare il file /etc/selinux/config e impostare la variabile SELINUX su enforcing, permissive, o disabled:
# getenforce # setenforce 0 # getenforce # setenforce 1 # getenforce # cat /etc/selinux/config
In genere si utilizza setenforce per passare tra le modalità SELinux (da enforcing a permissive e viceversa) come primo passo di risoluzione dei problemi. Se SELinux è attualmente impostato su enforcing mentre si verifica un certo problema, e lo stesso problema scompare quando lo si imposta su permissive, si può essere certi di avere a che fare con un problema di autorizzazioni SELinux.
Contesti SELinux
A SELinux context consists of an access control environment where decisions are made based on SELinux user, role, and type (and optionally a level):
- A SELinux user complements a regular Linux user account by mapping it to a SELinux user account, which in turn is used in the SELinux context for processes in that session, in order to explicitly define their allowed roles and levels.
- Il concetto di ruolo funge da intermediario tra i domini e gli utenti SELinux nel definire quali domini di processo e tipi di file possono essere accessibili. Questo proteggerà il tuo sistema da vulnerabilità agli attacchi di escalation dei privilegi.
- A type defines an SELinux file type or an SELinux process domain. Under normal circumstances, processes are prevented from accessing files that other processes use, and and from accessing other processes, thus access is only allowed if a specific SELinux policy rule exists that allows it.
Vediamo come tutto ciò funziona attraverso gli esempi seguenti.
ESEMPIO 1: Cambiare la porta predefinita per il demone sshd
In Sicurezza SSH – Parte 8 abbiamo spiegato che cambiare la porta predefinita su cui sshd è in ascolto è una delle prime misure di sicurezza per proteggere il tuo server dagli attacchi esterni. Modifichiamo il file /etc/ssh/sshd_config e impostiamo la porta su 9999:
Port 9999
Salva le modifiche e riavvia sshd:
# systemctl restart sshd # systemctl status sshd
Come puoi vedere, sshd non è riuscito a partire. Ma cosa è successo?
A quick inspection of /var/log/audit/audit.log indicates that sshd has been denied permissions to start on port 9999 (SELinux log messages include the word “AVC” so that they might be easily identified from other messages) because that is a reserved port for the JBoss Management service:
# cat /var/log/audit/audit.log | grep AVC | tail -1
A questo punto potresti disabilitare SELinux (ma non farlo!) come spiegato in precedenza e provare a far partire di nuovo sshd, e dovrebbe funzionare. Tuttavia, l’utilità semanage può dirci cosa dobbiamo cambiare affinché siamo in grado di far partire sshd sulla porta che scegliamo senza problemi.
Esegui,
# semanage port -l | grep ssh
per ottenere un elenco delle porte su cui SELinux consente a sshd di essere in ascolto.
Quindi cambiamo la porta in /etc/ssh/sshd_config in Porta 9998, aggiungi la porta al contest ssh_port_t, e quindi riavvia il servizio:
# semanage port -a -t ssh_port_t -p tcp 9998 # systemctl restart sshd # systemctl is-active sshd
Come puoi vedere, il servizio è stato avviato con successo questa volta. Questo esempio illustra il fatto che SELinux controlla il numero di porta TCP alle sue definizioni interne di tipo di porta.
ESEMPIO 2: Consentire a httpd di inviare accesso a sendmail
Questo è un esempio di SELinux che gestisce un processo che accede a un altro processo. Se dovessi implementare mod_security e mod_evasive insieme ad Apache nel tuo server RHEL 7, devi consentire a httpd di accedere a sendmail per inviare una notifica via mail in seguito a un attacco (D)DoS. Nel comando seguente, ometti il flag -P se non vuoi che la modifica sia persistente attraverso i riavvii.
# semanage boolean -1 | grep httpd_can_sendmail # setsebool -P httpd_can_sendmail 1 # semanage boolean -1 | grep httpd_can_sendmail
Come puoi vedere dall’esempio sopra, le impostazioni booleani SELinux (o semplicemente booleani) sono regole vere / false incorporate nelle politiche SELinux. Puoi elencare tutti i booleani con semanage boolean -l, e alternativamente mandarlo in output a grep per filtrare l’output.
ESEMPIO 3: Servire un sito statico da una directory diversa da quella predefinita
Supponiamo che tu stia servendo un sito web statico utilizzando una directory diversa da quella predefinita (/var/www/html), diciamo /sitiweb (questo potrebbe essere il caso se stai memorizzando i tuoi file web in un’unità di rete condivisa, ad esempio, e devi montarla in /sitiweb).
a). Create an index.html file inside /websites with the following contents:
<html> <h2>SELinux test</h2> </html>
Se lo fai,
# ls -lZ /websites/index.html
Vedrai che il file index.html è stato contrassegnato con il tipo default_t SELinux, a cui Apache non può accedere:
b). Change the DocumentRoot directive in /etc/httpd/conf/httpd.conf to /websites and don’t forget to update the corresponding Directory block. Then, restart Apache.
c). Browse to http://<web server IP address>, and you should get a 503 Forbidden HTTP response.
d). Next, change the label of /websites, recursively, to the httpd_sys_content_t type in order to grant Apache read-only access to that directory and its contents:
# semanage fcontext -a -t httpd_sys_content_t "/websites(/.*)?"
e). Finally, apply the SELinux policy created in d):
# restorecon -R -v /websites
Ora riavvia Apache e vai su http://<indirizzo IP del server web> di nuovo e vedrai che il file html viene visualizzato correttamente:
Riepilogo
In questo articolo abbiamo esaminato i concetti di base di SELinux. Nota che a causa dell’ampiezza dell’argomento, non è possibile fornire una spiegazione dettagliata completa in un singolo articolo, ma crediamo che i principi delineati in questa guida ti aiuteranno a passare a argomenti più avanzati se lo desideri.
Se posso permettermi, lascia che ti consigli due risorse essenziali per iniziare: la pagina NSA SELinux e la guida Utente e Amministratore SELinux di RHEL 7.
Non esitare a farci sapere se hai domande o commenti.
Source:
https://www.tecmint.com/selinux-essentials-and-control-filesystem-access/