[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
