RFC: Prompting for passphrase for systemd unit

[hseg]

Currently, the systemd configuration doesn't reliably load tokens on startup (confirmed for gpg, suspected for age due to similar semantics).
This is due to the fact that the decryption command needs to prompt for a passphrase, which under the current setup only works with a graphical session (to create a passphrase prompt popup).
Thus, for setups where the user logs into a non-graphical session, if X isn't started quickly enough the prompt attempt will fail (thankfully, this will not prevent pizauth from starting -- the configuration is set to ignore failures at this step). This situation is less than desirable.

Five solutions suggest themselves:

• Find out how to get prompting to work in a non-graphical context, and write the configuration so as to fall back to that if necessary
• Only start the service in a graphical context -- involves replacing the WantedBy line with WantedBy=graphical-session.target
• Have reloading the service also retry restoring tokens -- involves duplicating the ExecStartPost line as a ExecReload line
• Store gpg key unencrypted
• Store gpg private key or its passphrase in TPM -- perhaps using the abstraction that's supposed to drop in per-user encrypted credentials systemd/systemd#30968
• Use gpg's native TPM support -- note: don't know how this one works, incidentally discovered while working out how the other TPM option would need to be implemented

The "modify the configuration" options are less than appealing -- they don't quite match the semantics, and are a bit of a hack. Still, they work (indeed, they're what I'm using right now in the absence of understanding/possibility of the other options).

The above is meant as a brain-dump of my current understanding of the design space, don't yet know what to advocate for.

[ltratt]

I don't know if it's helpful, but I explicitly designed restore to support unexpected ways of getting data into pizauth https://tratt.net/laurie/blog/2023/pizauth_dump_restore.html.

[hseg]

On Thu, Jan 25, 2024 at 03:43:48AM -0800, Laurence Tratt wrote: I don't know if it's helpful, but I explicitly designed `restore` to support unexpected ways of getting data into pizauth https://tratt.net/laurie/blog/2023/pizauth_dump_restore.html.

Right, and this flexibility is much appreciated. Does this mean that as far as pizauth's semantics are concerned, restoring upon each reload is sensible? If so, we could go with that option, at least until I figure out how to either units to prompt for passphrases, or until we're able to do fully-automatic encryption. In the direction of prompting for passphrases, just stumbled on `systemd-ask-password`, which looks promising, but which I don't have the time to test ATM. (although I have doubts that it'd work -- if it did, why doesn't gpg prompt when I log into a console session?)

[ltratt]

restore is designed to be called as often as you want: it will ignore any problematic data (e.g. that based on a different config) and slurp in what it can. [There are some minor caveats mentioned in the man page due to clock drift. At worst these can cause token refreshing a bit early or late, but it won't compromise security.]

[ltratt]

@hseg Any luck with this?

[hseg]

On Fri, Feb 02, 2024 at 09:42:06AM -0800, Laurence Tratt wrote: @hseg Any luck with this?

Snowed in with homework, probably won't be able to touch this for the next while. Will be freer once semester break hits in mid-March, hope to find cycles for this before then though. Sorry for not notifying.

[ltratt]

@hseg np!

[ltratt]

@hseg Any luck with this?

[hseg]

It dropped off my radar, sorry. Will schedule some time for this this weekend, see what I can dig up. El 26 de mayo de 2024 19:15:13 GMT+03:00, Laurence Tratt ***@***.***> escribió:

…

@hseg Any luck with this? -- Reply to this email directly or view it on GitHub: #34 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[hseg]

OK, so the systemd feature I was hoping for[1] just dropped last Tuesday, so once it gets packaged for Arch Linux I can play around with it (briefly, the idea would be to have systemd encrypt/decrypt the dump file using a per-user keypair stored in TPM), hopefully I can have something for you Soon(TM). I've tried getting `gpg`'s TPM support to work so I could also offer something for older setups, but have been having no luck -- I've not managed to make heads or tails of the limited available documentation. (BTW, `age` also can use TPM[2] if you're interested in that) So far, the issue has been mitigated for me by the fact that my backup configuration polls me for my password every half hour or so, so I haven't run into this issue again recently -- though that doesn't mean the underlying issue is solved. Will keep you posted if I manage to make some progress, thanks for your patience! [1]: systemd/systemd#30968 [2]: https://github.com/Foxboron/age-plugin-tpm

[ltratt]

Thanks for the update!