grub.cfg Permissions: Fixing the CIS Bootloader Config Finding

“Ensure permissions on bootloader config are configured” is a CIS benchmark check that fails when grub.cfg permissions give group or other users any access, or the file is not owned by root:root. Fix it with chown root:root and chmod u-x,go-rwx on grub.cfg (plus grubenv and user.cfg on RHEL-family systems), or with vfat mount options on an EFI partition.

Two things trip people up: UEFI systems, where chmod has no lasting effect on the FAT-formatted EFI partition, and GRUB builds that reset the mode when the configuration is regenerated.

What the scanner is actually detecting

This is a configuration item from the CIS Linux audit files that Nessus and other Tenable products run during an authenticated compliance scan. It has no CVE; it reports PASSED or FAILED based on the owner, group and mode of the GRUB files. Newer CIS benchmarks call it “Ensure access to bootloader config is configured”, and item numbers vary, so search your report by title:

Note that the Debian 11 v1.0.0 remediation also removes the owner’s write bit (0400), while most current benchmarks allow 0600; 0400 satisfies both. Some audits, such as CIS Red Hat EL7 STIG v2.0.0, report grub.cfg and user.cfg as separate items. “Ensure bootloader password is set” is a different check that this fix does not satisfy.

Real-world risk, stated honestly

This is a low-severity hardening item, not a remotely exploitable flaw. The CIS rationale is that non-root users who can read boot parameters may spot weaknesses in how the system starts. What a reader gains depends on the file:

• Kernel parameters and boot entries: low value, since any local user can already read the running kernel’s command line from /proc/cmdline.
• A GRUB password hash: Debian and Ubuntu keep the password_pbkdf2 line in grub.cfg; RHEL-family grub2-setpassword stores it in user.cfg. A readable hash can be attacked offline. This is the best reason to fix the item.
• Write access for non-root users: rare, but urgent if the audit shows it, because that user could change kernel parameters for the next boot.

All of this needs a local account. On a server only administrators log into, the practical risk is small.

How to confirm it on the host

