You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the Issue
When the fix-cat2.yml task re-writes the /etc/fstab line for required DISA STIG /boot/efi options (e.g., noexec, nosuid,etc...), it re-writes it with a device path (e.g., /dev/sdX1) from the value capture in {{ boot_efi_mount.device }}.
Expected Behavior
Preserve VFAT Serial Number (UUID=XXXX-XXXX) and re-write this instead. It's a psuedo-UUID because it's unlike all other Linux 128-bit (32 hex) UUIDs used for GPT, UUID, DM-LVM2, etc... This is because it's a 32-bit (8 hex) timestamp value when the VFAT file system is created.
Actual Behavior
We're still tracking down the root cause, but it seems when the values are captured in the prior JSON, possibly due to the Ansible Galaxy POSIX module's Mount or other functions, it expects a 128-bit (32 hex) UUID, instead of a 32-bit (8 hex) Serial Number, and skips, falling back to the Device path. The EFI System Partition (ESP) mounted as /boot/efi is a FAT file system, and does not have a traditional 128-bit (32 hex) UUID, but the Linux mount command will take a 32-bit (8 hex) Serial Number as equivalent. It looks like if the UUID is not captured, the Device is used, hence the problem.
Control(s) Affected
rhel_08_010572
Environment (please complete the following information):
Ansible Version: 2.14 (RHEL8.8 Ansible-core with Ansible Galaxy modules)
Host Python Version: 3.6.8 (RHEL8.8 Python3)
Ansible Server Python Version: n/a
Additional Details: RHEL8.8 installation with the US CyberX.mil DISA STIG Ansible Playbooks run, using Ansible Lockdown to further lockdown
Additional Notes
We never noticed it until we were using a Dell PowerEdge 740xd that has a tendency to 'flip' our 240GB RAID volume for our system drive to /dev/sdb, and our multi-TB RAID volume for our data drive to /dev/sda. We confirmed Anaconda installed the OS to /dev/sda and created the UUID=XXXX-XXXX entry proper for /boot/efi, but it was changed after running Ansible-Lockdown for RHEL8-STIG. We will attempt to reproduce it on another system.
Possible Solution
Ensure VFAT 32-bit Serial Number is captured and re-written for /boot/efi in /etc/fstab when modifying options, and do not change to the device path, which may be enumerated differently on subsequent boots.
The text was updated successfully, but these errors were encountered:
Thank you for taking the time to raise this issue also for the great explanation and information provided really helps us to get a good solution.
I will aim to work on this (clients permitting the next couple of days).
Describe the Issue
When the fix-cat2.yml task re-writes the /etc/fstab line for required DISA STIG /boot/efi options (e.g., noexec, nosuid,etc...), it re-writes it with a device path (e.g., /dev/sdX1) from the value capture in {{ boot_efi_mount.device }}.
Expected Behavior
Preserve VFAT Serial Number (UUID=XXXX-XXXX) and re-write this instead. It's a psuedo-UUID because it's unlike all other Linux 128-bit (32 hex) UUIDs used for GPT, UUID, DM-LVM2, etc... This is because it's a 32-bit (8 hex) timestamp value when the VFAT file system is created.
Actual Behavior
We're still tracking down the root cause, but it seems when the values are captured in the prior JSON, possibly due to the Ansible Galaxy POSIX module's Mount or other functions, it expects a 128-bit (32 hex) UUID, instead of a 32-bit (8 hex) Serial Number, and skips, falling back to the Device path. The EFI System Partition (ESP) mounted as /boot/efi is a FAT file system, and does not have a traditional 128-bit (32 hex) UUID, but the Linux mount command will take a 32-bit (8 hex) Serial Number as equivalent. It looks like if the UUID is not captured, the Device is used, hence the problem.
Control(s) Affected
rhel_08_010572
Environment (please complete the following information):
Additional Notes
We never noticed it until we were using a Dell PowerEdge 740xd that has a tendency to 'flip' our 240GB RAID volume for our system drive to /dev/sdb, and our multi-TB RAID volume for our data drive to /dev/sda. We confirmed Anaconda installed the OS to /dev/sda and created the UUID=XXXX-XXXX entry proper for /boot/efi, but it was changed after running Ansible-Lockdown for RHEL8-STIG. We will attempt to reproduce it on another system.
Possible Solution
Ensure VFAT 32-bit Serial Number is captured and re-written for /boot/efi in /etc/fstab when modifying options, and do not change to the device path, which may be enumerated differently on subsequent boots.
The text was updated successfully, but these errors were encountered: