With grub-legacy setting a password in menu.lst made the single-user modes locked. Now I don't see a way to add passwords/locking to grub, (z)grepping through /etc/default/grub, /etc/grub.d/, /usr/share/doc/grub-pc/ doesn't give a hint.
Am Samstag, den 05.09.2009, 14:59 +0200 schrieb Norbert Preining: It's documented in the official GRUB wiki, which is linked to in the /urs/share/doc/grub-pc/README: http://grub.enbug.org/Authentication Integrating this into grub-mkconfig isn't that easy.
It is not too hard to just have a password which blocks people from editing the grub options (and thus let them do init=/bin/sh). That in combo with a proper BIOS lock from booting from anything else but the main disk will at least deter people from quickly changing the disk. Of course as they have physical access they can do a lot of other things, but it helps a bit ;) (and can be very annoying if you forget your password though, but heck) To just add a password which thus doesn't allow editing of boot entries: 8<------------------------------------------------------- jeroen@purgatory:~$ cat /etc/grub.d/42_password #!/bin/sh exec tail -n +1 $0 # add a password so that grub entries can't be edited set superusers="jeroen" password jeroen mypassword ------------------------------------------------------->8 For having per-entry user limits though it will be a lot more complex. It would be good to have MD5 or actually better SHA256 hashing there, but then again if one can read the generated /boot/grub/grub.cfg then you already have root and you can just change it anyway... Greets, Jeroen
Are you sure that the exec tail -n +1 $0 does not need to be exec tail -n +3 $0 instead? Regards, Niki
Nowadays, /etc/grub.d/40_custom provides a nice place for the "set superusers" and "password*" commands But that's not sufficient, as it requires the allowed boot entries to be marked --unrestricted, which no script appears to support yet. I am adding myself --unrestricted to the CLASS definition in /etc/grub.d/10_linux, but that's clearly a hack, as shown by the system being turned unbootable each time I forget that *I* was the one adding that option and let the package overwrite this script with the new version. With today's infrastructure, it would not be too hard to let the admin add such a flag from /etc/default/grub, maybe with an ADDFLAGS variable that would be usable by more than the 10_linux script (think Hurd/*BSD/memtest*/whatever). Or do I miss something ?
Nowadays, /etc/grub.d/40_custom provides a nice place for the "set superusers" and "password*" commands But that's not sufficient, as it requires the allowed boot entries to be marked --unrestricted, which no script appears to support yet. I am adding myself --unrestricted to the CLASS definition in /etc/grub.d/10_linux, but that's clearly a hack, as shown by the system being turned unbootable each time I forget that *I* was the one adding that option and let the package overwrite this script with the new version. With today's infrastructure, it would not be too hard to let the admin add such a flag from /etc/default/grub, maybe with an ADDFLAGS variable that would be usable by more than the 10_linux script (think Hurd/*BSD/memtest*/whatever). Or do I miss something ?
Hello, This is still a problem today. In RHEL like system there is a script (grub2-setpassword) that makes it easy for the user to set a password. See: https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/0028-Add-friendly-grub2-password-config-tool-985962.patch Also by default they made the generated boot entries "unrestricted" See: https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/0022-Don-t-require-a-password-to-boot-entries-generated-b.patch Apparently debian was doing the same before? (See: #1000854) Can something be done here? Kind regards, Laurent Bigonville