Poldi

NIIBE Yutaka gniibe at fsij.org
Wed Nov 16 03:25:01 CET 2016


Hello,

I am a maintainer of Debian Poldi package.  I did package it up, so
that people can stop complaining that it is too difficult to build.  I
do that to share the work of building the software.

Although I occasionally push some changes to upstream (to keep it
working), I don't want to put my energy to maintain the upstream.

It is somewhat difficult for me to say I'm working for Poldi, as I am
not that positive for this software.  Please understand this unclear
situation of mine.

Basically, I can't imagine useful/effective use cases of PAM
authentication by Poldi with OpenPGP card, while I noticed possible
misuses and possible weakness of the implementation.


Having said that, I recently pushed some changes to Poldi.  That's
mainly because GnuPG 2.1 deprecated use of the environment variable
GPG_AGENT_INFO.

I added following entries in poldi/NEWS file.

==============================================================
Changes since version 0.4.1:

* poldi-ctrl is removed
  Please use gpg-connect-agent instead.

* For backward compatibility of sudo and screen unlock
  In GnuPG 2.1, the environment variable GPG_AGENT_INFO is gone.  And
  now, Poldi's default is invoking scdaemon directly.  Still, there
  are use cases (like sudo and screen unlock) which expect connecting
  user's gpg-agent.  For this purpose, Poldi now distinguishes a case
  where pam_username == username_of_process_uid.  Only for such a case,
  Poldi tries to find scdaemon under gpg-agent.

* Poldi invokes scdaemon to connect it through pipe
  Older Poldi has a feature of connecting to scdaemon with help of
  gpg-agent using the GPG_AGENT_INFO enviornment variable.  In GnuPG
  2.1, the environment variable GPG_AGENT_INFO is gone and scdaemon no
  longer keeps locking the reader after card removal, it is good to
  always invoke scdaemon for the authentication by default.  If there
  is an existing scdaemon with card inserted, a failure is expected
  and this is safer fallback.  That's because Poldi should not connect
  to a smartcard which is in use for other purpose and possibly
  already authenticated.
==============================================================


I got a report that my change breaks a use case:

   * In the system, Poldi is configured for su.  A public key of auth
     key is registered in /etc/poldi/localdb for "root".

     That is, the system allows use of "su" service to the holder of
     the auth private key.

   * A user has an OpenPGP card with signing key, decryption key and
     auth key.

   * The card is in use by gpg-agent for a user for signing/decryption.

   * When typing "su -" to become superuser, it is the intention of
     the user to use the auth key in the card.


I don't know how/if Poldi can support this use case correctly.  It's
too difficult to solve for me.  I need your help.

(If I were the user and the admin of the system, I'd configure sudo
for Poldi and use "sudo -i".)


I think that it's not good in general for Poldi to connect to existing
scdaemon;  The scdaemon could be malicious one to steal other persons
PIN (if it's shared computer).
-- 



More information about the Gnupg-devel mailing list