SELinux réinitialiser le mot de passe root

Avertissement: Cette question n'est pas de résoudre le problème du changement de mot de passe root lorsque SELinux est actif car il existe déjà de nombreux guides pour le résoudre. C'est davantage la façon dont SELinux le fait en interne.

Je suis un utilisateur récent de SELinux, mais dernièrement, j'ai été plus en contact avec lui. Il y a eu un moment où quelqu'un m'a demandé comment réinitialiser le mot de passe root en cas d'oubli.

J'ai donc démarré mon CentOS, modifié l'entrée grub vers quelque chose comme

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

J'ai couru passwdet ensuite couru syncet forcé le redémarrage. Après le redémarrage, la connexion avec le nouveau mot de passe a été rejetée ainsi qu'avec l'ancien bien sûr.

Redémarré à nouveau et passé le noyau le paramètre pour désactiver SELinux ( selinux=0). J'ai essayé de me connecter avec le nouveau mot de passe et cela a fonctionné. Ensuite, j'ai forcé un ré-étiquetage automatique fs (via le fichier .autorelabel) et avec SELinux actif, il était maintenant possible de se connecter.

Ma question est: pourquoi cela arrive-t-il? Pourquoi le réétiquetage affecte-t-il la connexion lorsqu'il y a simplement eu un changement de mot de passe et non d'utilisateurs ou d'objets?

Merci pour votre attention.

TL; DR: la réinitialisation habituelle du mot de passe root ne fonctionne pas dans SELinux. Pourquoi?

Edit: Cela a été testé sur une machine virtuelle exécutant CentOS7 avec KVM comme hyperviseur.

— Jorge Heleno
source

Êtes-vous sûr que cela ne fonctionne pas? Essayez à nouveau. Cela fonctionnera probablement très bien. Je soupçonne que vous avez simplement eu des contextes de fichiers incorrects sur certains fichiers, provoquant l'échec de toutes les connexions. Ainsi, l'auto-étiquetage a vraiment résolu le problème.

— Michael Hampton

@MichaelHampton Je viens de retracer toutes mes étapes en recommençant et je n'ai pas pu me reconnecter avec SELinux actif. Après l'avoir désactivé, je pouvais me connecter sans problème. Corrigez-moi si je me trompe, mais changer un mot de passe ne devrait pas changer les contextes de fichiers, n'est-ce pas?

— Jorge Heleno

Non, ça ne devrait pas. Vous semblez avoir découvert quelque chose d'étrange et d'inattendu.

— Michael Hampton

J'ai pu dupliquer ce problème dans un système CentOS 7.5 fraîchement installé.

Voici ce qui se passe:

Lorsque vous démarrez avec init=/bin/bash, vous pouvez rencontrer deux problèmes:

Le système de fichiers racine peut être monté en lecture seule. Dans ce cas, passwdse plaindra d'un Authentication token manipulation error.

C'est assez évident: si le système de fichiers n'est pas monté en lecture-écriture, il n'est pas possible d'y écrire.
La politique SELinux peut ne pas être chargée. Dans ce cas passwd, le mot de passe sera modifié avec succès, mais vous aurez le problème décrit dans la question d'origine ci-dessus: personne ne pourra se connecter.

Les hachages de mot de passe sont stockés dans le /etc/shadowfichier. Ce fichier a normalement le type SELinux shadow_t. Cependant, la modification du fichier alors qu'aucune stratégie SELinux n'est chargée entraîne la suppression du type SELinux du fichier, le laissant ainsi unlabeled_t. Ainsi, les services qui tentent de lire le fichier pour authentifier les connexions ne peuvent plus le lire.

Pour changer le mot de passe root sur RHEL / CentOS 7, vous devez donc suivre ce processus:

Ajoutez init=/bin/bashà la fin de la ligne de commande du noyau dans grub, comme vous l'avez fait précédemment.
À l'invite bash, chargez la stratégie SELinux avec /usr/sbin/load_policy -i.
Montez le système de fichiers racine en lecture-écriture avec mount -o remount,rw /.
Maintenant, changez le mot de passe et il réussira. passwd root
Remontez le système de fichiers en lecture seule pour valider les modifications et avoir un système de fichiers propre au prochain démarrage avec mount -o remount,ro /.
Quittez le shell ou redémarrez le système avec exec /sbin/init 6.

Vous pouvez maintenant vous connecter avec le mot de passe root modifié.

Une explication plus longue de cette procédure est disponible auprès de Red Hat (abonnement requis).

— Michael Hampton
source

Le problème était sur les politiques qui n'étaient pas chargées. Pourquoi ne sont-ils pas chargés? SELinux devrait fonctionner au niveau du noyau, donc le système init ne devrait pas être requis.

— Jorge Heleno du

@JorgeHeleno SELinux est en effet activé ou désactivé par défaut au démarrage du noyau, mais l'espace utilisateur est responsable de décider quelles politiques sont chargées. Le noyau n'a pas pu décider cela, car certaines installations peuvent vouloir des politiques différentes (par exemple ciblées, strictes, mls). Cela se produit au début du processus de démarrage, mais vous contournez cela lorsque vous exécutez init=/bin/bash.

— Michael Hampton

si une politique n'est pas chargée pourquoi le passwd"semble réussir"?

— Andrew Savinykh

et s'il n'a pas réussi, pourquoi la connexion avec l'ancien mot de passe a-t-elle échoué?

— Courses de légèreté en orbite

@Jorge Helen: Votre explication est presque terminée. Le point est les fichiers modifiés par passwdsavoir /etc/passwdet /etc/shadow. S'il s'exécute passwdsans stratégie chargée, il ne s'exécute pas dans le contexte selinux approprié et les fichiers modifiés se retrouvent avec un contexte selinux différent. Lors du démarrage avec selinux activé et les stratégies actives, la vérification du mot de passe échoue en raison d'un contexte de fichier inapproprié et non en raison d'une wrong passworderreur. Forcer selinux à utiliser des contextes de fichiers fiables en touchant /.autorelabelpeut également résoudre ce problème lors du changement de mots de passe sans politique chargée.

— hargut