Date: Mon, 18 Dec 2017 16:21:36 -0500 From: Daniel Kahn Gillmor <dkg@...thhorseman.net> To: halfdog <me@...fdog.net>, oss-security@...ts.openwall.com Subject: Re: Recommendations GnuPG-2 replacement On Mon 2017-12-18 20:21:56 +0000, halfdog wrote: > The features you describe are a clear must for desktop/enduser > usecases, that require frequent access to the key. It is clear > to me, that those features are required, no discussion to this > point. > > The point in starting this thread was, that GnuPG does NOT conveniently > cover usecases for headless or scripting operation. Thus it seems > that the time has come to look for replacement, as GnuPG is moving > more in the "desktop" direction, as also your comments indicate. I find that gpg works fine in a headless operation, but it does so mainly without a password. If your headless operation has access to the secret key and the password, that's basically equivalent, afaict, so it's not clear to me what benefit password protection gives you. If you don't want to deal with pinentry, how do you propose protecting the secret key material? I'm not asking this to be contrary -- i'm trying to understand your threat model. Why do you need a passphrase for your secret key that you use in headless/scripting operation? and what security benefit do you expect to gain from it? > That's really a strange argument. You fear PTRACING for key extraction > of a short-lived, per-key instance of gpg1 process and solve that > by putting all the key material into a single long-lived gpg-agent > process, not even providing convenient commands to flush the keys > from there? Hence not even PTRACING is needed, you can just access > the socket to make the process give you the keys (directly or > by requesting decrypts/signatures - I did not check on that). You should look into gpg-agent's restricted socket. i believe it's intended to provide very similar constraints to what you're looking for. > Even with namespaces, PTRACE is still allowed unless you are running > the agent as SUID-binary, causing other risks again. fwiw, gpg-agent upstream provides no ptrace protection, but in debian we have a minor defense-in-depth patch applied: https://anonscm.debian.org/git/pkg-gnupg/gnupg2.git/tree/debian/patches/block-ptrace-on-secret-daemons/Avoid-simple-memory-dumps-via-ptrace.patch I welcome any suggested improvements on these changes, even if upstream isn't willing to apply them directly. > In my opinion, for server operation both schemes would not improve > security the same way as on desktops: if the automated tasks is > implemented to be run as root, PTRACE and namespaces do not help in > any way. sure, but maybe we can acknowledge that automated tasks running as root are already in a pretty dangerous position? I'm not aware of any of the solutions offered in this thread as a "replacement for GnuPG-2" other than hardware tokens themselves that provide any real resistence to an automated task running as root on the machine in question. > If run as distinct user, there are only two usecases: > > * The service just does encryption/signature verification: here > the unavoidable agent just provides additional attack surface, > e.g. by replacing verification keys in the agent only, thus > everything looks nice on disk but your signature verification > is broken. eh? the agent does not handle verification keys (i.e. public keys) -- it only handles private keys. if the service in question only does public key operation, then the agent is irrelevant. > * The service does signing/decryption: the key is passwordless > (or password is within user-readable configuration) or HW-token. > In both cases, the initial security of the key material before > being transfered to gpg-agent only depends on file system level > access restrictions. Gaining access to UID or PTRACE is already > equivalent to full key material compromise. So also here the > agent only adds attack surface and that's it. I agree with you that the safest case would be to isolate the secret key material in a different UID and filesystem namespace. If the agent is running as a dedicated user account, and accessed by a different user account talking specifically to its restricted socket, then access to UID is not a given, and PTRACE isn't possible. This kind of privilege isolation is (i think) what you're looking for, and it is *only* possible with the agent (or some similar architecture). While this is not a common deployment of gpg-agent today, and it might have bugs in it for current deployment, it seems you're arguing *for* using an agent, rather than against it. If you try this particular use case, i'd be happy to help you iron out any bugs to make sure it's safe to use this way. > To reduce the attack surface, a "gpg --one-shot" argument could > be added, which will terminate the agent immediately after use, > maybe not even exposing it via sockets visible to other processes > but only connected to its "parent" gpg process via pipes. this approach would lose the benefit of long-running processes that you can get from things like dirmngr, and it would fail in the event that your agent was acting across a privilege boundary (you'd have to launch a constrained agent somehow). wouldn't it be better to improve on the user-isolated processes instead? that said, i do agree that having an anonymous socketpair()-connected agent that lives and dies with the parent process would be a nice option -- but each option incurs a support burden, and i am not sure that the burden is worth the tradeoff when it is compared with the other isolate-and-constrain-the-agent proposals, so i'm more likely to work on the latter myself. All the best, --dkg Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