[PATCH] Add inside-Emacs mode to GUI pinentry programs

[Daiki Ueno]

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> however, doing this seems like it might open up a possible hole in the
> protections offered by the agent, so i think we need to proceed
> thoughtfully.  If the requester can instruct the agent to talk to
> arbitrary emacs sessions, then an attacker with access to the agent's
> socket can potentially do things like mount password-guessing attacks
> without any visibility to the user.

Thanks for bringing it up.  I think Emacs is secure enough nowadays to
such kind of attacks, i.e., it properly sets up the permission of the
parent directory of a socket, and the client does some checks of the
file owner.  However, we should double-check if it is secure enough for
this use-case, indeed.

By the way, is the envvar restriction really working?  I was curious how
pinentry-gnome3 works without knowing the address of the D-Bus session
bus, since gcr internally uses it to talk to the actual prompter service
implementation (i.e., gnome-shell).

So just tried:

  $ pkill gpg-agent
  $ gpg2 --symmetric -o /dev/null < /dev/null
  ...works ok...

  $ pkill gpg-agent
  $ DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/invalid \
    gpg2 --symmetric -o /dev/null < /dev/null
  gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
  gpg: It is only intended for test purposes and should NOT be
  gpg: used in a production environment or with production keys!
  gpg: cancelled by user
  gpg: error creating passphrase: Operation cancelled
  gpg: symmetric encryption of '[stdin]' failed: Operation cancelled

I don't see the envvar listed in common/session-env.c, but it seems to
be actually passed to pinentry-gnome3:

  $ DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/invalid \
    strace -e trace=connect -f gpg2 --symmetric -o /dev/null < /dev/null
  ...
  25983 connect(5, {sa_family=AF_LOCAL, sun_path="/tmp/invalid"}, 110) = -1 ENOENT (No such file or directory)
  ...

Perhaps libassuan/src/system-posix.c:__assuan_spawn should use execve,
instead of execv?

Regards,
-- 
Daiki Ueno