# BIOS or UEFI?
[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS

# Mode, owner:group and path of every GRUB file under /boot (includes /boot/efi)
sudo find /boot ( -name grub.cfg -o -name grubenv -o -name user.cfg ) -type f 
  -exec stat -c '%a %U:%G %n' {} +

# Filesystem and mount options of the EFI partition, if any
findmnt /boot/efi -o SOURCE,FSTYPE,OPTIONS

A compliant file shows 600 or 400 and root:root; 644 or 444 fails. Where the real configuration lives:

• RHEL 9 and later family: /boot/grub2 on all architectures. On UEFI, /boot/efi/EFI/redhat/grub.cfg only loads /boot/grub2/grub.cfg.
• RHEL 7 and 8 family on UEFI: the EFI vendor directory (for example /boot/efi/EFI/redhat), on vfat.
• Debian and Ubuntu: the audits check /boot/grub/grub.cfg.

How to fix it

Record the current state first so you can roll back:

sudo find /boot ( -name grub.cfg -o -name grubenv -o -name user.cfg ) -type f 
  -exec stat -c '%a %U:%G %n' {} + | sudo tee /root/grub-perms.before

RHEL, CentOS, Rocky Linux, AlmaLinux, Oracle Linux and Amazon Linux

This follows the CIS remediation for files in /boot/grub2. Run it from a root shell:

for f in /boot/grub2/grub.cfg /boot/grub2/grubenv /boot/grub2/user.cfg; do
  [ -f "$f" ] && chown root:root "$f" && chmod u-x,go-rwx "$f"
done

The [ -f ] test skips user.cfg on hosts without a GRUB password. For audits that expect 0400, use chmod u-wx,go-rwx. If chmod reports “Operation not permitted”, the file (or a symlink’s target) is on the EFI partition; see the UEFI section.

Debian and Ubuntu

sudo chown root:root /boot/grub/grub.cfg
sudo chmod u-x,go-rwx /boot/grub/grub.cfg     # 0600 or stricter

# Audits that expect 0400, such as CIS Debian 11 v1.0.0:
sudo chmod u-wx,go-rwx /boot/grub/grub.cfg

UEFI with the configuration on the EFI system partition

FAT (vfat) has no Unix owners or modes. The mount(8) man page defines uid= and gid= as the owner and group of all files and fmask= as the umask for regular files, so the fix goes in /etc/fstab. The CIS example:

<device> /boot/efi vfat defaults,umask=0027,fmask=0077,uid=0,gid=0 0 0

Rather than pasting it, add fmask=0077,uid=0,gid=0 to your existing /boot/efi entry and keep its device, dump and pass fields. If it already has umask=0077, keep that; 0027 would loosen directories. Then apply:

sudo cp -a /etc/fstab /root/fstab.bak
sudoedit /etc/fstab                  # change only the /boot/efi options
sudo findmnt --verify                # parse check before mounting
sudo systemctl daemon-reload
sudo umount /boot/efi && sudo mount /boot/efi

Do not rely on mount -o remount: the kernel’s FAT driver ignores mount options on a remount. If umount says the target is busy, reboot in a maintenance window, as CIS suggests. On RHEL 9 and later, if the audit output names only /boot/grub2 files, the chmod fix is enough.

Keep it fixed after update-grub or grub2-mkconfig

Regeneration behavior depends on the GRUB build. The CIS Ubuntu 16.04 benchmark even had an item, “Ensure permissions on bootloader config are not overridden”, because update-grub reset grub.cfg to 444. Debian’s GRUB 2.02 package shows why: grub-mkconfig sets the new file to 444 when no line starts with password, then moves it over grub.cfg. Debian’s 2.06 packages (Debian 11 and 12) copy the new contents into the existing file instead, so your mode survives (see the grub-mkconfig source), and upstream GRUB 2.12 does the same. Distributions patch this script, so re-check after the next regeneration and let configuration management enforce owner and mode.

How to verify the fix and rescan

sudo find /boot ( -name grub.cfg -o -name grubenv -o -name user.cfg ) -type f 
  -exec stat -c '%a %U:%G %n' {} +
# expect 600 or 400 with root:root; vfat files typically show 700 root:root

findmnt /boot/efi -o OPTIONS
# expect fmask=0077; uid= and gid= are omitted from this output when they are 0

Then rerun the same compliance scan with the same audit file and confirm the item moves to PASSED. If you edited /etc/fstab, reboot once in a maintenance window to prove /boot/efi still mounts cleanly.

What can break and how to roll back

• Booting is unaffected by the chmod. GRUB reads its files with its own filesystem drivers before Linux starts, and root can still write the file, so update-grub keeps working.
• Non-root readers lose access. Scripts or monitoring agents that parse grub.cfg as an unprivileged user will get “Permission denied”.
• A bad fstab line can stop a clean boot and drop the host into emergency mode. Run findmnt –verify and keep console access.

To roll back file modes, run this from a root shell (errors on vfat files are expected):

while read -r mode owner file; do
  chown "$owner" "$file"; chmod "$mode" "$file"
done < /root/grub-perms.before

For the EFI change, restore /root/fstab.bak, run systemctl daemon-reload, then unmount and mount /boot/efi again, or reboot.

Common false positive reasons

• The scan account could not elevate. Without working sudo, the audit may fail to inspect files under /boot on a compliant host. See our guide to SSH credentials and sudo for Linux authenticated scans.
• Benchmark version mismatch. A 0600 grub.cfg fails an audit that expects 0400, such as CIS Debian 11 v1.0.0.
• The file is not where you fixed it. On RHEL 7 and 8 family UEFI hosts, grub.cfg is on the EFI partition, where only mount options help.
• GRUB is not the bootloader. Containers, other bootloaders and VMs that boot a kernel directly have nothing to check. CIS says to apply equivalent settings; record a documented exception.

FAQ

Should grub.cfg be 0400 or 0600?

Current CIS benchmarks accept 0600 or stricter; the older Debian 11 v1.0.0 benchmark asks for 0400. Use 0400 if you run mixed audit versions.

Why does chmod not stick under /boot/efi?

FAT has no Unix permissions. Set fmask=0077,uid=0,gid=0 in /etc/fstab and mount the partition again.

Why did the finding return after an update?

Kernel and GRUB package updates can regenerate grub.cfg, and some GRUB builds write it with a looser mode. That is a true positive; enforce the mode with configuration management.

Does this fix the GRUB password finding too?

No. “Ensure bootloader password is set” is a separate item. Tight permissions protect the hash once you set one.

Tracking this finding across many hosts

On a large Linux fleet, this item tends to reappear after image rebuilds and GRUB updates. If you use SITEY, you can upload the .nessus export from your compliance scan, have its AI draft a host-specific script that runs only after a human approves it, deploy it through its agents on Linux endpoints, and let it re-test the host to confirm the finding closed. Duplicates are merged per scanner, not across scanners.

Sources

• Tenable: CIS Debian Linux 11 Server L1 v1.0.0, 1.4.2 Ensure permissions on bootloader config are configured
• Tenable: CIS Red Hat Enterprise Linux 9 v2.0.0 L1 Server, 1.4.2 Ensure access to bootloader config is configured
• Tenable: CIS Ubuntu Linux 16.04 LTS Server L1 v2.0.0, 1.4.1 Ensure permissions on bootloader config are not overridden
• Red Hat: Considerations in adopting RHEL 9, Kernel (boot loader configuration files unified)
• mount(8) Linux manual page: mount options for fat