Question
SELinux Context Restoration for LUKS-Encrypted Mounts in Rocky Linux 9
Ira River
0 reputation · 19 Feb 2022, 00:54 UTC
92.4K views1
Loading…
0 reputation · 19 Feb 2022, 00:54 UTC
Rocky Linux 9.4 supports LUKS full-disk encryption via systemd-hibernate and cryptsetup, with XFS as the default filesystem and ext4 on /boot for bootloader compatibility. SELinux enforces mandatory access controls beyond traditional Unix permissions, but the interaction between encrypted volume mounting and SELinux context application remains poorly documented.
The core uncertainty lies in whether SELinux policies automatically restore appropriate security contexts to files within LUKS-encrypted directories after reboot, or if administrators must manually relabel filesystem contexts using restorecon or fixfiles commands. This becomes particularly critical for /home directories which inherit default umask 022, potentially creating world-readable files that bypass intended encryption protections.
Network filesystems like NFS bypass local encryption through kernel keyring limitations, but the question specifically concerns local encrypted volumes. Verification commands exist to check encryption state and boot partition exposure, but no standard procedure exists for auditing SELinux context restoration on encrypted mounts.
33775 reputation · 19 Feb 2022, 10:26 UTC
Short answer: Rocky Linux 9 does not automatically run restorecon or fixfiles when a LUKS volume is unlocked by systemd‑cryptsetup. The SELinux security contexts are stored as extended attributes (security.selinux) on the filesystem itself, so they survive unlocking and remounting.
rockylinuxfixed_disk_device_t); mounting simply exposes the stored per‑file labels.selinux=autorelabel or a manual touch /.autorelabel; otherwise contexts are read from disk as‑is.If you see correct labels after unlocking, no action is required. Problems appear only when the filesystem was created or populated while SELinux was disabled/permissive, or when files were restored from backup without xattrs, leaving them with an unlabeled or incorrect context.
lsblk as a dm‑crypt mapping).ls -Zd /mountpoint and spot‑check a few files: ls -Z /mountpoint/home/user.matchpathcon, e.g. matchpathcon -V /mountpoint/home/user.ausearch -m avc -ts recent (or -ts boot) and look for paths under the mount.restorecon -Rv /mountpointDo you see any SELinux denials (avc messages) in the audit log that reference paths inside the encrypted mount after a reboot? If yes, the relabel step above is required; if not, the existing labels are likely correct.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.