Grub 2 Password Protection

[ranch hand]

I am glad to hear that it isn't just me.

Am fighting with several other things in 10.04 but will be getting back to this in a couple of weeks.

[drs305]

Update:
I just tried enabling the console mode in /etc/default/grub and in console mode both encrypted and unencrypted password/authentication works as it should. Of course, in this mode backgrounds will not be available.

GRUB_TERMINAL=console

[ranch hand]

Wow, I was going to try that and was too chicken at the time. That is great.

I will give it a whack one of these days on one of these installs on my box. If it works I will just slap that on the wifes.

No background!! Oh My What Will We Do?

Security or Background? That is a tough one.

My main use of backgrounds is to use the wallpaper from the install supplying grub at the time so I know at a glance which I am using. I bet if I have one with a black background I can tell it too.

The Wifes background is very nice but you don't see it for very long. I think she will get over it and she only needs that security when away anyway. Two sets of the needed files and we are all set. One secure and the other not so secure.

Thanks a bunch.

[drs305]

Wow, I was going to try that and was too chicken at the time. That is great.
Thanks a bunch.

I was pleasantly surprised that it worked, even with the encrypted password using grub-mkpasswd_pbkdf2.

I should note the encrypted passwords are available in Grub 1.98+ (Lucid) or the experimental branches, not in Karmic and 1.97~beta.

@ ranch hand: I'm off for a week, so I expect you to have everything Grub 2-related solved by the time I get back.


Caution Added: In playing a bit with this, I found that encrypted function still isn't working as it should. When trying to get into the edit mode I get the username and p/w prompts, but then it takes me back to the main menu. Without editing capability, make sure you have at least one entry you know will work, otherwise you won't be able to try to recover a boot via command line or editing.

Update 3/8/2010: With build 1.98~20100128-1ubuntu4 the encrypted passwords are working fine if I have GRUB_GFXMODE=console as the option in /etc/default/grub. When attempting to use it in gfxterm mode the password mode still seems to hang.

[ranch hand]

While my wifes box does run 9.10, it also is running grub1.98. I have access to the 10.04 repo.

I have a sources.list.lizard (10.04 is called Lounge Lizard isn't it) that just has the main lucid repo on it.

Change the name of the real sources list to sources.list.kinky (9.10+Kinky Kitty) and drop the .lizard and you can have the newest kernel and grub if you want them.

Kinky runs real well on 2.6.32 by the way. My wifes just runs on 31. I just want it stable. It will get upgraded to the Lizard when System76 says it will work with their drivers. I may try them before that but not on hers.

EDIT
I have no idea what you are off to but have FUN.

[smo]

hi

first, thansk for the infos

i just tried it and i have 2 questions

how can i do the protect "only" the command line edit with the "e" key or console

so anyone can boot, but only superuser can edit the menu, is it possible ?

and second question:

is it possible to change the keymap in grub2 ? i looked all the files but can t find anything for it

thx

++

[drs305]

how can i do the protect "only" the command line edit with the "e" key or console

so anyone can boot, but only superuser can edit the menu, is it possible ?

...

is it possible to change the keymap in grub2 ? i looked all the files but can t find anything for it

I have very limited experience with the keymap issue. I know you can add items such as "keymap=us" or "keymap=qwerty" to either of these lines in /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT=
GRUB_CMDLINE_LINUX=

I have also used "setkmap=us" in the linux line of a custom menu entry for mounting ISOs. That is the limit of my knowledge on keymaps in Grub2 I'm afraid.


As for the first question you asked, this is one of the things I like about the forums. Sometimes it takes a bit of thought to come up with a solution to an unanticipated request.

If a superuser and password are set the entire menu is locked for editing menuentries or entering the Grub2 command line.

Here is what I came up with regarding your request - locking the edit feature (and also command line):

1. Make at least one scripted entry password-protected, such as the recovery mode. If there is one password-enabled entry, only the superuser can edit or use the terminal. No other entries would require any user to use a password.

2. A solution that meets your requirements (all entries accessible) could be done by adding an entry into /etc/grub.d/40_custom. You could make it invisible, or add a message either at the top or bottom of the real menu. (For the bottom, make the entry in 40_custom; for the top, rename the file 06_custom). The actual entry, other than the title, wouldn't boot to anything. I've used the "insmod ext2" command since it is already used in my existing grub.cfg entries.

Here are two examples.

Invisible:

cat << EOF
menuentry " " --users superman {
insmod ext2
}
EOF

Welcome message in 06_custom:

cat << EOF
menuentry "Welcome. You Have 10 Seconds to Select a New Entry." --users superman {
insmod ext2
}
EOF

Make sure you have added at least the superuser and password in the 00_header file as described in the first post and then update grub.

[petteriIII]

Thanks for your excellent Howto. I have been using the manual way of editing grub.cfg - the editing calls for helper-programs to pull trough and if you don't have them dont't even try. But when editing by hand there is no need to touch any configuration-files in any condition and there are no limits to what you can edit. But anyway password-protection operates just as you said. My grub.cfg in it's entirety is as follows:

set timeout=5
set default="Lucid-1, 2.6.32-18-generic, sda1"

# Superuser petteri's password is 1234 in the context of editing menuline when booting or going to commandline; it is not the usual 'sudo-password'. Normal user osmo can boot Lucid-2 wit password 4321; other users cannot boot it at all.
set superusers="petteri"
password petteri 1234
password osmo 4321

menuentry "Lucid-1, 2.6.32-18-generic, sda1" --class ubuntu --class gnu-linux --class gnu --class os {
insmod ext2
set root='(/dev/sda,1)'
search --no-floppy --fs-uuid --set df4b9966-28ad-41b3-936d-fa5470865131
linux /boot/vmlinuz-2.6.32-18-generic root=UUID=df4b9966-28ad-41b3-936d-fa5470865131 ro quiet splash
initrd /boot/initrd.img-2.6.32-18-generic
}

menuentry "Lucid-2, sda2" --users osmo {
configfile (hd0,2)/boot/grub/grub.cfg
}

[eotakos]

Thank you very much for the how-to. I tried password protecting without encryption on lucid and it worked right away. I can't afford trying the risky encryption thing because I am on vacation, without a live-cd, and my connection is over my mobile phone...

There was this trick suggested in the forums for the previous version of grub, in which instead of encryption, the permitions of menu.lst were changed in order to prevent unauthorized users from reading the unencrypted password from within the file.... could something like this work in this case? like changing the permitions of 00_header and grub.cfg files? (unfortunately I can't test it myself because I'd be left helpless without an OS in case of a failure... anyhow... I'll probably check this out when I get home)


Thanks again for the thread!

[drs305]

eotakos,

I just did a simple "sudo chmod -r <path/filename>" on /boot/grub/grub.cfg and /etc/grub.d/00_header.

sudo chmod -r /boot/grub/grub.cfg /etc/grub.d/00_header

Without the +r attribute, a normal user can't use "cat" or open the file for viewing without admin privileges. The update-grub command worked fine and any of the commands combined with "sudo" or "gksudo" worked normally.