openssh unix dev - Apr 2013 - ssh-agent allowing access to other users?

hi openssh folks--

thanks to openbsd-compat/getpeereuid.c, ssh-agent refuses to allow
connections from other users.  This is great in the general case, but in
some cases, i would like to use the agent to mask off access to the raw
public key material but make it available for use by other user accounts.

For an example use case, see what Tollef (cc'ed here) was trying to do
in [0].  running the agent as one user and permitting access from
another user via filesystem permissions currently fails due to the euid
check in ssh-agent.c.

Is it unreasonable to propose a slight weakening of this check when
deliberately configured?  If so, what interface would seem most
reasonable to permit?

Some example interface choices:

 A) ssh-agent could take a new -g option indicating the name of a unix
group; if a peer's euid is a member of that group (based on the same
logic used by sshd's AllowGroups option) then access would be granted.

 B) the SSH_ALLOWED_EUIDS environment variable for the ssh-agent process
could be read as a whitespace-separated list of acceptable numeric uids
to allow connections from?

 C) some other configuration interface/authorization interface?  I'm
open to suggestions...

I'd be happy to write up a patch for A or B if folks think either would
be reasonable.

Feedback?  Thoughts?

Regards,

	--dkg


[0]
http://err.no/personal/blog/tech/2013-03-22-09-45_sharing_an_ssh_key_securely.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20130401/74301c75/attachment.bin>

On 01/04/13 23:36, Daniel Kahn Gillmor wrote:
> hi openssh folks--
>
> thanks to openbsd-compat/getpeereuid.c, ssh-agent refuses to allow
> connections from other users.  This is great in the general case, but in
> some cases, i would like to use the agent to mask off access to the raw
> public key material but make it available for use by other user accounts.
>
> For an example use case, see what Tollef (cc'ed here) was trying to do
> in [0].  running the agent as one user and permitting access from
> another user via filesystem permissions currently fails due to the euid
> check in ssh-agent.c.
>
> Is it unreasonable to propose a slight weakening of this check when
> deliberately configured?  If so, what interface would seem most
> reasonable to permit?
Add a --allow-other-users or --give-keys-to-anyone parameter?
Given that there will be little use of such feature, it's hard to make
an interface
which serves everybody and someone disabling that check should know what
they are doing (and thus properly secure the fs permissions).

As for the problem of Tollef due to an evil ssh-agent (clever trick!), a
solution
would be to make /usr/bin/ssh-agent sgid to another group (eg.
?good-agent?), then check
in the sudo snippet (you better make a script...) that $SSH_AUTH_SOCK
belongs
to that group (and thus was created by the trusted code).

There are a few caveats for BSD:
* Some BSD flavours ignore socket permissions (but the containing folder
should still make the initial --allow-other-users socket safe).
* It may be possible to reattach to the socket under BSD using SO_REUSEADDR
in the second process (anyone wants to test with AF_UNIX?)

Under Linux (which is what Tollef seems to be using) it would apparently
work.
Anyone seeing a hole in that method?