Now that we've configured the system to require a root password to get into single user mode, let me show you how easy it is to get around that too. Remember that when the bootloader loads the colonel, then the colonel loads in a knit system like a knit or system deep. What we can do is tell the colonel to use this shell as the init system is bypasses the init system altogether and drops you into a root shell. I've interrupted the boot process here and I'm going to go ahead and edit the kernel parameters. And what I'm going to do is simply type init equals bin slash bash. So what I'm doing is replacing the init system. I'm telling the kernel to use bash as the init system. I'll go ahead and execute this configuration. So instead of running the normal init process that executes the startup scripts and asks you for passwords and that sort of thing, just the bash shell is executed. To protect against this tactic, we need to stop someone from passing in arguments to the kernel. To do this, we can require a password on the bootloader before you are allowed to make any changes. Here's how to password protect the grub boot loader. First, we're going to play some configuration and Etsy grub dot D. You can place the configuration anywhere you want but I recommend using the 40 underscore custom file. Since it shouldn't be overwritten, even when the grub package is updated. Go ahead and modify that file. And what we're going to do here is put in set super users equals, and then you can choose a username. 

I'm just going to use root. You can put anything here. You could put Jason, you could put Bob, you could put admin this is not operating system related. This is for the bootloader. So we'll set super users in this example to root and we'll go ahead and put a password on this root account. We'll set the password for the root account to root. I know that's not very secure but this is just a simple example. Now, if you want to encrypt the passwords you can use the grub to make password P B K D F two command on Santos or REL or it's the grub dash M K P A S S w D dash P B K D F two on Ubuntu systems. So just look for grub and MK password is it varies from distribution to distribution. So if I run this and I enter a password then we get this output. So instead of using password root root then instead of using password route route what we would use would be password underscore P B K DF two root, and then this long output that's on your screen here grub dot P B K D F two Shaw five one 12, et cetera. And that's what would go in that 40 underscore custom file. If you wanted to use an encrypted password which I actually recommend. Next, you should rebuild the grub dot CFG file. Again, this will differ a bit, depending on how your distribution implemented grub for Santos and Red Hat. The command is grub two make config dash Oh four output and then we'll supply the path to the grub.com file. And we'll go ahead and hit enter and it will generate that configuration and use that additional configuration we added in the custom file for grub. If you're using Ubuntu, the command is update grub. Again, you're going to have to refer to the documentation for your specific distribution. 

Okay, we're going to go ahead and reboot the system and boot in a single user mode or attempt to boot into a single user mode. And we'll see if this works. So I'm here and I would normally press E and I'll go ahead and do that now. And now it's asking for a username, and this is the username that we supplied in the grub configuration. And this example I use root, but again you could use any username that you'd like. Let me supply a wrong password. If you supply the wrong password, you get booted to the main menu and then I'll do it again. This time with the correct password. Now I have access to the kernel parameters. Again, using a password on the bootloader prevents someone from booting into single user mode or bypassing it entirely by passing a net equals been bashed to the kernel. Even this solution isn't perfect because if you have physical access to the system, you can simply insert your own bootable CD DVD or USB device. I'm going to insert a virtual CD into our virtual CD rom here on our virtual machine. And I'll just go ahead and use this disc image. And I'm going to hit the power button again the virtual power button for this example. But again, this is exactly how you would do it if you had access to the physical system. So here we're booting from the CD. This CD is a Cintos installed disc, which also has some built in rescue and troubleshooting tools. I'm going to select the troubleshooting menu and then select rescue a Cento system. 

Now the system has been booted from this CD and on this particular CD it asked me if I would like to try to Mount the file systems and I'll go ahead and say, continue to go ahead and let the CD try to go ahead and mount the file systems for me. All right. I'll press enter to get to a shell. And here I am at the root shell. Oops. And then there are my discs. They're mounted under mount system image. And I can go in here. For example, I'll go to boot grub two and then I can just edit this grub dot CFG file. And we'll look for Here is the configuration we added the super users equals root and the password. And I could simply just edit this out, reboot the system. I'll go ahead and do that now. And now we have access to grub without a password. All right, now I've interrupted the boot process and I hit E to edit the configuration and I'm not prompted for a password. The important thing to remember here is that if someone can gain access to the storage that your server uses they can do whatever they want to with it. If your disc or a virtual disc rather live in the cloud then the service provider can potentially access your virtual disc and view and modify them. The way to mitigate this risk in this scenario is to encrypt your data. We'll talk about encryption in another part of the course.