Open adombeck opened 3 weeks ago
The token is stored by the broker, which is run as a confined snap, so unfortunately it lacks permissions to use systemd-creds
or the TPM. There is a TPM interface for snaps but systemd-creds
still fails to use the TPM when that interface is used:
$ echo foo | systemd-creds --with-key=tpm2 --name foo encrypt - -
Failed to create TPM2 context: Operation not supported
We could try other tools to use the TPM, or try to figure out what exactly systemd-creds
tries to do which is not supported in the snap.
An alternative would be to use the TPM in authd instead, to store a secret which we pass unencrypted to the broker via D-Bus. That secret can then be concatenated with the user password to derive the key which we encrypt the token with.
I think that fixing this in snapd is totally fine, it should support an interface that allows us to communicate with systemd-creds
. TBH, it would be nicer if systemd-creds
wouldn't access to the TPM directly, but through a system service that is exposed on the system bus, I see there's some varlink support, but I didn't go through the details of it.
Systemd credentials allow systemd services to store sensitive data in a secure way. It makes use the TPM to encrypt the credentials (if there is one).
UDENG-4057