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).