Verify the UEFI Boot Loader grub.cfg Group Ownership
Ensures the UEFI GRUB 2 config /boot/efi/EFI/redhat/grub.cfg is group-owned by root (gid 0).
Checked against a path’s metadata, mode, owner, group, SUID/SGID.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
The UEFI GRUB 2 configuration file /boot/efi/EFI/redhat/grub.cfg controls how the system boots, including kernel command-line parameters and the boot-loader password. The root group is highly privileged, and the group-owner of this file should have no access privileges anyway. If a non-root group owns it, members of that group could read boot parameters to spot security weaknesses, or, combined with loose permissions, alter the boot configuration and compromise the system before any OS-level control loads.
What Pavois checks
Pavois reads the effective group owner of /boot/efi/EFI/redhat/grub.cfg on the live system via the InSpec file resource and asserts gid == 0. It inspects the actual inode metadata as the kernel sees it on the mounted EFI System Partition, not a packaging default, so post-install drift is caught. The check is skipped (only_if) on systems where the file is absent (e.g. BIOS boot).
only_if { file('/boot/efi/EFI/redhat/grub.cfg').exist? }
describe file('/boot/efi/EFI/redhat/grub.cfg') do
its('gid') { should eq 0 }
endHow to verify it is applied
Run stat -c '%G %g' /boot/efi/EFI/redhat/grub.cfg. Expected output: root 0. Any other group name or non-zero gid means the rule is not applied.
Inspect & investigate
Ownership changes are not logged by default. Watch the file with auditd: auditctl -w /boot/efi/EFI/redhat/grub.cfg -p wa -k grub-perms, then inspect grep 'key="grub-perms"' /var/log/audit/audit.log. Boot-loader activity is visible in the kernel ring buffer (dmesg) and journalctl -b after a reboot.
Remediation
No automated remediation is defined for this rule, so it must be applied manually. Restore the correct group ownership with chgrp root /boot/efi/EFI/redhat/grub.cfg.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| group | root |
|---|---|
| path | /boot/efi/EFI/redhat/grub.cfg |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
A non-root group owner on the UEFI grub.cfg exposes boot parameters and, with loose permissions, the boot configuration itself, a pre-OS attack surface. The fix is low-risk: chgrp root only changes group ownership, not content, and does not affect booting. Precaution: the EFI System Partition is usually VFAT, which does not store Unix ownership; chgrp then takes effect via mount options (gid=/umask= in /etc/fstab). Re-running grub2-mkconfig regenerates the file and may reset ownership, so re-apply afterward. Do not alter the file's content here, only ownership.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R29 | direct | 2.0 | high |
| CIS | 1.4.2 | direct | per OS, see the benchmark table | high |
| NIST | 3.4.5 | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.