From owner-freebsd-arch Sat Sep 2 14:48:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 99CAE37B42C; Sat, 2 Sep 2000 14:48:15 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id RAA60815; Sat, 2 Sep 2000 17:45:14 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 2 Sep 2000 17:45:14 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Jacques A. Vidrine" Cc: Neil Blakey-Milner , Dan Nelson , sthaug@nethelp.no, phk@critter.freebsd.dk, ume@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: setuid ssh should die (Re: Request for review: nsswitch) In-Reply-To: <20000902155701.C1263@hamlet.nectar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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