From owner-freebsd-security Wed Nov 3 9:48:34 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 502E615700 for ; Wed, 3 Nov 1999 09:48:26 -0800 (PST) (envelope-from robert@cyrus.watson.org) 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 MAA36300; Wed, 3 Nov 1999 12:29:38 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Wed, 3 Nov 1999 12:29:38 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Spidey Cc: Ollivier Robert , freebsd-security@FreeBSD.ORG Subject: Re: Examining FBSD set[ug]ids and their use In-Reply-To: <14367.64514.294218.824898@anarcat.dyndns.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 3 Nov 1999, Spidey wrote: > Ok... In fact, this UUCP thing has been discussed over and over again > on the various FBSD-* lists, and I don't want to get back on this, as > I think compatibility wins over the security in that perticular case. > > Anyways, since UUCP runs in its sandbox, I guess it's ok... Hmm. Well, the old security hole in the sandbox that I reported, that root ran uustat each day, has now been fixed (at least, in 3.3 it has been). However, I don't like that /usr/bin/uustat is still owned by UUCP, and appears in the default path for root and others. Really, if a binary is not owned by a privileged account, it should not be in the default system path, rather in some obscure subdirectory where a user has to intentionally go find it, in my opinion. :-) Same goes for man -- /usr/bin/man is owned by uid man, so anyone who breaks the manpage sandbox can modify it, and abscond with the privileges of any user running man. Man should really use a gid, not a uid, so that the man binary doesn't have to by writable by the sandbox. Or alternatively, we should throw away caching since our machines are getting so fast :-). There are no doubt others, of course, but the traditional flaw here is that setuid binaries have to be owned by the account they switch to, making them a poor choice for a sandbox. Really the binary switching to the sandbox should not be modifiable by code running in the sandbox. setgid doesn't fix that entirely because it doesn't handle the sandbox the same way, but... 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-security" in the body of the message