How do I prevent Grub command-line boots?

[perspectoff]

Re: How do I prevent Grub command-line boots?

I also found the solution for Grub Legacy, which was kind of in front of my nose the whole time.

At the top of menu.lst for Grub Legacy there is a "password" option that is commented out.

When it is uncommented (whether an actual password is used or not), entering the command-line and manually editing the menu items is disabled (unless, presumably, a specified password is entered). Menu items using this password can be locked by entering the word "lock" below the title of the menu item. I read the Grub Legacy Manual 20 times but could never sort it out.

(I found the answer in a single post on Ubuntu Forums from 2007

http://ubuntuforums.org/showthread.php?t=7353 (Post #7)

-- good thing they haven't removed the archives there).

This works fine.

Problem solved.

[kubicle]

Re: How do I prevent Grub command-line boots?

I also found the solution for Grub Legacy, which was kind of in front of my nose the whole time.

Ah, didn't realize you were using Grub legacy...and focused on grub2, sorry for that.

Anyway, all is well that ends well.

[perspectoff]

Re: How do I prevent Grub command-line boots?

I use both. I use Grub Legacy in a boot partition to chainload every other bootloader. I needed to password-protect Grub Legacy, therefore.

(My computers have Windows, Mac OSX, OpenSuse, CentOS, and (K)Ubuntu on them, and I change them around a good deal. Grub2 has been pretty unsatisfactory under these circumstances, IMO. It is much easier to use Grub Legacy merely to chainload the native bootloader of whichever OS is being booted, rather than expect Grub2 to act as the bootloader for all of them. It is also an awful lot of work to install Grub2 into a self-contained boot partition and configure it there. I'm not even sure it can be done. Grub Legacy lives quite happily on its own in a /boot partition, and does not even need an installed OS in order to function. On the other hand, I believe Grub2 only functions properly when installed inside a partition with a running OS, but I could be wrong.)

Of course, every (K)Ubuntu OS after Karmic has had Grub2 as its native bootloader, so, of course, that is the bootloader that is chainloaded each time from Grub Legacy. So not only did I have to password-secure Grub Legacy (once only), but I have to secure Grub2 (for every OS installation that uses it), as well.

[kubicle]

Re: How do I prevent Grub command-line boots?

Of course, every (K)Ubuntu OS after Karmic has had Grub2 as its native bootloader, so, of course, that is the bootloader that is chainloaded each time from Grub Legacy. So not only did I have to password-secure Grub Legacy (once only), but I have to secure Grub2 (for every OS installation that uses it), as well.

That sounds like quite a bootloader Bonanza

Couldn't you let Grub Lecagy (if that's what you prefer) load all your linux installations, or do you have reason to chainload them through grub2 (for each distribution separately)?

[perspectoff]

Re: How do I prevent Grub command-line boots?

Quite the opposite.

I only need to install and set the Grub Legacy in the /boot partition once during the life of the computer. For the life of the computer, the Master Boot Record (MBR) is only allowed to refer to this /boot partition, and I never permit the bootloader of any OS to change the MBR.

By keeping the bootloader of every OS quarantined to its own OS, I avoid the endless problems you see on these forums of people who can't access their other OSs on their computer when they try to rely on a single bootloader (Grub2) for every OS.

Further, if a user installs (K)Ubuntu (or other Linux OS that uses Grub2) on their computer on two separate partitions, they get dueling copies of Grub2, both trying to claim the MBR, both updating independently, both requiring tweaking. Both copies of Grub2 sometimes can interact with other OSs in different ways, too (depending on their version numbers).

If a user happens to delete a no-longer-needed partition containing a copy of Grub2 to which the MBR has been allowed to refer, their computer will be non-functional until he/she goes through a lot of recovery steps to reset the MBR by "re-installing Grub2" again from recovery disks or LiveCDs, etc. No fun at all!

If a user rearranges partitions, moves an OS to a different partition, duplicates partitions (for backup or other reasons), or updates or changes the type of OS on a partition, using Grub2 as a single "master" bootloader becomes a real horror-show.

In contrast, I don't have to manage the bootloaders of any OS (except to add a password to prevent manual command-line access) and, in fact, never touch any of them. These forums are full of posts from people that must fiddle endlessly with Grub2 for anything but the most basic situation.

For a user that only has, say, a single Windows OS and a single (K)Ubuntu OS on their computer (and they will never want to have more than that and will never adjust, move, or change partitions), perhaps using Grub2 alone might be suitable.

Even in this scenario, however, Grub2 is used to chainload the Windows bootloader, so even in this most basic configuration there are, as you describe it, "a Bonanza of bootloaders" anyway.

Both Ubuntu forums and Kubuntu forums have many, many, many posts every week for the past several years of the types of problems I have described.

Not me. I never have those problems, merely by adding a /boot partition with a simple self-contained chainloader to which the MBR forever refers, installed once during the life of the computer.

To answer your question directly, though, (K)Ubuntu now installs Grub2 automatically into the partition in which (K)Ubuntu is installed.

It's a lot of work to remove it and replace it with Grub Legacy every time I install/re-install a copy of (K)Ubuntu. I have dozens of (over the years perhaps closer to a hundred) copies of (K)Ubuntu. It's better to just let them do their own thing but leave their bootloaders quarantined. (I never, ever allow any OS installation to modify the MBR.)

[perspectoff]

Re: How do I prevent Grub command-line boots?

So, the steps I have taken to limit access and prevent unauthorized bootups of my computers (that are in locations where it is not feasible/reasonable to lock them away in a vault) are these:

1 ) Set a BIOS supervisor/administrator password.

