Task "Configure hardened options for mounts" overrides fstab entries with UUID or LABEL as source with device path

[networkhell]

Description

Task: "Configure hardened options for mount {{ mount.path }}" in Task File minimize_access_fs.yml overrides all UUID, PARTUUID or LABEL entries in /etc/fstab with the device path.

Impact: this behaviour potentially renders virtual machines with multiple disks unbootable

Reproduction steps

---
- hosts: all
  vars:
    os_mnt_boot_enabled: true
  roles:
    - role: devsec.hardening.os_hardening

Current Behavior

fstab source entries of all mounts that are touched by this tasks are overridden to the device path (e.g. /dev/sdxy) fstab before play: UUID=780690c3-3687-439c-a61d-6a97dfaee640 /boot ext4 rw,nosuid,nodev,noexec 1 2 fstab after play: /dev/sda2 /boot ext4 rw,nosuid,nodev,noexec 1 2

Expected Behavior

Task respects source information of /etc/fstab (e.g. Source is UUID, PARTUUID or Label) or is configurable to use Label, UUID or PartUUID of disks.

OS / Environment

Tested with:

• CentOS 7.9
• Debian 12.5
• Ubuntu 20.04

Ansible Version

"ansible [core 2.15.7]
  config file = ***/ansible.cfg
  configured module search path = ['*']
  ansible python module location = /Users/***/.pyenv/versions/3.9.18/envs/***/lib/python3.9/site-packages/ansible
  ansible collection location = /Users/***/.ansible/collections:/usr/share/ansible/collections:/Users/***/workspace/git/***/***/collections_galaxy
  executable location = /Users/***/.pyenv/versions/***/bin/ansible
  python version = 3.9.18 (main, Nov 13 2023, 15:12:36) [Clang 15.0.0 (clang-1500.0.40.1)] (/Users/***/.pyenv/versions/3.9.18/envs/***/bin/python3.9)
  jinja version = 3.1.2
  libyaml = True"

Collection Version

9.0.0

Additional information

No response

[rndmh3ro]

Does it work if you override with os_mnt_boot_src UUID=780690c3-3687-439c-a61d-6a97dfaee640?

PS: Sorry for deleting the other posts, they contained infot that does not need to be public. :)

[networkhell]

Does it work if you override with os_mnt_boot_src UUID=780690c3-3687-439c-a61d-6a97dfaee640?

Yes it works with that override but I think the default behaviour is quite dangerous. Maybe it would be a safe default to use the UUID as source in any case? Or at least make it configurable. I guess a real fix would be more complicated as it would require a comparison of fstab contents and actual mounts.