On 2 May 2004, Dan Kegel <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > >I think the improvement in friendliness makes up for any nervousness. > > That sounds like the way Microsoft thought when they were designing > ActiveX!
There's no call for that sort of language. :-) I think what you have is just timidness, rather than well-founded concern. Let's see what the differences are between the daemon starting automatically and starting ssh-agent with something like "eval `ssh-agent`". In either case the process listens on a unix-domain socket that is only accessible to the user. It is also accessible to any process of that user, for at least two reasons: access to the socket is only controlled by unix credentials, and secondly the server can be ptraced or similarly molested by any other process of that user. The ssh-agent exports some environment variables, either directly or by writing a shell fragment: SSH_AUTH_SOCK=/tmp/ssh-vFNtj16414/agent.16414; export SSH_AUTH_SOCK; SSH_AGENT_PID=16415; export SSH_AGENT_PID; echo Agent pid 16415; None of these are security critical. The only one that even looks like it is the location of the socket, but that is trivial to guess. On the other hand, the current ssh-agent design requires (well, nearly requires) that the daemon be started near the top of the tree of processes that need to use it. For example, it is quite hard to start an ssh-agent from a running X session and have it be available to every process in that session. I don't think it gives any security. It is merely cumbersome. It might be that people want several different agents running at the same time, in which case you need something like environment variables to choose among them. But I think it's fine to have reasonable defaults. Wanting just one ssh-agent per single logged on user is pretty common. I don't think it would be appropriate for ssh to automatically and by default start a background process, just because that would be surprising to users. However, if you're using a program like the mooted lfssh whose explicit purpose is to cache connections, then I think it's reasonable. If this function did go into SSH then I think it would be OK to do it automatically when the option is turned on. > The only thing that will take away nervousness is a good security analysis. > Since that's hard, IMHO making the setup of the daemon manual helps > a lot, since it makes it explicitly clear to the user that they > are opening up a possible hole. Where is the hole? Or, in what way is automatically starting the daemon when an option is given any different from starting it manually? > I posted my ideas on the ssh list, and it sounds like they like 'em > to some extent (though they haven't made the jump to one daemon > handling multiple remote systems, I think). See > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=108348373615666&w=2 > and followups. That's really good. I had been meaning to ask for a while. -- Martin
signature.asc
Description: Digital signature
__ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
