/boot not on a separate partition

[Eric-Domeier]

Unsure how to comply with SV-230300r743959_rule

Group Title: SRG-OS-000480-GPOS-00227

Rule Title: RHEL 8 must prevent files with the setuid and setgid bit set from being executed on the /boot directory.

Discussion: The "nosuid" mount option causes the system not to execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access.

Check Text: For systems that use UEFI, this is Not Applicable.

Verify the /boot directory is mounted with the "nosuid" option with the following command:

$ sudo mount | grep '\s/boot\s'

/dev/sda1 on /boot type xfs (rw,nosuid,relatime,seclabe,attr2,inode64,noquota)

If the /boot file system does not have the "nosuid" option set, this is a finding.

Fix Text: Configure the "/etc/fstab" to use the "nosuid" option on the /boot directory.

From the RHEL8 SPEL AMI

[root@ip-10-128-8-178 boot]# df -h /boot
Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/RootVG-rootVol   14G  5.2G  8.9G  37% /

Since /boot is mounted on root / - how is everyone complying with this STIG utilizing the SPEL image?

thanks

[lorengordon]

At the moment, due to the way /boot is mounted, we're considering that to be an invalid finding, resulting from a bad check. Perhaps an issue on the ComplianceAsCode/content project would make some headway fixing the check, or get some further insight into why the check is what it is. @ferricoxide please correct me if that isn't quite right.

[Eric-Domeier]

Looking at the Redhat docs, it is recommended that /boot is on it's own partition

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/performing_a_standard_rhel_8_installation/partitioning-reference_installing-rhel

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/assembly_securing-rhel-during-installation-security-hardening#Disk_partitioning_securing-rhel-during-installation

But I can't find anything about why nosuid would need to be set on the /boot

[ferricoxide]

For our EL7-based builds, we were using MBR disk-formatting. For EL8, we switched to using GPT. We found, while doing the refactoring of the disk-partitioning method, that the standalone /boot partition wasn't proving to be functionally-necessary. As a result, we got rid of /boot as a standalone partition in the EL8 build-logic. The content that used to be read from a /boot filesystem (and that previously required it to be a standalone, mounted filesystem) is now loaded into a raw, 16MB storage-extent at the head of the root-disk. You can see this extent by using file -s against the first partition on the root-EBS:

# file -s /dev/nvme0n1p1
/dev/nvme0n1p1: data

At this point, the primary benefit of a standalone /boot is similar to what some of the other partitioning-guidance is about: helping ensure that your / doesn't get consumed by "not root" storage-consumption. In the case of /boot storing too many initrd images (and the like).

Since the installonly_limit in the /etc/yum.conf file is set to 3, this generally means that /boot directory's contents stay under the 500MiB we allocated in our EL7 builds. Most of our images' users aren't trying to generate custom-kernels (that wouldn't be covered by the yum.conf setting), and it's assumed that if any of our images' users are generating custom-kernels, they will also know to keep an eye out to not blow up / by letting the /boot filesystem to become grossly-large.

Worth noting that, in recent versions of Compliance As Code, the "Add nosuid Option to /boot" is now a contingent setting: if there's a /boot declared in /etc/fstab file, then the nosuid mount-option must be set on /boot; however, if /boot isn't in /etc/fstab, no such mount-option is required (this can be seen in the publicly-posted OSCAP output for the 0.27.1 watchmaker release).

With respect to:

But I can't find anything about why nosuid would need to be set on the /boot

The rationale for that mount-option is described in the "Add nosuid Option to /boot" section of the previously linked-to OSCAP output:

The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from boot partitions.

[ferricoxide]

Going to mark this closed, for now. May revisit:

• When we add build-logic for EL9
• If we add builders with UEFI logic for EL8 (e.g., to allow use of Graviton instance-types)