2 ) Set a Hard Drive password (through a BIOS utility/setting) which gets stored on a chip in the hard drive (able to be reset only by resoldering the hard drive). That way the hard drive can only be used in conjunction with a BIOS which has the password. If the hard drive is removed from the computer, it is not easily used in another computer.

3 ) In the BIOS, disable booting from any device except the hard drive.

4 ) Set passwords for Grub (Grub2 and/or Grub Legacy) so that the Grub command-line can not be used to manually boot from any device other than the hard drive.

5 ) Use only password-protected user accounts. Disallow root login.

6 ) When using a GUI-desktop, use screensavers that require the user password in order to return to the screen. (Not used with kiosk-mode computers).

7 ) Restrict USB access to specific users (optional).

8 ) Encrypt highly sensitive folders/drives (optional) and restrict user access by setting privileges. Set a root superuser password and disallow root access to highly sensitive encrypted folders.

These precautions are now standard on every computer that is used in our organization in kiosk mode, as well as on computers that are (necessarily) located in high-traffic areas.

(In addition, of course, any computer connected to the network (LAN or WAN) also has the usual network security precautions, firewalls, proxies, network monitoring, etc.)

Other basic (and relatively simple) recommendations are welcomed.

[Snowhog]

Re: How do I prevent Grub command-line boots?

Whoa! Just hope/pray that senilety doesn't set in.

Rule of thumb: Apply a level of security appropriate to the sensativity of the data.

[perspectoff]

Re: How do I prevent Grub command-line boots?

Some people use their computers for more than games and Twitter.

[wizard10000]

Re: How do I prevent Grub command-line boots?

Some people use their computers for more than games and Twitter.

And still completely miss the point when it comes to enterprise security.

[perspectoff]

Re: How do I prevent Grub command-line boots?

Hence Wikileaks, millions of dollars in bank losses from poor enterprise security, hacking into cloud servers bringing them down for a month, and endless other examples of security breaches. QED.

There are plenty of hackers and malicious types on the Internet that try to convince people not to use security. Wolves dressing in sheepskins, IMO. "This neighborhood is pretty safe" is their appealing mantra.

Setting a few passwords is hardly a lot of effort, though.

A lock on the door of a house generally doesn't do any good if you don't have, or don't use, a key with which to lock it, or if you then leave all the windows open ("safe" neighborhood or not).

[wizard10000]

Re: How do I prevent Grub command-line boots?

QED.

Now that's funny

In each instance of your red herring enterprise security best practices were not followed. You don't blame the process if someone fails to follow it.

[kubicle]

Re: How do I prevent Grub command-line boots?

Other basic (and relatively simple) recommendations are welcomed.

The pdf's available here have some nice tips on improving security (written for RHEL, but mostly usable on other distributions as well).