Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 2 Sep 2000 17:45:14 -0400 (EDT)
From:      Robert Watson <rwatson@FreeBSD.ORG>
To:        "Jacques A. Vidrine" <n@nectar.com>
Cc:        Neil Blakey-Milner <nbm@mithrandr.moria.org>, Dan Nelson <dnelson@emsphone.com>, sthaug@nethelp.no, phk@critter.freebsd.dk, ume@FreeBSD.ORG, arch@FreeBSD.ORG
Subject:   Re: setuid ssh should die (Re: Request for review: nsswitch)
Message-ID:  <Pine.NEB.3.96L.1000902174123.60028C-100000@fledge.watson.org>
In-Reply-To: <20000902155701.C1263@hamlet.nectar.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2 Sep 2000, Jacques A. Vidrine wrote:

> On Sat, Sep 02, 2000 at 10:14:24PM +0200, Neil Blakey-Milner wrote:
> > So was he.  He is talking RhostsRSAAuthentication.  I think we needn't
> > worry about it, and we should default to non-suid, with a comment in the
> > configuration stating that RhostsRSAAuthentication requires suid-root on
> > the ssh binary on the client side.
> 
> Agreed.
> 
> It may make sense to have ssh warn if it is not setuid, and this option
> has been requested, e.g.
> 
> @@ -546,6 +546,10 @@
>  	}
>  	/* Disable rhosts authentication if not running as root. */
>  	if (original_effective_uid != 0 || !options.use_privileged_port) {
> +		if (options.rhosts_authentication ||
> +		    options.rhosts_rsa_authentication)
> +			log("Warning: rhosts disabled - "
> +			    "insufficient privileges");
>  		options.rhosts_authentication = 0;
>  		options.rhosts_rsa_authentication = 0;
>  	}

That sucks.  Don't do that. :-)

Part of my BSDCon TrustedBSD talk is going to deal with precisely the type
code that appears above: rather than checking uid's, please *attempt* the
operation where possible (and I realize it's not always possible for
compound operation).  The reason is that this is a file system based
access control check, and that the userland process cannot predict the
access control used under the VFS layer.  For file systems with non-local
security models (NFS, AFS, Coda, smbfs), the local uid is often not a
predictor of whether the call will succeed. 

Instead, either perform the open() directly to check, or make use of the
access() syscall.

In a capability-based environment, ssh may have CAP_DAC_READ_SEARCH and
CAP_NET_BIND, which would permit it to (a) be protected from interference,
and (b) read the key file and bind the requisite port.  A uid==0 check
would foil that, and require the application be modified.  This is much
the same as similar checks in kernel, where callers should not directly
test for privilege, they should query the suser function.


  Robert N M Watson 

robert@fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000902174123.60028C-100000>