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

[Aaron Rainbolt]

On 10/11/23 04:40, Aleksandar Kostadinov wrote:
> 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.

I think I get what you're saying (I'm not too familiar with how TPMs 
work). Thanks for the info! I believe allowing decryption skipping is 
safe for my particular use case (the only acceptable form of encryption 
key is a password, and attacks involving modification of the unencrypted 
software on the disk are beyond what I want to protect from). But I can 
see how it could be a security issue in other situations, so it makes 
sense why systemd would require extra work to allow that sort of thing.

> 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
>>>