I’m relatively new to openSUSE, so bear with me with my question. I’m currently exploring three (3) Linux distros and I like openSUSE better than Fedora and Ubuntu so far.
I just noticed though that, compared to the other two, advanced boot options (the one with the option to boot into recovery mode, among other things) appears to be enabled by default in openSUSE. As my intent for moving away from Windows is leaning more towards business-like use, I’m concerned that having this pop up every time a computer is turned on may trigger the curiosity of some “regular users” and behave like shadow IT, exploring options to bypass security restrictions in place.
So I explored YaST and saw an option under Bootloader to hide the menu on boot and set the timeout seconds. But when I tried that, there’s still a brief flash saying press something to reveal the menu (I can’t remember if I recall it right, I’ll post an addendum when I come across it again). There’s an option for password protection, but I’m not sure how that will play out in a directory-enabled network (more passwords to manage is not a pretty picture).
Fedora and Ubuntu appears to not do that by default, so I’m wondering if there’s a similar way to make openSUSE behave that way as well. I know that merely hiding it from casual view does not really ensure protection but, coming from Windows, most regular users never knew about the existence of Safe Mode until they saw someone access the advanced boot options.
Any guidance on this would be greatly appreciated.
Nope, it’s not the password option. But ( don’t know if Leap has that ), there’s an option “Hide menu at boot”. If you check that, the user cannot access the GRUB2 bootmenu. The password affects editing items at boot.
I don’t think recovery mode helps a regular user to become root, but if you want, you can remove the recovery options, edit /etc/default/grub (uncomment the line):
#Uncomment to disable generation of recovery mode menu entries
# GRUB_DISABLE_RECOVERY="true"
Then on YaST Bootloader, select:
Hide Menu on Boot
Timeout to 0
Protect Boot Loader with Password
Protect Entry Modification Only
From YaST Bootloader help:
Protect Boot Loader with Password at boot time, modifying or even booting any entry will require the password. If Protect Entry Modification Only is checked then booting any entry is not restricted but modifying entries requires the password (which is the way GRUB 1 behaved). As side-effect of this option, rd.shell=0 is added to kernel parameters, to prevent an unauthorized access to the initrd shell.
In BIOS, also protect with password and remove option for booting from USB.
Hi @awerlang, thanks for the insights. I just have reservations on removing recovery mode from the boot menu options because, if I correctly understood what I have been reading so far, those options are helpful in case someting goes wrong with the OS and you need to troubleshoot. For the BIOS, yes, I have those covered. As for the clarification on the password protection, it looks promising. Follow-up question on that though: would you know how this works in a domain environment? I don’t have an LDAP server set up yet, so I am unable to test my theory on centralized management in Linux.
Hi @Knurpht, yes, there is a Hide menu at boot option in Leap. It’s available in YaST. Hang on, I’ll reboot my laptop in a bit so I can tell you what that brief message says when I use that option.
The menu could not be accessed no matter how fast I pressed ‘t’ during boot, so perhaps just setting it to 1 second would suffice
Check **Protect Bootloader with Password **
and uncheck Protect Entry Modification Only
It does protect the menu from being accessed
I set a password that is different from the local root account and noticed that it uses the password specified in YaST (is GRUB root different from the root we use when running sudo?)
It may be a challenge to centralize the password in a domain environment if this is the case
@Knurpht, the message that flashes during boot even if the menu is hidden is this: “Press t to show the boot menu on this console”
The recovery option is different than the ability to edit the command line. The only difference between recovery and normal boot is the absence of any kernel parameters (set in YaST Bootloader). I just test it to confirm. You could achieve the same result the typing ‘e’ in the grub menu. So the recovery option won’t help anyone taking over the machine. But you’ll also require another method to really recover the machine.
I have occasionally booted a system with a terminal attached. I would be doing that in a virtual machine, which virtualizes an xterm (or similar) session as a serial terminal.
When I do that, I see the message “Press t to show the boot menu” on the terminal, but I don’t get a menu. Presumably if I press t on that terminal, I will get a menu (I never actually tried that).
I mention this, because I suspect that’s why the “Press t …” is there.
Check **Protect Bootloader with Password **and uncheck Protect Entry Modification Only
It does protect the menu from being accessed
I set a password that is different from the local root account and noticed that it uses the password specified in YaST (is GRUB root different from the root we use when running sudo?)
It may be a challenge to centralize the password in a domain environment if this is the case
I’m pretty sure that this is independent of the linux root (the “sudo” root). I have never tried that password option, but my guess has been that the password is stored in “/etc/default/grub” (which is then made readable only by root). If that turns out to be right, you could probably use that for your centralizing.
The password of the root user in a booted Linux system is of course different from the password used by Grub. Grub has no access to a userid/password list of any of the Linux systems it might be able to boot (and when it had, which of the many Linux systems in a multi boot situation should it take?)
And there aren’t different users in Grub, thus there is no user named root in Grub. There is just password protection for certain actions implemented in Grub.
This is specific to EFI. It switches to text mode from graphical. I do not understand why it is needed. According to commit message, there are EFI systems which cannot display menu in graphical mode. But I see no difference between displaying splash screen image and displaying menu image. Anyway, if menu is set to “hidden”, you can press ESC to display graphical menu and on EFI press ‘t’ to switch to pure text and display menu, the problem is, if menu timeout is set to 0, grub does not wait for you to do either and starts booting immediately. The “press ‘t’” is displayed unconditionally; this can be considered a bug, it should probably not be displayed when timeout is zero.
There are. You can assign different passwords to different user names and assign different permissions to them. E.g. to allow only boot specific menu items but not edit them or escape to CLI.
My fault, I admit that I did not realy check that :shame:
But the message to the OP was that there is no connection between any password validation in Grub and the validation lists (like /etc/passwd and /etc/shadow) in any of the systems that may or not may be on the system (or even on the subset of them that are known to Grub). Grub only has (and needs) access to files (like it’s configuration and the kernel) in /boot and nothing outside it.
If I correctly understood all the replies I got so far, we can have multiple usernames and passwords for GRUB, but it is not possible to centralize authentication (e.g. via an LDAP server) for GRUB because it does not have access to the validation lists such as passwd and shadow. Is this accurate?
