Bug 452331 - Grub should be installed with password to stop interactive editing
Summary: Grub should be installed with password to stop interactive editing
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-21 00:35 UTC by Eric Springer
Modified: 2008-11-07 22:57 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-11-07 18:36:11 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Eric Springer 2008-06-21 00:35:12 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008061015 Firefox/3.0 for mac

Description of problem:
This is more of a suggestion, than a bug. Perhaps someone can tell me proper procedure about filing a bug report next time. I'm not sure if I've done it right.

When anaconda installs grub - it should be installed with roots password. Otherwise, anyone with physical access to the box can take it over. This is anything from cat'ing files to the grub screen (which can include password hashes, that can be cracked later and abused). To making the computer boot from an external device (that you've tried to lock in BIOS from booting) or even, loading run level 1 which gives root access to your machine.

I believe this needs to be done, because of lack of awareness. Most users are not aware their install can be hijacked in 30 seconds (conservatively) with physical access. While encrypted drives help, they do not stop the actual PC booting from another drive.

Windows XP got a lot of attention, because safe mode didn't ask for password (and logged in Administrator) but was subsequently fixed in Vista. And this is worse, as it allows the computer to be booted to a different OS.

My suggested fix. That the password option in grub is enabled. I suggest using a separate password to root's. The reason, two fold. The first being, it will get out of sync as the admin password is changed. And the second being, if the unsalted md5 hash from the grub list file is broken we do not want to compromise roots password. As the grub file will contain a sensitive hash, normal users should not have read access to it.


Version-Release number of selected component (if applicable):


How reproducible:
Always


Steps to Reproduce:
1. Turn on computer
2. Hit any key
3. Hit 'a' to modify the arguments ( I think, i tells you anyway)
4. Add a '1' at the end
5. You are now in root.

Actual Results:


Expected Results:
You should be asked for a password to modify arguments. 

Additional info:

Comment 1 Eric Springer 2008-06-21 00:52:12 UTC
Sorry. A few mistakes.
"installed with roots password." should be "installed with a password"
"admin password" should be "root's password"

And ignore my User-Agent string. I didn't realize it would get attached. The
'for mac' thing is designed to spoof Blackboard to not doing some Windows
specific checks when uploading assignments.


Comment 2 Chris Lumens 2008-11-07 18:36:11 UTC
As you said, anyone with physical access can take the machine over.  That's just how it is.  Even with a grub password, someone could get around it by trying to boot from a specially crafted CD or USB drive.  A BIOS password might help there, if the user is knowledgable enough to set one, but there are still mechanisms to defeat BIOS passwords.  If nothing else, a suitably motivated attacker could remove the drive, install it in another computer, and get what they wanted that way.

Anyway, we do offer the ability to set a GRUB password still if you review your partitioning layout.  The next screens will take you through advanced bootloader configs.

Comment 3 Eric Springer 2008-11-07 22:57:57 UTC
I certainly don't disagree with anything you said, but I disagree with your conclusion. 

(Y)our job is provide a secure operating system. There is no doubt that someone with physical access can compromise a machine, but that should be the physical aspect (which everyone is aware of, and takes precautions if appropriate) not some boot loader.

Consider two typical home machines. One is running Fedora, the other Vista. How long would it take an attacker (probably a family member or something) to get into each machine? The Fedora one, probably 30 seconds (change run level, backup old password, change password, reboot) and no tools required.

The Vista machine, on the other hand is extremely different. Yes, a typical BIOS is unlocked to allow you to change boot order, and compromised with specially crafted bootable media (such as Linux live cd). But the reason it's _so_ different, is the Vista machine has done everything in its power to stop attacks.
  

That said, it isn't exactly a technical problem, but a social/awareness one. As you said the option to stop interactive editing is available, but how many Fedora users know how easily their computer can be hijacked (or even files cat'ed from their home dir)?



So what I would really like to see, is if we could have interactive editing passworded by default (If we could find a way to hack grub to link the password with root accounts password, as creating a separate password seems a little too cumbersome).

But if that can't be done, why don't we give the GRUB password option a more prominent position in the installer, with a warning that really explains the importance of the issue. 




(In reply to comment #2)
> As you said, anyone with physical access can take the machine over.  That's
> just how it is.  Even with a grub password, someone could get around it by
> trying to boot from a specially crafted CD or USB drive.  A BIOS password might
> help there, if the user is knowledgable enough to set one, but there are still
> mechanisms to defeat BIOS passwords.  If nothing else, a suitably motivated
> attacker could remove the drive, install it in another computer, and get what
> they wanted that way.
> 
> Anyway, we do offer the ability to set a GRUB password still if you review your
> partitioning layout.  The next screens will take you through advanced
> bootloader configs.


Note You need to log in before you can comment on or make changes to this bug.