After Harden GRUB bootloader using bootloader password has been implemented…
Should disable dracut recovery console?
Should set kernel parameters:
rd.shell=0 rd.emergency=halt
As per fedora - How can I secure the dracut shell? - Server Fault?
2 Likes
We should make sure this doesn’t break Recovery Mode, that’s the only thing wrong I can think of with that.
1 Like
Not to be confused:
- A) dracut recovery shell [This topic]
- B) Linux recovery mode (Single-User Mode) [somewhat related, but not the same]
This topic overlaps very much with Harden GRUB bootloader using bootloader password.
If protecting all GRUB bootloader boot menu entries, is there still a point in disabling dracut recovery shell?
Specifically, since there is a Linux recovery mode boot menu entry anyhow.
A theoretic argument could be made “if an attacker can bypass GRUB passwords”, but these minor Protection against Physical Attacks measures help against weak adversaries. An advanced adversary that could in theory bypass the bootloader password, would probably bother with neither GRUB passwords, dracut recovery shell nor Linux recovery mode but instead use Malicious Hardware Modifications, Side Channel Attacks or similar.
related:
Right, that’s what I thought. Then yeah, I think this change would make sense.
I guess it depends. Theoretically an attacker could try to gain a root shell on a system by fooling some privileged component of the system into damaging boot files, then reboot and have a root shell. That would let them turn a data corruption vulnerability into a privilege escalation one. Blocking the Dracut recovery shell prevents that - the attacker can use the data corruption vuln to render the system unbootable, but can’t use that to then gain root access. If the system under attack was a physical system, this wouldn’t be that important to defend against since the user is probably using FDE which would prevent this sort of attack too, but if the system under attack if an unencrypted VM hosted on a server, then this would be a reasonable attack to fear and I can see this being a good mitigation for it.
1 Like
Right. So similar to Harden GRUB bootloader using bootloader password - #6 by Patrick there could be a corporate setup use case.
A malicious employee could manage to corrupt some system files to then get a dracut recovery shell.
Or the complex VM related attack you’ve described.
We could set rd.shell=0 rd.emergency=halt in security-misc. (And then undo the setting in debug-misc, if not already the case.)
But we would only set it for GRUB_CMDLINE_LINUX_DEFAULT (default boot entry) or GRUB_CMDLINE_LINUX (all boot entries, including recovery boot entry)?
The kernel parameters rd.shell=0 rd.emergency=halt can be modified or unset from GRUB boot menu. But those who worry about that, can either set a BIOS password and/or a bootloader password, depending on their threat model.
Setting it for default (non-recovery) boot menu entries might makes sense. Because those who want to protect Linux recovery mode boot entries, need to set a GRUB root password anyhow.
Another related solution: Remove Linux recovery mode boot option from default GRUB boot menu
1 Like
Actually i would argue against that, why do we need to rely on recovery mode?
I think of recovery mode ability is like backdooring your own OS, what we need to do is that change the mentality of how user reacting with OS:
Since we are moving towards btrfs/snapshot feature this will reduce the reliability on recovery mode.
Other thing is that think about a mobile phone got whatever issue to the boot of the OS, yes it has recovery mode but very unlikely users gonna figure out how to use it let alone if its even possible to have any usefulness when entering recovery mode as it will just allow you to reinstall the OS…
So how to solve this? another mental change to the user that he should always backup his own data to his own hardware and that can be his own flash/hard drive, or internal clould (NAS/Nexcloud…etc) or even external server… something he choose but the OS will not backdoor itself for recovery mode.
Note: booting into recovery mode is a malicious boot up of the system, because it will be booting with minimalistic services meaning will disable almost all security features that user needs, other word its just the wrong method in nowadays time.
For Linux recovery mode we have ticket Remove Linux recovery mode boot option from default GRUB boot menu.