[Pkg-gnupg-maint] Bug#367058: problems with misconfigured gnupg-agent and /etc/X11/Xsession.d/90gpg-agent

[Daniel Kahn Gillmor]

Reviewing bugs in GnuPG packages, i'm a little worried about
https://bugs.debian.org/367058 -- it hasn't been resolved in years, and
it's pretty simple:

On a machine that uses the standard X11 session startup scripts in
/etc/X11/Xsession.d (this is chosen by
/etc/alternatives/x-session-manager, i think, and does not include
gnome-session, but does include openbox-session), a user can lock
themselves out of X11 entirely with the following changes to their home
directory:

 echo use-agent >> ~/.gnupg/gpg.conf
 echo no-such-option >> ~/.gnupg/gpg-agent.conf



I just tried this on a debian unstable system with gdm3 as the display
manager and x-session-manager pointing to openbox-session.

I think the general principle should be that if gpg-agent can't parse
its config file correctly, or has other errors, we should start up the
command anyway, but with no gpg-agent running.

The trick is how to do that safely.

-------


Background
----------

gpg-agent is a cache of cryptographic credentials (keys and passwords)
to make life easier for end-users, and to limit access to the
credentials.

Users will typically want one gpg-agent instance to run one per active
session.  This means these are all goals:

 a) no sharing gpg-agent across sessions

 b) avoid running more than one gpg-agent in a single session

 c) when the session terminates, gpg-agent should also terminate


gpg-agent has four main ways to communicate how it is set up to the
processes in a single session:

 0) environment variables: $GPG_AGENT_INFO contains a path to an
    arbitrary unix-domain socket and a process ID.  You can run
    "gpg-agent --daemon", it will print out a setting for this env var,
    and you can manually export it.

 1) ~/.gnupg/.gpg-agent-info-$(hostname) -- this contains a bourne shell
    snippet that can be used to set the environment variables as
    described above.

 2) the "standard socket" (~/.gnupg/S.gpg-agent), without any
    out-of-band communication, processes just try this socket.

 3) chained process execution -- if i launch "gpg-agent --daemon bash",
    then gpg-agent itself launches bash with the appropriate environment
    variables set, and when bash terminates, gpg-agent terminates.


mechanism (0) on its own is troubling, because it seems likely to fail
goal (b) -- two different processes could launch their own agent at
different times within a session with no clear way to coordinate it.

mechanisms (1) and (2) can succeed at goal (b) (possibly with a tiny
race condition) by using the filesystem to coordinate between processes
that share a session (though they might run into trouble with goal (a)
if the same homedir is mounted on multiple machines via e.g. NFS, or if
two sessions for a given user are started on the same machine).

But mechanisms (0), (1), and (2) all fail goal (c) -- they have no way
of knowing when it's time to quit.

usage (3) is what's going on in /etc/X11/Xsession.d/90gpg-agent, and
it's the only approach that solves goal (c).

But usage (3) ends up being extremely brittle, as #367058 indicates.

I'm tempted to punt on goal (c) entirely, and say that this sort of
cleanup is the job of the session manager, not of the daemon.  For
example, systemd user sessions should make that kind of cleanup easy.  I
guess we have to think through what that would mean for (for example)
remote ssh sessions that invoke the agent, though.


As for how to get the gpg-agent auto-launched cleanly and uniquely per
session, i don't really care if it's approach (1) or (2) or some default
launch-as-needed policy from upstream, or even a dbus-triggered service
launched from a systemd user session.

What do folks think makes sense in terms of how to solve this in debian?

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20140926/6475729b/attachment-0003.sig>