Linux : SELinux et dépannage d'un serveur qui ne démarre plus

L'audit de sécurité tient en deux constats. Sur srv-portail, le serveur qui sert aux clients le portail de suivi des conteneurs, SELinux ne protège plus rien depuis que le prestataire l'a mis en mode permissif, « parce que le portail ne démarrait pas avec ». Et personne n'a jamais testé un redémarrage : depuis la coupure de courant de cette nuit, srv-archives, qui garde les déclarations en douane, ne démarre plus. Vous lisez d'abord l'état de SELinux, les contextes des processus et des fichiers, et le journal d'audit, où le mode permissif a noté chaque refus sans en appliquer aucun. Vous passez en mode contraint pour voir le portail tomber, puis vous écartez les trois fausses corrections qui font repartir le portail en ouvrant bien plus que le besoin : couper SELinux, le booléen que propose audit2why, et le module qu'écrit audit2allow. La vraie correction tient en deux étiquettes : le port 8090 et le dossier du portail, par semanage et restorecon. SELinux passe en mode contraint, maintenant et au démarrage, sans perte de service. AppArmor, le module de Debian et d'Ubuntu, est situé en regard. Puis le second serveur : en mode d'urgence, root verrouillé, impossible d'y entrer. Vous lisez sa console, trouvez le montage qui échoue, arrêtez le serveur, vérifiez son disque, le montez depuis l'extérieur comme depuis une instance de secours, corrigez la faute de frappe de son fstab et la testez par un montage d'essai. Enfin la preuve : vous découvrez pourquoi le serveur, pourtant « activé », ne redémarrait pas seul, et vous redémarrez la machine pour de vrai. Un compte rendu écrit clôt l'audit. Dernier lab du parcours : il couvre les deux derniers chapitres de LFS207, les modules de sécurité Linux et le secours d'un système.