https://bugzilla.mindrot.org/show_bug.cgi?id=1663
Daniel Kahn Gillmor <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #1811|0 |1 is obsolete| | --- Comment #13 from Daniel Kahn Gillmor <[email protected]> --- 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. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
