ssh-agent allowing access to other users?

[Daniel Kahn Gillmor]

On 04/01/2013 06:57 PM, Ángel González wrote:
> Add a --allow-other-users or --give-keys-to-anyone parameter?

i was thinking that the semantics would be more like
"allow-certain-other-users-to-make-ssh-agent-requests".  since ssh-agent
doesn't give its keys to anyone under any circumstance, there would be
no give-keys-to-anyone, and any constraints the ssh-agent owner wanted
to impose would still be honored for requests coming from other users.

So, for example, i could run an ssh-agent in my main X11 session and ask
it to prompt me for every request.  Then i could allow a designated user
account access to that agent's socket, and i could selectively allow or
deny requests made by that user account.

The idea of live modifications of the access list suggests a third
implementation option:

 C) extend the ssh-agent protocol to include enabling access to other
users with a separate protocol command type.

I'm not sure i like it, but it's worth having on the table while
brainstorming, i guess.

> 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).

Nothing about this proposal mentions adjusting the fs permissions.  The
current code is already more restrictive than the fs permissions.  If we
wanted to trust the user to know what to do with fs permissions, we
could just do that directly by dropping the getpeereuid check entirely.
 But i'm proposing to selectively loosen the getpeereuid check, not to
tweak the fs permissions at this point.

And yes, a sophisticated user can work around this (as i am currently,
for example, by using a socat invocation as the original ssh-agent user
to launder connections from another less-restrictive socket through to
the original ssh-agent socket).  But this is crufty and more dangerous
and more complex than just having the logic where it makes more sense:
in the agent itself.

> 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).

on the system i'm currently using (Debian GNU/Linux), /usr/bin/ssh-agent
is already setgid root, to avoid arbitrary memory access by
non-privileged users.  I think this isn't compatible with the change
you're suggesting.

Thanks for the thought and feedback!

Regards,

	--dkg


-------------- 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/4dee625d/attachment.bin>