[systemd-devel] How to make an encrypted disk mentioned in /etc/crypttab "optional"?

[Aleksandar Kostadinov]

Just FYI, in some situations it might be a security issue to allow
booting without decrypting  root volume (I know you're not doing for
root). Just want to point out that it shouldn't be a default feature
to skip decrypting.

An example scenario where we shouldn't allow that would be where root
disk is decrypted automatically with TPM. If attacker replaces that
volume with a non-encrypted volume and skipping decryption is allowed,
then system may boot with PCRs in  a state suitable for decrypting
other encypted volumes or extracting the original root volume
encryption key... unless user has setup decryption to depend on PCR 15
(setup with the encryption keys of already decrypted volumes) or the
boot phase as understood by systemd-stub (e.g. enter-initrd).

I hope I managed to explain.

On Wed, Oct 11, 2023 at 4:52 AM Aaron Rainbolt <arraybolt3 at gmail.com> wrote:
>
> I figured out how to do this, sorta. I ended up bypassing the
> systemd-cryptsetup mechanism entirely and instead wrote my own shell
> script and systemd unit that did things exactly the way I wanted. Now if
> the user provides the right password, their home dir is mounted, if they
> type a wrong one they're asked for their password again, and if they
> type "guest" the system boots without mounting the encrypted home dir
> and uses the ramdisk-backed one instead.
>
> In case anyone's interested, my systemd unit is:
>
> [Unit]
> Description=Mount encrypted home
> Before=display-manager.service
> [Service]
> Type=oneshot
> RemainAfterExit=true
> ExecStart=/usr/local/bin/firebook_homemount.sh
> [Install]
> WantedBy=multi-user.target
>
> And the corresponding script is:
>
> #!/bin/bash
> # Mounts an encrypted home dir (or fails gracefully)
> while true; do
>      decryptPassword="$(systemd-ask-password --no-tty "Please provide
> your user password (or type \"guest\" to enter guest mode)")"
>      if [ "${decryptPassword}" = "guest" ]; then
>          break
>      else
>          echo "${decryptPassword}" | cryptsetup luksOpen
> /dev/disk/by-label/firebook-crypt firebook-home
>          if [ "$?" = "0" ]; then
>              mount /dev/mapper/firebook-home /home
>              break
>          fi
>      fi
> done
>
> I also masked systemd-ask-password-console.service and
> systemd-ask-password-wall.service so that if the user enters a wrong
> password, they're asked for their password within Plymouth repeatedly
> (whereas originally if the user flunked their password at Plymouth,
> systemd-ask-password would default to using
> systemd-ask-password-wall.service next). This seems to be working so far.
>
> On 10/9/23 02:10, Aaron Rainbolt wrote:
> > Good morning/evening, and thanks for your time.
> >
> > I'm attempting to create a Fedora-based immutable distro (not based on
> > Silverblue) that stores user data in an encrypted /home partition. The
> > goal is to have something that behaves somewhat similar to Chrome OS.
> > One feature I'm attempting to implement is a "guest mode", whereby a
> > user can sign into the system without providing any password, but if
> > they do so they don't gain access to the system's owner's data and
> > virtually anything they do is erased upon shutdown.
> >
> > In order to do this, I have two /home directories - one is part of the
> > (immutable) root filesystem, which can only be written to thanks to a
> > Dracut-created ramdisk overlay. The other is stored in an encrypted
> > partition. I'm using a crypttab line like this to prepare the
> > encrypted partition:
> >
> >     firebook-home LABEL=firebook-crypt none luks,discard,nofail
> >
> > And I'm using an fstab line like this to mount it:
> >
> >     /dev/mapper/firebook-home /home ext4 defaults,nofail 0 0
> >
> > Note that I've marked both of these with "nofail" - the goal is that
> > the user will be prompted for their password by systemd upon boot, but
> > if they do not provide the password (by intentionally providing a
> > wrong password three times), the encrypted drive should not be mounted
> > and the system should boot normally using the ephemeral home directory
> > provided by the root filesystem + ramdisk overlay.
> >
> > This seems to be *almost* working, however if I intentionally provide
> > a wrong password to the password prompt a few times, it doesn't
> > actually "give up" on getting a password from me. What it does instead
> > is it stops asking me for the password at boot, but then rather than
> > starting GNOME it just leaves me at a console screen. If I am able to
> > get GDM to appear somehow, I can't sign in.
> >
> > What I end up doing is switching to a TTY, signing in, and then
> > elevating to root to troubleshoot. Once I've elevated to root, I get a
> > `wall` message informing me that the system is *still waiting* for a
> > password and that I need to run `systemd-tty-ask-password-agent` (I
> > think?) to provide it. If I go ahead and do this, then restart GDM,
> > I'm able to sign in after that. (I could be wrong about what command
> > it's asking me to run, but I think it was
> > `systemd-tty-ask-password-agent`.)
> >
> > From my research, it looks like systemd is refusing to ever truly
> > "give up" on getting the password for the encrypted /home directory,
> > despite the use of `nofail` in the fstab and crypttab files. I'm not
> > finding any documentation on how to get systemd to "give up" on
> > getting the password. For my particular use case, I'd like systemd to
> > just forget that the encrypted drive exists at all if the wrong
> > password is given. If the user wants to mount the encrypted drive
> > after that, they should either reboot or use cryptsetup manually.
> >
> > Is there any way to make systemd "give up" on getting a password?
> >
> > Thanks for your help!
> >
> > Aaron
> >
>