RFC: Prompting for passphrase for systemd unit #34
Comments
|
I don't know if it's helpful, but I explicitly designed |
|
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?)
|
|
|
|
@hseg Any luck with this? |
|
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.
|
|
@hseg np! |
|
@hseg Any luck with this? |
|
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: ***@***.***>
|
|
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
|
|
Thanks for the update! |
|
Hello! Any updates for this one? |
|
Sorry, I'm in the middle of exams -- I hope to be freer starting next week.
|
|
OK, so the nominally-correct way isn't working for me, but I have found a
workaround!
You want to pipe the key material into `systemd-creds --user encrypt - PRIVKEY`,
then add `systemd-creds --user decrypt KEYFILE` to the various `Exec`
commandlines:
```
[Service]
Environment="DUMP=%S/%N.dump"
ExecStartPost=-sh -c 'systemd-creds --user decrypt "$PRIVKEY" | age -d -i - | pizauth restore'
ExecStop=
ExecStop=-sh -c 'pizauth dump | age -e -r "$PUBKEY" -o "$DUMP"'
ExecStop=/usr/bin/pizauth shutdown
```
Now, if I am reading the docs correctly, this could be simplified by appending
the output of `age-keygen | systemd-creds --user encrypt --name id.key -p - -`
to the file and using `%d/id.key` as the identity file for both `age`
invocations (dropping the systemd-creds line), but I haven't managed to get this
to work. Judging by [1], this may be a known bug to be fixed in a future
version.
[1]: systemd/systemd#33318
One mistake I made in my earlier descriptions of this feature is that the
credentials are provided read-only, so this can't be used as encrypted storage,
only to securely provide key material.
|
|
I hit send on my last email a little too hastily...
I have gotten in touch with the systemd mailing list, hopefully I'll have a
better answer soon. Otherwise, I can always make a PR with the workaround,
leaving the TODO item as a fresh issue.
|
|
OK please let me know when you feel comfortable with the solution. I don't have a Linux box so I have no opinion on this, and am happy to take suggestions! |
|
I haven't tried it myself, but could https://github.com/Foxboron/age-plugin-tpm be useful for this, to achieve it in an init-independent fashion? Right now I just have my age key in |
Currently, the systemd configuration doesn't reliably load tokens on startup (confirmed for
gpg, suspected foragedue 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:
WantedByline withWantedBy=graphical-session.targetExecStartPostline as aExecReloadlineStore gpg key unencryptedgpgprivate key or its passphrase in TPM -- perhaps using the abstraction that's supposed to drop in per-user encrypted credentials systemd/systemd#30968gpg'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 implementedThe "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.
The text was updated successfully, but these errors were encountered: