From mboxrd@z Thu Jan 1 00:00:00 1970 From: William Josephson To: 9fans@cse.psu.edu Subject: Re: [9fans] one reason ideas from Plan 9 didn't catch on Message-ID: <20011113191919.A86980@honk.eecs.harvard.edu> References: <20011113195826.27824199BB@mail.cse.psu.edu> <24323.1005692093@apnic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <24323.1005692093@apnic.net>; from ggm@apnic.net on Wed, Nov 14, 2001 at 08:54:53AM +1000 Date: Tue, 13 Nov 2001 19:19:19 -0500 Topicbox-Message-UUID: 21f8d9fc-eaca-11e9-9e20-41e7f4b1d025 On Wed, Nov 14, 2001 at 08:54:53AM +1000, George Michaelson wrote: > > That's all my fault. Rsc, ehg, and I have been working on a new security > > architecture that makes ssh, ssl, private passwords, etc. easier to keep > > track of and use, sort of sshagent++, in addition to fixing the plan9 > > authentication. > > This both intrigues and worries me. I use ssh-agent a lot, but I have huge > lingering worries that the chain of open FD back through process history > and the IPC mechanisms is a gaping yaw of risk. I personally refuse to use ssh-agent and avoid ssh X11 forwarding because I don't trust either to get this sort of thing right. I'll leave it to Presotto to discuss the system in detail, but they've done a lot of thinking about this sort of problem. > Wouldn't a kerberos tkt like mechanism pose less risks? Isn't the pain of > occaisional re-authentication purposeful? I exclude systems like the SUNray > where a physical token can be removed and moved to carry the auth info. It isn't tied to a particular protocol. > Having said which, if Plan9 has a clean abstraction for this (and the little > I understand about the mechanisms suggest this strongly) then its a wonderful > idea. > Doesn't it also pose risks for loss of that parent ssh-agent-like thing? It serves a similar purpose and ssh-agent is probably the closest thing under Unix. Unlike Unix, Plan 9 has per-process namespaces (and single-user terminals). You end up having to trust the kernel either way, of course. -WJ