Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 80776

Summary: grubby creates world-readable grub.conf files
Product: [Retired] Red Hat Linux Reporter: Alan Sundell <asundell+rhbz>
Component: mkinitrdAssignee: Erik Troan <ewt>
Status: CLOSED CURRENTRELEASE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3Keywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-10-02 11:41:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Alan Sundell 2002-12-31 06:48:47 UTC
From Bugzilla Helper:

Description of problem:
Upgrading a kernel package can result in a world-readable grub.conf file.

This file can contain sensitive information, such as (MD5-crypted) passwords
used to protect grub's interactive operations (as is recommended in the
Installation Guide).   This information can enable non-privileged local users
with console access to gain control of the boot process and thus gain root
access to the system.

The default umask for root on RedHat is "022".  grubby creates a new grub.conf
as a temporary file (using fopen) and renames it over the old grub.conf file.

Because of the umask, and because grub.conf is a new file, grub.conf ends up
mode 0644 after upgrading a kernel package (or otherwise invoking grubby), even
if the file was previously readable by root only.

The permissions on /boot and /boot/grub are both, by default, 0755, so no
protection is offered there.

Therefore, after an administrator as installed a kernel upgrade, a local user
with console access can read the crypted password from the grub.conf file, crack
it with any of various brute-force password crackers, and then gain complete
control of the system via any number of means (such as booting into single-user
mode).


Version tested:
grubby version 3.3.10 from mkinitrd-3.3.10-1

How reproducible:
Always

Steps to Reproduce:
1. chmod 600 /boot/grub/grub.conf
2. rpm -Fvh new-kernel.rpm
3. ls -l /boot/grub/grub.conf


Additional Information:
Based on a cursory look at bootloader.py, it appears that anaconda generates the
original grub.conf file with a sensible mode of 0600 (or preserves existing
permissions if a grub.conf file already exists), but I haven't tested this.

In any case, I would humbly suggest that grubby create its temporary file with
mode 0600 and then change its permissions to match the old grub.conf after
writing is complete.

On the other hand, an argument could be made that grub.conf should never be
world-readable, but I guess it depends on how heavy-handed you want to be.

The obvious workaround for this issue in the meantime is to add a "umask 077" to
the end of ~root/.bashrc before upgrading kernel packages (rpm launches
subshells which will source ~/.bashrc, so simply setting it on the command line
before running rpm is not sufficient).

Comment 1 Jeremy Katz 2003-01-06 06:25:54 UTC
Fixed in CVS and 3.4.34-1

Comment 2 Mark J. Cox 2003-10-02 11:41:12 UTC
(Therefore fixed for Red Hat Linux 9 and above)