Configura SELinux per consentire ai demoni di utilizzare i file in posizioni non predefinite

Sfondo

SELinux aggiunge un altro livello di controllo dei permessi sui sistemi Linux. Sui sistemi abilitati per SELinux vengono controllate prima le normali autorizzazioni DAC e, se consentono l'accesso, la policy di SELinux viene consultato. Se la politica di SELinux nega l'accesso, viene generata una voce di registro nel registro di controllo in /var/log/audit/audit.log o in dmesg se auditd non è in esecuzione sul sistema.

SELinux assegna un'etichetta, chiamata contesto di sicurezza , a ogni oggetto (file, processo, ecc.) nel sistema:

• File avere un contesto di sicurezza memorizzato in attributi estesi. Questi possono essere visualizzati con ls -Z .

  SELinux mantiene un database che mappa i modelli di percorsi ai contesti di file predefiniti. Questo database viene utilizzato quando è necessario ripristinare manualmente i contesti file predefiniti o quando il sistema viene rietichettato. Questo database può essere interrogato con semanage strumento.

• Processi viene assegnato un contesto di sicurezza quando viene eseguito un eseguibile (execve chiamata di sistema). I contesti di sicurezza dei processi possono essere visualizzati con la maggior parte degli strumenti di monitoraggio del sistema, ad esempio con ps Z $PID .

• Esistono anche altri oggetti etichettati, ma non sono rilevanti per questa risposta.

politica di SELinux contiene le regole che specificano quali operazioni tra contesti sono consentite. SELinux opera su lista bianca regole, tutto ciò che non è esplicitamente consentito dalla policy viene negato. La policy di riferimento contiene moduli di policy per molte applicazioni e di solito è la policy utilizzata dalle distribuzioni abilitate per SELinux. Questa risposta descrive principalmente come lavorare con una policy basata sulla policy di riferimento, che molto probabilmente stai utilizzando se utilizzi la policy fornita dalla distribuzione.

Quando esegui la tua applicazione come utente normale, probabilmente non ti accorgi di SELinux, perché la configurazione predefinita pone gli utenti in unconfined contesto. Processi in esecuzione in unconfined contesto hanno pochissime restrizioni in atto. Potresti essere in grado di eseguire il tuo programma senza problemi nella shell utente in un contesto non limitato, ma quando viene avviato utilizzando il sistema init potrebbe non funzionare più in un contesto limitato.

Problemi tipici

Quando i file si trovano in una posizione non predefinita (non descritta nella politica predefinita) i problemi sono spesso correlati ai seguenti motivi:

• I file hanno un contesto di file errato/incompatibile :File spostati con mv mantenere i propri metadati, inclusi i contesti di sicurezza dei file, dalla vecchia posizione. I file creati nella nuova posizione hanno ereditato il contesto dalla directory principale o dal processo di creazione.

• Avere più demoni che utilizzano gli stessi file :La policy di default non include regole per consentire l'interazione tra i contesti di sicurezza in questione.

File con contesto di sicurezza errato

Se i file non sono utilizzati da un altro demone (o altro processo confinato) e l'unica modifica è la posizione in cui sono archiviati i file, le modifiche richieste alla configurazione di SELinux sono:

• Aggiungi una nuova regola al database del contesto dei file
• Applica il contesto file corretto ai file esistenti

Il contesto del file nella posizione predefinita può essere utilizzato come modello per la nuova posizione. La maggior parte dei moduli di policy include la documentazione della pagina man (generata utilizzando sepolicy manpages ) che spiega possibili contesti di file alternativi con la loro semantica di accesso.

Il database del contesto dei file utilizza la sintassi delle espressioni regolari, che consente di scrivere specifiche sovrapposte. Vale la pena notare che il contesto applicato è l'ultima specifica trovata.

Per aggiungere una nuova voce al database del contesto file:

semanage fcontext -a -t <type> "/path/here/(/.*)?"

Dopo che la nuova voce di contesto è stata aggiunta al database, il contesto del database può essere applicato ai tuoi file usando restorecon <files> . Esecuzione di restorecon con -vn i flag mostreranno quali contesti di file verrebbero modificati senza applicare alcuna modifica.

Testare un nuovo contesto di file senza aggiungere una nuova voce nel database

Il contesto può essere modificato manualmente con chcon attrezzo. Questo è utile quando vuoi testare il nuovo contesto del file senza aggiungere una voce al database del contesto del file.

