[LU-16621] File and directory names are not encrypted when using secure boot Created: 06/Mar/23  Updated: 25/Apr/23  Resolved: 13/Mar/23

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: Lustre 2.16.0

Type: Bug Priority: Major
Reporter: Alex Deiter Assignee: Alex Deiter
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Related
Severity: 3
Rank (Obsolete): 9223372036854775807

 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.



 Comments   
Comment by Gerrit Updater [ 06/Mar/23 ]

"Alex Deiter <alex.deiter@gmail.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/50219
Subject: LU-16621 enc: file names encryption when using secure boot
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: fce9c54ea823022a14b6a3696e163bd27270a505

Comment by Sebastien Buisson [ 07/Mar/23 ]

Given that the problem with secure boot is that it prevents access to debugfs, patch #50219 (which is fine) will certainly not be enough to have a functional Lustre client, as there are so many other Lustre parameters handled via debugfs.

Comment by Gerrit Updater [ 13/Mar/23 ]

"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/50219/
Subject: LU-16621 enc: file names encryption when using secure boot
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 716675fff642655c4d4715654b0b4880b96139b6

Comment by Peter Jones [ 13/Mar/23 ]

Landed for 2.16

Generated at Sat Feb 10 03:28:35 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.