SELinux ripristina la password di root

Disclaimer: questa domanda non è quella di risolvere il problema di cambiare la password di root mentre SELinux è attivo perché ci sono molte guide per risolverlo già. Questo è più di come SELinux lo fa internamente.

Sono un recente utente di SELinux ma ultimamente sono stato più in contatto con esso. C'è stato un momento in cui qualcuno mi ha chiesto come posso ripristinare la password di root in caso di dimenticarla.

Così ho avviato il mio CentOS, modificato la voce grub in qualcosa del genere

linux16 <kernel_location> root=/dev/mapper/centos-root rw init=/bin/bash

Ho corso passwde in seguito ho eseguito e syncriavviato forzatamente. Dopo il riavvio, l'accesso con la nuova password è stato rifiutato e ovviamente con quello precedente.

Riavviato di nuovo e passato al kernel il parametro per disabilitare SELinux ( selinux=0). Ho provato ad accedere con la nuova password e ha funzionato. Successivamente ho forzato una rietichettatura automatica fs (tramite il file .autorelabel) e con SELinux attivo era ora possibile accedere.

La mia domanda è: perché succede? Perché la rietichettatura influisce sul login quando si verificava semplicemente un cambio di password e non di utenti o oggetti?

Grazie per l'attenzione.

TL; DR: il normale ripristino della password di root non funziona in SELinux. Perché?

Modifica: questo è stato testato su una macchina virtuale che esegue CentOS7 con KVM come hypervisor.

— Jorge Heleno
fonte

Sei sicuro che non funzioni? Ritenta. Probabilmente funzionerà bene. Ho il sospetto che tu abbia semplicemente avuto contesti di file sbagliati su alcuni file, causando il fallimento di tutti gli accessi. Pertanto, l'autoregel era ciò che risolveva davvero il problema.

— Michael Hampton

@MichaelHampton Ho appena ripercorso tutti i miei passi facendolo di nuovo e non sono riuscito ad accedere di nuovo con SELinux attivo. Dopo averlo disabilitato ho potuto accedere senza problemi. Correggimi se sbaglio ma cambiare una password non dovrebbe cambiare il contesto dei file, giusto?

— Jorge Heleno,

No non dovrebbe. Sembra che tu abbia scoperto qualcosa di strano e inaspettato.

— Michael Hampton

Sono stato in grado di duplicare questo problema in un sistema CentOS 7.5 appena installato.

Ecco cosa sta succedendo:

Quando fai il boot con init=/bin/bashci sono due problemi che potresti incontrare:

Il filesystem di root può essere montato in sola lettura. In questo caso passwdsi lamenterà di un Authentication token manipulation error.

Questo è abbastanza ovvio: se il filesystem non è montato in lettura-scrittura, non è possibile scriverlo.
La politica SELinux potrebbe non essere caricata. In questo caso passwdcambierà correttamente la password, ma avrai il problema descritto nella domanda originale sopra: nessuno sarà in grado di accedere.

Gli hash delle password sono memorizzati nel /etc/shadowfile. Questo file normalmente ha il tipo SELinux shadow_t. Tuttavia, modificando il file mentre non è caricata alcuna politica SELinux, il tipo SELinux viene rimosso dal file, lasciandolo così unlabeled_t. Pertanto, i servizi che tentano di leggere il file per autenticare gli accessi non sono più in grado di leggerlo.

Per modificare la password di root su RHEL / CentOS 7, è quindi necessario seguire questo processo:

Aggiungi init=/bin/bashalla fine della riga di comando del kernel in grub, come hai fatto in precedenza.
Al prompt di bash, caricare la politica SELinux con /usr/sbin/load_policy -i.
Montare il filesystem di root in lettura-scrittura con mount -o remount,rw /.
Ora cambia la password e ci riuscirà. passwd root
Rimontare nuovamente il file system per eseguire il commit delle modifiche e disporre di un file system pulito al successivo avvio con mount -o remount,ro /.
Esci dalla shell o riavvia il sistema con exec /sbin/init 6.

Ora puoi accedere con la password di root modificata.

Una spiegazione più lunga di questa procedura è disponibile presso Red Hat (è richiesto un abbonamento).

— Michael Hampton
fonte

Il problema riguardava le politiche che non erano state caricate. Perché non vengono caricati? SELinux dovrebbe funzionare a livello di kernel, quindi il sistema init non dovrebbe essere richiesto.

— Jorge Heleno,

@JorgeHeleno SELinux è effettivamente attivato o disattivato di default all'avvio del kernel, ma l'utente è responsabile di decidere quali criteri vengono caricati. Il kernel non ha potuto decidere questo, perché alcune installazioni potrebbero desiderare politiche diverse (ad esempio, mirate, rigorose, mls). Questo accade all'inizio del processo di avvio, ma lo ignori quando esegui init=/bin/bash.

— Michael Hampton

se una politica non viene caricata, perché passwd"sembra avere successo"?

— Andrew Savinykh,

e se non è riuscito, perché l'accesso con la vecchia password non riesce ancora?

— Razze di leggerezza in orbita,

@Jorge Helen: la tua spiegazione è quasi completa. Il punto sono i file modificati da passwdie /etc/passwde /etc/shadow. Se eseguito passwdsenza criteri caricati, non viene eseguito nel contesto selinux appropriato e i file modificati finiscono con un contesto selinux diverso. Quando si avvia con selinux abilitato e le politiche attive il controllo della password fallisce a causa di un contesto di file inappropriato e non a causa di un wrong passworderrore. Forzare selinux a relazionare i filecontex toccando /.autorelabelpuò anche risolvere quel problema quando si cambiano le password senza criteri caricati.

— Hargut,