disk/cryptodisk: Require authentication after TPM unlock for CLI access

The GRUB may use TPM to verify the integrity of boot components and the
result can determine whether a previously sealed key can be released. If
everything checks out, showing nothing has been tampered with, the key
is released and GRUB unlocks the encrypted root partition for the next
stage of booting.

However, the liberal Command Line Interface (CLI) can be misused by
anyone in this case to access files in the encrypted partition one way
or another. Despite efforts to keep the CLI secure by preventing utility
command output from leaking file content, many techniques in the wild
could still be used to exploit the CLI, enabling attacks or learning
methods to attack. It's nearly impossible to account for all scenarios
where a hack could be applied.

Therefore, to mitigate potential misuse of the CLI after the root device
has been successfully unlocked via TPM, the user should be required to
authenticate using the LUKS password. This added layer of security
ensures that only authorized users can access the CLI reducing the risk
of exploitation or unauthorized access to the encrypted partition.

Fixes: CVE-2024-49504

Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

docs/grub.texi

@@ -9119,6 +9119,36 @@ command through the swtpm control channel.
 # @kbd{swtpm_ioctl -s --unix swtpm-state/ctrl}
 @end example
 
+@subsection Command line and menuentry editor protection
+
+The TPM key protector provides full disk encryption support on servers or
+virtual machine images, meanwhile keeping the boot process unattended. This
+prevents service disruptions by eliminating the need for manual password input
+during startup, improving system uptime and continuity. It is achieved by TPM,
+which verifies the integrity of boot components by checking cryptographic
+hashes against securely stored values, to confirm the disks are unlocked in a
+trusted state.
+
+However, for users to access the system interactively, some form of
+authentication is still required, as the disks are not unlocked by an
+authorized user. This raised concerns about using an unprotected
+@samp{command-line interface} (@pxref{Command-line interface}), as anyone could
+execute commands to access decrypted data. To address this issue, the LUKS
+password is used to ensure that only authorized users are granted access to the
+interface. Additionally, the @samp{menu entry editor} (@pxref{Menu entry
+editor}) is also safeguarded by the LUKS password, as modifying a boot entry is
+effectively the same as altering the @file{grub.cfg} file read from encrypted
+files.
+
+It is worth mentioning that the built-in password support, as described in
+@samp{Authentication and Authorization in GRUB} (@pxref{Authentication and
+authorisation}), can also be used to protect the command-line interface from
+unauthorized access. However, it is not recommended to rely on this approach as
+it is an optional step. Setting it up requires additional manual intervention,
+which increases the risk of password leakage during the process. Moreover, the
+superuser list must be well maintained, and the password used cannot be
+synchronized with LUKS key rotation.
+
 @node Platform limitations
 @chapter Platform limitations