Confirmation for cached passphrases useful?

[Daniel Kahn Gillmor]

On 10/12/2010 12:34 AM, Robert J. Hansen wrote:
> Heck, this doesn't even defend against an *unprivileged* attack.  Give
> me unprivileged access to your user account I'll edit your .profile to
> put a .malware/ subdirectory on your PATH and drop my trojaned GnuPG in
> there.  Once the malware executes, delete the hidden subdirectory,
> restore your original PATH, and send the passphrase it intercepted off
> towards my C4I server.

yes, of course this isn't going to be able to protect the user from
someone with full access to their user account or their current session.

Agents like gnupg-agent and other socket-driven services are capable of
being exported over heavily-constrained connections, where only access
to the agent's socket is given to the attacker.  For example, you can
forward ssh-agent over the network to a process on a remote host, or set
up a simple socket-forwarding service within a machine to grant access
to your gnupg-agent to other user accounts.

As an example, I know people who run their web browser in a
heavily-constrained mode, e.g. under a separate user account, in a
virtual machine or VNC session.  If such a browser (or a plugin to it)
wants access to the principal user's agent, it has only one recourse,
which is to talk to the agent's socket.  (This sort of constraint is
much more effective with the ssh-agent model, where secret key material
never leaves the agent, as opposed to the traditional gpg-agent model
where the agent is only a passphrase cache; it sounds like gpg-agent is
planning to adopt the ssh-agent model as of 2.1, which is great news.)

> And if we're assuming I've instead subverted an unprivileged non-user
> account (like a jailed service), then this "attack" is a nonissue, so
> why are we trying to solve it?

If the specialized/jailed account has access to such a forwarded agent,
then an attack against it *is* an issue.  It would be good to be able to
grant gpg-agent access to the constrained service when it requests it
reasonably, and to be able to deny it when it requests access unreasonably.

> This seems like an niche solution to a problem which, as of right now,
> is nonexistent.

Conversely, people won't run well-isolated subsystems if the tools we
provide don't support reasonable separation and control in the first
place.  Do we want to build tools that support secure use?  If so,
implementing Hauke's suggestion at least in the GPG 2.1 branch is a good
idea.  And previous branches would be nice too, though the classic
gpg-agent communication model (passphrase-cache-only) is too weak for
the proposed confirmation prompt to enable well-isolated use.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20101012/637e62d4/attachment.pgp>