Linux: SELinux and rescuing a server that won't boot

The security audit comes down to two findings. On srv-portail, the server that gives customers the container tracking portal, SELinux has protected nothing since the contractor set it to permissive mode, "because the portal would not start with it". And nobody has ever tested a reboot: since last night's power cut, srv-archives, which keeps the customs declarations, no longer boots. You first read the state of SELinux, the contexts of processes and files, and the audit log, where permissive mode noted every denial without enforcing any. You switch to enforcing to see the portal go down, then rule out the three false fixes that bring the portal back by opening far more than the need: switching SELinux off, the boolean audit2why suggests, and the module audit2allow writes. The real fix comes down to two labels: port 8090 and the portal's folder, with semanage and restorecon. SELinux goes to enforcing mode, now and at boot, with no loss of service. AppArmor, the module on Debian and Ubuntu, is placed alongside. Then the second server: in emergency mode, root locked, no way in. You read its console, find the failing mount, stop the server, check its disk, mount it from the outside as from a rescue instance, fix the typo in its fstab and test it with a test mount. Finally the proof: you find out why the server, although "enabled", did not restart on its own, and you really reboot the machine. A written report closes the audit. The last lab of the path: it covers the last two chapters of LFS207, Linux security modules and system rescue.