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