[Bug 1663] Allow to use agent for distribution of public keys.

bugzilla-daemon at bugzilla.mindrot.org bugzilla-daemon at bugzilla.mindrot.org
Sun Jul 4 11:00:24 EST 2010


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

           What    |Removed                     |Added
   Attachment #1811|0                           |1
        is obsolete|                            |

--- Comment #13 from Daniel Kahn Gillmor <dkg at fifthhorseman.net>  ---
Created attachment 1895
  --> https://bugzilla.mindrot.org/attachment.cgi?id=1895
updated pubkey-agent patch against 5.5p1 (with security fixes)

The Monkeysphere development team is interested in seeing this modular
key-based authorization functionality included in OpenSSH.  We believe
the LDAP-specific code should be distributed separately.  We reviewed
the pubkey-agent patch today, and found a handful of problems that
appear to need fixing.  The attached patch applies against 5.5p1, and
resolves the immediate problems.

The concerns we found were:

 0) not all components of the path to the command were checked for
proper ownership and permissions.

 1) using popen() while under temporarily_use_uid() meant that a child
process could re-elevate its privileges to root with seteuid().

 2) the combination of strtok, percent expansion, and the implicit sh
-c invocation (via popen()) leave open a number of possibilities to
violate the principle of least surprise for an unfortunate sysadmin.

Our revised patch resolves (1) by explicitly fork()ing and exec()ing,
permanently dropping privileges in the child process before the exec().

Our revised patch resolves (2) by requiring the command be a single
explicit path to an executable, which will receive a single
command-line argument (the name of the user to authorize).

We also felt that the earlier patch was mistaken by invalidating the
AuthorizedKeysFile option if PubkeyAgent is present.  The admin is
already able to disable AuthorizedKeysFile (e.g. by pointing it to
/dev/null).  Also, having a (new, relatively-unknown) option have
potentially surprising interactions with another (well-known,
widely-understood) option seems like a bad idea.  Our approach was to
provide fall-through behavior.  If the PubkeyAgent does not authorize
the connecting key, sshd will consult AuthorizedKeysFile as in current
versions of OpenSSH.

Note that we also feel the choice of option names leaves something to
be desired.  PubkeyAgent and PubkeyAgentRunAs are misleading, since
there is no required agent at all.  The term AuthorizedKeysCommand (see
#1778) seems more appropriate by analogy with existing config options
LocalCommand, ProxyCommand and AuthorizedKeysFile.  I'll offer a
revised patch with the updated names shortly.

Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

More information about the openssh-bugs mailing list