Open hseg opened 6 months ago
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!
Currently, the systemd configuration doesn't reliably load tokens on startup (confirmed for
gpg
, suspected forage
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:
WantedBy
line withWantedBy=graphical-session.target
ExecStartPost
line as aExecReload
lineStore gpg key unencryptedgpg
private key or its passphrase in TPM -- perhaps using the abstraction that's supposed to drop in https://github.com/systemd/systemd/pull/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.