From here on out, the steps are the same for both the CentOS and the Ubuntu virtual machines, except for the following:
- On your Ubuntu machine, the grub.cfg file is in the /boot/grub/ directory. On your CentOS machine, it's in the /boot/grub2/ directory.
- On Ubuntu, the /boot/grub/ and /etc/grub.d/ directories are world-readable. This means you can cd into them as a normal user.
- On CentOS, the /boot/grub2/ and /etc/grub.d/ directories are restricted to the root user. So, to cd into them, you'll need to log in to the root user's shell. Alternatively, you can list the contents from your normal user shell with sudo ls -l, and you can edit the files you need to edit with sudo vim /boot/grub2/grub.cfg or sudo vim /etc/grub.d/40_custom. (Substitute your favorite editor for vim.)
- On Ubuntu, the command to create a password hash is grub-mkpasswd-pbkdf2. On CentOS, the command is grub2-mkpasswd-pbkdf2.
With these slight differences in mind, let's get started.
The first thing you'll do is create a password hash for your new users:
- On Ubuntu, use the following command:
grub-mkpasswd-pbkdf2
- On CentOS, use the following command:
grub2-mkpasswd-pbkdf2
Next, open the /etc/grub.d/40_custom file in your text editor and add a line for your new user, along with the password hash that you just created. The line should look something like this:
password_pbkdf2 goldie grub.pbkdf2.sha512.10000.225205CBA2584240624D077ACB84E86C70349BBC00DF40A219F88E5691FB222DD6E2F7765E96C63C4A8FA3B41BDBF62DA1F3B07C700D78BC5DE524DCAD9DD88B.9655985015C3BEF29A7B8E0A6EA42599B1152580251FF99AA61FE68C1C1209ACDCBBBDAA7A97D4FC4DA6984504923E1449253024619A82A57CECB1DCDEE53C06
Note that this is all one line that wraps around on the printed page.
What you're supposed to do next is run a utility that will read all of the files in the /etc/grub.d/ directory, along with the /etc/default/grub file. This will rebuild the grub.cfg file. However, on CentOS, that utility doesn't work correctly. On Ubuntu, it does work correctly, but it will overwrite any changes that you might have already made to the grub.cfg file. So, we're going to cheat.
Open the grub.cfg file in your text editor:
- On Ubuntu, use the following command:
sudo vim /boot/grub/grub.cfg
- On CentOS, use the following command:
sudo vim /boot/grub2/grub.cfg
Scroll down until you see the ### BEGIN /etc/grub.d/40_custom ### section. In this section, copy and paste the line that you just added to the 40_custom file. This section should now look something like this:
### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
password_pbkdf2 "goldie" grub.pbkdf2.sha512.10000.225205CBA2584240624D077ACB84E86C70349BBC00DF40A219F88E5691FB222DD6E2F7765E96C63C4A8FA3B41BDBF62DA1F3B07C700D78BC5DE524DCAD9DD88B.9655985015C3BEF29A7B8E0A6EA42599B1152580251FF99AA61FE68C1C1209ACDCBBBDAA7A97D4FC4DA6984504923E1449253024619A82A57CECB1DCDEE53C06
### END /etc/grub.d/40_custom ###
Finally, you're ready to password protect the individual menu entries. And here, I've discovered yet another difference between Ubuntu and CentOS.
In all of the menu entries for CentOS, you'll see that the --unrestricted option is already there for all menu entries. This means that, by default, all users are allowed to boot every menu option, even if you've set a superuser password:
menuentry 'CentOS Linux (3.10.0-693.11.1.el7.x86_64) 7 (Core)' --class centos --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-693.el7.x86_64-advanced-f338b70d-ff57-404e-a349-6fd84ad1b692' {
So, on CentOS, you don't have to do anything if you want all users to be able to use all available boot options.
Now, let's say that you have a menuentry that you want to be accessible to everybody. On CentOS, as I just pointed out, you don't have to do anything. On Ubuntu, add --unrestricted to the menuentry, as you did previously:
menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-f0f002e8-16b2-45a1-bebc-41e518ab9497' --unrestricted {
If you want nobody but the superuser to boot from a particular option, add --users "" (on CentOS, be sure to remove the --unrestricted option first):
menuentry 'Ubuntu, with Linux 4.4.0-98-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.4.0-98-generic-recovery-f0f002e8-16b2-45a1-bebc-41e518ab9497' --users "" {
If you want only the superuser and some other particular user to boot from a certain option, add --users, followed by the username (again, on CentOS, remove the --unrestricted option first):
menuentry 'Ubuntu, with Linux 4.4.0-97-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.4.0-97-generic-advanced-f0f002e8-16b2-45a1-bebc-41e518ab9497' --users goldie {
If you have more than one user that you want to access a boot option, add an entry for the new user in the ### BEGIN /etc/grub.d/40_custom ### section. Then, add the new user to the menuentry that you want him or her to access. Separate the usernames with a comma:
menuentry 'Ubuntu, with Linux 4.4.0-97-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.4.0-97-generic-advanced-f0f002e8-16b2-45a1-bebc-41e518ab9497' --users goldie,frank {
Save the file and reboot to try out the different options.
Now that we've gone through all this work, I need to remind you again that any manual edits that you've made to the grub.cfg file will be lost any time a new grub.cfg file is generated. So, any time you do a system update that includes either installing or removing a kernel, you'll need to manually edit this file again to add password protection. (In fact, the only real reason I had you add the users and their passwords to the /etc/grub.d/40_custom file is so that you'll always have that information available to copy and paste into grub.cfg.) I wish that there were a more elegant way of doing this, but according to the official GRUB 2 documentation, there isn't.
Before we leave this topic, I'd like to share my personal thoughts about GRUB 2.
It was necessary to create a new version of GRUB because the old legacy version doesn't work with the new UEFI-based motherboards. However, there are things about GRUB 2 that are very disappointing.
First, unlike legacy GRUB, GRUB 2 isn't implemented consistently across all Linux distros. In fact, we've just seen in our demos how we have to do things differently when we go from CentOS to Ubuntu.
Next is the fact that the GRUB 2 developers gave us some good security options, but they haven't given us an elegant way of implementing them. I mean, really. The whole idea of telling us to implement security features by hand-editing a file that will be overwritten every time we do an operating system update just doesn't seem right.
And finally, there's the sad state of the GRUB 2 documentation. I don't mean to sound like I'm tooting my own horn because I know that that's unbecoming. However, I think it's safe to say that this is the only comprehensive writeup you'll find anywhere for using the password protection features of GRUB 2.
Now, you probably know more about GRUB 2 than most people you know. Next, we'll talk about locking down the BIOS/UEFI settings.