ship systemd unit that sets keys from file

[ibotty]

I propose shipping and documenting the following unit that sets a key in /etc/stratisd/<pool>.key.

#/etc/systemd/system/stratisd-key@.service
[Unit]
Description = stratis set key from file
After = stratisd.service

[Service]
ExecStart=/usr/bin/stratis key set --keyfile-path /etc/stratisd/%i.key %i
RemainAfterExit=yes

[Install]
WantedBy = multi-user.target

[mulkieran]

@ibotty Could you be as specific as possible about your intended use case? thx!

[ibotty]

Sure. I'd like to mount an encrypted stratis volume on system startup. The key should reside on the (already non-stratis, luks-encrypted) root file system. The volume is mounted via /etc/fstab.

[mulkieran]

Migrating to project

[mulkieran]

@jbaublitz, @dkeefe: Could you comment? My first thought is that such a file would be too user-specfic for Stratis to ship unconditionally.

[jbaublitz]

If we're going to package anything, I'd much prefer packaging a service file that prompts the user for a passphrase through a general system mechanism like zenity or systemd-ask-password. The problem with shipping this configuration file is that we make no recommendations about how to store keyfiles. It is up to the user to determine their own threat model and whether their keyfile location and permissions satisfy that threat model. I'd be very hesitant to ship something like this for that reason and also the concern @mulkieran brought up about it being too specific. Anything that we ship will likely be seen as the default or recommended way to set things up and I don't see this as being something that applies to enough users to be a good default for most users.

[mulkieran]

@jbaublitz That makes sense to me. @ibotty If there is some more general solution that would also be useful to you, please let us know.

[ibotty]

That systemd unit is in a way a logical successor to having stratis key set --keyfile-path. Shipping it with stratis will ensure that at least only root can read the key, when also shipping /etc/stratis with suitable permissions.

It also makes it easier to start with stratis encryption. See how much easier https://fedoramagazine.org/getting-started-with-stratis-encryption/ could become with said unit: no strange systemd unit with key-setting, sleeps and mounting in one single-use unit. It could just say systemctl enable --now stratisd-key@pool1key and tell them to add the mount path to /etc/fstab as usual.

Honestly, I didn't think of users not realizing that when storing the key on disk, the password is only as safe as the disk. That has to be addressed prominently, of course. I don't think not including useful features is the way to go though.

I'd argue that there are many use cases where it makes sense to store the key on disk.

• The root fs is already encrypted,
• The root fs is immobile(-ish), the stratis-encrypted device is mobile.

This unit does not readily address the usecase, that a user has a usb-stick on their keychain holding the key for the stratis pool. That would work with that unit and symlinks, but I don't know whether I would support that usecase 🙃.

Having said that, I am not opposed at all against asking users for their password. I don't know how to achieve that with a systemd unit alone though, because stratis key set will have to be run by root (afaict) and the program asking for the password will want to run as $USER.

[jbaublitz]

@ibotty I still maintain that this unit file is not generic enough. We may eventually, for example, bump into a setup where the root filesystem is unencrypted and the assumption of this unit file is that it's always encrypted to safely use it. We have not explicitly stated that that is a requirement anywhere in our documentation so I'm not personally willing to make that a restriction for using our unit file without explicitly stating it, and it seems like a somewhat arbitrary restriction just for a unit file that we ship. If you have had success with the unit file you proposed, I absolutely encourage you to use it as it seems to work for your use case, but we have to consider all potential use cases before merging something into our code base.

I am still interested in working with you on a service file that we can definitely merge to prompt users for their passphrase. I'm going to do a little bit more research into this. systemd-ask-password does not need to be run as $USER and actually requires elevated permissions so let me do a bit more digging into this and see if I can propose something that would work for you. How does that sound?

[jbaublitz]

@mulkieran I have a suggestion that ties into stratisd-min for how we can potentially deal with the D-Bus/fstab-generator ordering problem. I'll update you in stand up.

[ibotty]

Oh, I did not know about systemd-ask-password. That might, indeed, work for asking the user for the password. I will play around with it.

That is not what I will need in any case though. I'd like to mount a stratis volume without any user interaction.

Maybe the unit should be named accordingly: stratis-set-key-from-filesystem@.service? There can't be one systemd unit that asks for the password and reads a password from file anyway. My naming choice would have been: stratis-key@ and stratis-ask-key@, but I am totally open to anything.

[ibotty]

Reading systemd-ask-password, is it possible for stratis to read the password directly from the kernel keyring, so that systemd-ask-password can put it into the right spot. Quoting its manpage:

--keyname=
  Configure a kernel keyring key name to use as cache for the password.
  If set, then the tool will try to push any collected passwords into
  the kernel keyring of the root user, as a key of the specified name.

[johnsimcall]

I'd like to mount a stratis volume without any user interaction.

Seems very timely that the new Stratis 2.3.0 release supports Clevis/Tang. I have a tang server deployed in my network which allows me to unlock and mount my volumes automatically.

I typically use Cockpit to establish the Clevis/Tang binding, but I would recommend trying the new Stratis features too! Here's a short video that highlights it's simplicity.