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/[email protected]
[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: [email protected]? 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.

[ibotty]

Well, that's one more way to decrypt. But, say, I don't have any other trusted devices in this network. I don't think my use case is handled by that. I appreciate stratis supporting clevis/tang though. I'd really like to try it out in an enterprise environment!

Anyway, back to the point:
Would it be it ok to ship two systemd units, appropriately named, one reading the key from local fs, the other asking the user?

[jbaublitz]

@ibotty You could use a TPM with our Clevis implementation so that is an option still. However, I'm happy to keep discussing an alternate unit file both for prompting the user and using a keyfile. If we do end up adding a keyfile service file, I'm going to request that somehow, the absolute path is encoded in the argument after the @. That way, we are making no recommendations about where people store their keyfiles and it is generic enough to cover all paths.

[ibotty]

The problem with having an absolute path is that right now the unit file (above) uses the convention that %i (the part after @) is part of the file name as well as the keydesc. (in terminology of the -h or key_desc in the manpage. Why is that different btw?)

I don't know how to implement that. I will note though, that using an absolute path is not possible with above unit, but using a path somewhere else is indeed possible with a symbolic link.

[jbaublitz]

I need to discuss this with the team, but I think it's unlikely that we'll include something that hard codes a path. Again, if this is something that is useful for your workflow, I encourage you to use it for your workflow independently of what we include in our main repo.

in terminology of the -h or key_desc in the manpage. Why is that different btw?

I'm not entirely sure what you mean by this, but it appears the --key-desc parameter is represented correctly in both the help text and the man page.

[ibotty]

in terminology of the -h or key_desc in the manpage. Why is that different btw?
I'm not entirely sure what you mean by this, but it appears the --key-desc parameter is represented correctly in both the help text and the man page.

from the manpage:

   key set <(--keyfile-path <path> | --capture-key)> <key_desc>

from -h

usage: stratis key set [-h] (--keyfile-path KEYFILE_PATH | --capture-key) keydesc

But that's only very minor.

Regarding the main point. Of course I can keep using it. I do think that having a robust unit in proper is favorable, but if you disagree, I'm ok with that as well.

[jbaublitz]

We may be able to augment the systemd generators to handle the root filesystem case with a kernel command line parameter like stratis.rootfs.keyfile. Non-root filesystem handling in /etc/fstab may not be able to be generalized but I'll do some more investigation.

[mulkieran]

Dropping this from any particular project at this tim.e