Il nuovo contesto del file è specificato negli argomenti di chcon . Quando utilizzato con --reference= opzione, il contesto di sicurezza da un file di riferimento viene copiato nei file di destinazione.

utilizzando un contesto specifico (default_t ):

chcon -t default_t <target files>

o utilizzando un riferimento:

chcon --reference=<path to default location> <target files>

Nota sui diversi file system e punti di montaggio

Se la nuova posizione è il proprio punto di montaggio, il contesto può essere impostato con un'opzione di montaggio. Il contesto impostato con l'opzione di montaggio non viene archiviato su disco, quindi può essere utilizzato anche con file system che non supportano gli attributi estesi.

mount <device> <mount point> -o context="<context>"

Consentire ai processi in esecuzione in diversi contesti di sicurezza di utilizzare gli stessi file

Opzione 1:booleani

La policy di riferimento include opzioni sintonizzabili, chiamate booleans , che abilitano/disabilitano determinate regole aggiuntive. Molti di essi consentono l'interazione di diversi demoni di sistema che di solito non usano gli stessi file.

L'elenco di tutte le possibili opzioni sintonizzabili e le relative descrizioni possono essere elencate utilizzando semanage boolean -l . audit2allow potrebbe anche essere in grado di dire direttamente quale valore booleano deve essere abilitato.

Per abilitare/disabilitare un valore booleano usando semanage :

semanage boolean --on <boolean name>
semanage boolean --off <boolean name>

I booleani sono il modo più semplice per modificare la politica. Tuttavia, tutte le possibili situazioni non possono essere affrontate attivando un valore booleano. Alcuni booleani consentono anche un accesso molto ampio, essendo eccessivamente permissivi.

Opzione 2:estendi la policy con un nuovo modulo

Se non esiste alcun valore booleano per consentire l'accesso, la politica deve essere modificata aggiungendo un modulo personalizzato.

Un semplice modulo che aggiunge le regole richieste per consentire l'accesso può essere generato dai file di log usando audit2allow con i seguenti passaggi:

1. Imposta il dominio del demone (contesto di sicurezza) alla modalità permissiva . In modalità permissiva il criterio non viene applicato , ma i log vengono generati sull'accesso normalmente negato dal criterio.

   semanage permissive -a <domain>
   

2. Prova il tuo demone durante il normale funzionamento per generare voci di registro.

3. Crea un nuovo modulo di criteri e inseriscilo.

   audit2allow -a -M <name>
   semodule -i <name>.pp'
   

4. Riattiva la modalità di applicazione

   semanage permissive -d <domain>
   

Questo metodo funziona meglio quando sono coinvolti solo pochi contesti di sicurezza. In una configurazione complessa è molto probabile che tu debba scrivere il tuo modulo di policy. Alcune risorse per iniziare sono il wiki di gentoo e la documentazione dell'API delle policy di riferimento.

Con questo comando:

# semanage fcontext -l /oldpath/

Puoi controllare i contesti SElinux predefiniti nelle cartelle del tuo sistema, quindi con quel comando puoi vedere il contesto predefinito di quella cartella del demone.

Quindi puoi controllare qualsiasi contesto SELinux che dovresti configurare nella directory in cui vuoi spostare il tuo contenuto.

Diciamo che vedi che la tua cartella daemon ha questo contesto (è il contesto di apache):

# semanage fcontext -l
...
/var/www(/.*)? all files system_u:object_r:httpd_sys_content_t:s0

Quindi applicherai questi contesti al nuovo percorso in questo modo (esempio con apache daemon contesto di sicurezza predefinito)

# semanage fcontext -a -t httpd_sys_content_t '/newpath(/.*)?'

Dopo averlo fatto, considerando che il tuo contenuto è già nel nuovo percorso, dovresti forzare tutto sotto quel percorso, per ottenere quel contesto:

# restorecon -RFvv /newpath

Puoi verificare se ha funzionato, con questo comando:

# ls -Zd /newpath/

Ricorda che quando esegui il mv di una directory o di file, mantiene il contesto di sicurezza Quando esegui il cp di una cartella o di una directory, imposterà il contesto su quello del genitore.

Se hai bisogno di controllare le pagine man per software specifico, puoi installare le pagine man con:

# yum install -y selinux-policy-devel

Non dimenticare di eseguire questo comando per reindicizzare man db:

# mandb

Quindi puoi eseguire questo e controllare tutte le pagine man di selinux.

# man -k selinux

Suggerimento, esegui questo comando prima e dopo l'installazione del pacchetto, per vedere la differenza:

# man -k selinux | wc -l