Root in un terminale, negato sotto SELinux: perché l’hook fallisce

Eseguite lo script up come root, termina, e lo stesso script fallisce quando il servizio lo richiama. Nulla è cambiato nei permessi del file, quindi il passo naturale successivo è allentarli di nuovo, cosa che non risolve niente. Su un host SELinux il fattore decisivo spesso non è chi sia il processo, ma in quale dominio venga eseguito, e root all’interno di un dominio confinato resta confinato.

Lo stesso comando, due domini di sicurezza diversi

L’applicazione dei tipi valuta insieme il dominio di origine, l’etichetta di destinazione e l’operazione richiesta. La vostra sessione di terminale viene eseguita in un dominio non confinato o amministrativo, e il demone viene eseguito nel dominio assegnato alla sua unità. Comandi identici producono quindi decisioni diverse, e la differenza è intenzionale e non un difetto della politica.

Per questo confrontare le due esecuzioni è utile solo se confrontate i loro contesti. Eseguite lo stesso comando dalla shell e dall’hook, e la versione dalla shell dimostra che il binario esiste e che gli argomenti sono corretti; non dimostra nulla sul fatto che il servizio sia autorizzato a eseguirlo. Eseguitelo in entrambi i modi e confrontate i domini, non solo i codici di uscita. È questo confronto che trasforma una lamentela vaga sui permessi in una domanda precisa su un dominio e un’etichetta.

La forma classica di questo guasto è un helper che richiama uno strumento esterno. L’hook stesso può essere permesso, mentre lo strumento che invoca porta un’etichetta che il dominio del servizio non può eseguire, o scrive in una directory la cui etichetta lo vieta.

Leggete il record AVC accanto all’errore dell’hook

Un rifiuto AVC nomina i campi che decidono il caso: il contesto di origine del processo, il contesto di destinazione dell’oggetto, la classe dell’oggetto e l’autorizzazione specifica che è stata rifiutata. Leggete tutti e quattro prima di formulare una teoria, perché un rifiuto sull’esecuzione e un rifiuto sulla scrittura richiedono riparazioni completamente diverse.

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

Il contesto di origine dovrebbe corrispondere al dominio in cui il servizio viene effettivamente eseguito, e il contesto di destinazione all’etichetta del file o della directory toccati dall’operazione. Se uno dei due non coincide con l’errore che state inseguendo, state leggendo un altro evento.

Annotate la versione della politica e il percorso esatto dell’eseguibile accanto al record. Un nome di dominio che compare nella politica di una distribuzione è una prova su quell’installazione, non una garanzia che un’altra build fornisca le stesse regole. È questo contesto che consente a qualcun altro di riprodurre la vostra conclusione sul proprio host. Senza di esso, il record si legge come un aneddoto e non come una prova.

Etichetta, configurazione o politica: tre riparazioni

La prima riparazione è un’etichetta che non corrisponde alla posizione installata del file. Uno script copiato al suo posto con cp o scritto da un editor può portare un’etichetta predefinita che il dominio del servizio non può usare, e ripristinare il contesto atteso risolve senza toccare la politica.

La seconda è la configurazione. La distribuzione può offrire un modo supportato di eseguire l’operazione, una directory documentata per l’helper o un pacchetto di politica aggiornato che già la consente. Cambiare la vostra disposizione con quella supportata costa meno che scrivere una politica e sopravvive agli aggiornamenti.

La terza è una regola realmente assente, e dovrebbe essere l’ultima risorsa. Generate un candidato con gli strumenti di audit, leggete cosa consente davvero, restringetelo all’operazione e al dominio che avete osservato, e fate revisionare da qualcun altro prima che si avvicini alla produzione.

Perché un vecchio modulo allow non è la risposta

I risultati di ricerca per questo guasto sono pieni di moduli preconfezionati, spesso per uno strumento che l’hook non richiama più. Installarne uno concede autorizzazioni che possono non avere nulla a che fare con il vostro rifiuto, e lascia in piedi la vera discrepanza aggiungendo un buco permanente.

Nasconde anche il guasto successivo. Un modulo che consente un’ampia classe di operazioni farà sparire questo errore e trasformerà il successivo in qualcosa di molto più difficile da attribuire. Rimuovere il modulo in seguito è anche un cambiamento che nessuno vuole pianificare, quindi la scorciatoia tende a diventare permanente.

Il confronto disciplinato è tra il rifiuto che potete leggere e il cambiamento che proponete. La guida alla risoluzione dei problemi di SELinux di Red Hat mette i controlli di etichettatura e configurazione davanti alla politica generata proprio per questo motivo. Se nel record non c’è un rifiuto corrispondente, probabilmente SELinux non è il vostro problema, e i problemi di percorso, sandbox o autorizzazioni restano aperti.