pizauth

pizauth copied to clipboard

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 https://github.com/systemd/systemd/pull/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.

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.

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?)

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.]

@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: https://github.com/ltratt/pizauth/issues/34#issuecomment-2132274665 You are receiving this because you were mentioned.

Message ID: @.***>

OK, so the systemd feature I was hoping for1 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 TPM2 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!

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.

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!