by mail.netbsd.org with SMTP; 20 Oct 2000 19:18:52 -0000
	via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp
	(sender: <woods@proven.weird.com>) (ident <[rhTltx9EQZESJUfZUiXzBWveTm58qU7/]> using rfc1413)
	id <m13mhgi-000gCBC@most.weird.com>
	for <tech-security@netbsd.org>; Fri, 20 Oct 2000 15:18:44 -0400 (EDT)
	(Smail-3.2.0.112-Pre 2000-Feb-17 #1 built 2000-Oct-4)
	id BE4324; Fri, 20 Oct 2000 15:18:42 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: woods@weird.com (Greg A. Woods)
To: Andrew Brown <atatat@atatdot.net>
Cc: tech-security@netbsd.org
Subject: Re: setuid ssh
In-Reply-To: <20001020143456.A4739@noc.untraceable.net>
References: <20001018135225.A7705@antioche.lip6.fr>
	<Pine.NEB.4.21.0010181440492.6544-100000@agnostic.union.cynic.net>
	<20001020182702.E976D4@proven.weird.com>
	<20001020143456.A4739@noc.untraceable.net>
Reply-To: tech-security@NetBSD.ORG (NetBSD Security Technical Discussion List)
Organization: Planix, Inc.; Toronto, Ontario; Canada
Message-Id: <20001020191842.BE4324@proven.weird.com>
Date: Fri, 20 Oct 2000 15:18:42 -0400 (EDT)

[ On Friday, October 20, 2000 at 14:34:56 (-0400), Andrew Brown wrote: ]
> Subject: Re: setuid ssh
>
> well...what does it *need* to be suid for?  is there anything besides
> the privileged port and the host key that it requires root privs for?
> or is that it?

That's it, I think, at least for ssh/slogin....

The privileged port is important in this scenario because it conveys
trust.  Obviously you have to only use this with known trusted hosts.
The result is you can allow users to delegate trust amongst a group of
trusted machines.  In an ideal world you'd have an sshd option to ignore
the (or some) user's list of known_hosts and trust only the system-wide
known_hosts list.

The private host key file could be owned by, and readable by only, any
user other than root, I suppose, but ssh/slogin would still have to be
setuid -- just not to root.  In the end this doesn't protect the remote
server much and except for worries about bugs in the client code I'm
much more willing to trust only the superuser to convey trust from a
client machine.

I don't know about OpenSSH, but if you were to make such changes to
SSH-1.2.27 or newer you'd have to audit the code with a fine toothed
comb again to make sure everything was done right since the current
implementation makes some assumptions about what it means to be
privileged (i.e. it assumes euid==0 is priviledged).

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>