[LU-16621] File and directory names are not encrypted when using secure boot

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: Lustre 2.16.0
• Severity: 3
• Assignee: Alex Deiter
• Reporter: Alex Deiter

Description

File and directory names are not encrypted when using secure boot

Steps to reproduce

• Enable encryption for file and directory names
• Create a test directory on top of the Lustre filesystem and enable encryption for this directory
• Copy some files to the test directory
• Lock the encrypted directory
• Try to access the encrypted directory and check the content and file names

  mgs# lctl set_param -P llite.*.enable_filename_encryption=1
  ...
  client% sudo fscrypt setup
  client% sudo fscrypt setup /mnt/lustre
  client% sudo install -v -d -m 0777 -o stack -g stack /mnt/lustre/test
  client% fscrypt encrypt /mnt/lustre/test
  client% cp /etc/passwd /mnt/lustre/test
  client% fscrypt lock /mnt/lustre/test
  client% ls -l /mnt/lustre/test
  client% md5sum /mnt/lustre/test/*
  

Expected results

• The content of the files are encrypted and unavailable until the test directory is locked
• The original file and directory names are encrypted and not not visible

Expected output

+ fscrypt encrypt /mnt/lustre/test
...
"/mnt/lustre/test" is now encrypted, unlocked, and ready for use.
+ cp /etc/passwd /mnt/lustre/test
+ fscrypt lock /mnt/lustre/test
"/mnt/lustre/test" is now locked.
+ ls -l /mnt/lustre/test
-rw-r--r--. 1 stack stack 4096 Feb 17 15:53 iY5cBB+f8Olgcy3H,nCarFqOaTmZuOxEZby9hOSMfBG
+ md5sum /mnt/lustre/test/iY5cBB+f8Olgcy3H,nCarFqOaTmZuOxEZby9hOSMfBG
md5sum: /mnt/lustre/test/iY5cBB+f8Olgcy3H,nCarFqOaTmZuOxEZby9hOSMfBG: Required key not available

Actual results

• The content of the files are encrypted and unavailable until the test directory is locked
• The original file and directory names are unencrypted and visible

Actual output

...
+ fscrypt encrypt /mnt/lustre/test
...
"/mnt/lustre/test" is now encrypted, unlocked, and ready for use.
+ cp /etc/passwd /mnt/lustre/test
+ fscrypt lock /mnt/lustre/test
"/mnt/lustre/test" is now locked.
+ ls -l /mnt/lustre/test
-rw-r--r--. 1 stack stack 4096 Feb 17 15:51 passwd
+ md5sum /mnt/lustre/test/passwd
md5sum: /mnt/lustre/test/passwd: Required key not available

Compatibility and portability

The same issue can be reproduced on the Ubuntu 22.04 client(s) with kernel version 5.15.0 when Secure Boot is enabled

Workaround

If we just disable secure boot, then encryption of directory and file names works as expected

Root cause

Secure Boot is a verification mechanism for ensuring that code launched by a computer's UEFI firmware is trusted. It is designed to protect a system against malicious code being loaded and executed early in the boot process, before the operating system has been loaded.

Secure Boot works using cryptographic checksums and signatures. Each program that is loaded by the firmware includes a signature and a checksum, and before allowing execution the firmware will verify that the program is trusted by validating the checksum and the signature. When Secure Boot is enabled on a system, any attempt to execute an untrusted program will not be allowed. This stops unexpected / unauthorised code from running in the UEFI environment.

By its very design, Secure Boot may affect or limit some things that users want to do.
For example, activates lockdown mode in the Linux kernel (references: Kernel lockdown for secure boot and debugfs: Restrict debugfs when the kernel is locked down). When lockdown is in effect, a number of features are disabled or have their use restricted. This includes special device files and kernel services that allow direct access of the kernel image:

• /dev/mem
• /dev/kmem
• /dev/kcore
• /dev/ioports
• BPF
• kprobes

And the ability to directly configure and control devices, so as to prevent the use of a device to access or modify a kernel image:

• The use of module parameters that directly specify hardware parameters to drivers through the kernel command line or when loading a module
• The use of direct PCI BAR access
• The use of the ioperm and iopl instructions on x86 arch
• The use of the KD*IO console ioctls
• The use of the TIOCSSERIAL serial ioctl
• The alteration of MSR registers on x86 arch
• The replacement of the PCMCIA CIS
• The overriding of ACPI tables
• The use of ACPI error injection
• The specification of the ACPI RDSP address
• The use of ACPI custom methods

Certain facilities are restricted:

• Only validly signed modules may be loaded (waived if the module file being loaded is vouched for by IMA appraisal)
• Only validly signed binaries may be kexec'd (waived if the binary image file to be executed is vouched for by IMA appraisal)
• Unencrypted hibernation/suspend to swap are disallowed as the kernel image is saved to a medium that can then be accessed
• Use of debugfs is not permitted as this allows a whole range of actions including direct configuration of, access to and driving of hardware
• IMA requires the addition of the "secure_boot" rules to the policy, whether or not they are specified on the command line, for both the built-in and custom policies in secure boot lockdown mode

The most important restrictions for us:

• Only validly signed modules may be loaded
• Only validly signed binaries may be kexec'd
• Use of debugfs is not permitted

Lustre filesystem and llite (client VFS interface) actively uses the debugfs subsystem and registers many access points there.