Verify /boot/efi/EFI/redhat/user.cfg Group Ownership
Ensures the UEFI GRUB password file /boot/efi/EFI/redhat/user.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 user.cfg file (/boot/efi/EFI/redhat/user.cfg) typically stores the GRUB boot-loader password hash that gates editing of boot entries and the kernel command line. 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 the boot parameters and the password hash to identify weaknesses and exploit them at boot time, before any OS-level security control is active.
What Pavois checks
Pavois reads the effective group owner of /boot/efi/EFI/redhat/user.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) where the file is absent (e.g. no GRUB password set, or BIOS boot).
only_if { file('/boot/efi/EFI/redhat/user.cfg').exist? }
describe file('/boot/efi/EFI/redhat/user.cfg') do
its('gid') { should eq 0 }
endHow to verify it is applied
Run stat -c '%G %g' /boot/efi/EFI/redhat/user.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/user.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/user.cfg.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| group | root |
|---|---|
| path | /boot/efi/EFI/redhat/user.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 user.cfg exposes the GRUB password hash and boot parameters, useful to an attacker preparing a boot-time compromise. The fix is low-risk: chgrp root only changes group ownership, not content, and does not affect booting or the stored password. Precaution: the EFI System Partition is usually VFAT and does not store Unix ownership; chgrp then takes effect via mount options (gid=/umask= in /etc/fstab). Pair this with restrictive permissions (0600/0700) so the hash is not world-readable, and do not delete or rewrite the file, only its 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.