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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users