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

Related — Tue, 25 Apr 2023 03:58:18 +0000

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.

Whamcloud Community JIRA