From owner-freebsd-security Thu Nov 4 2:50:38 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 2056E15670 for ; Thu, 4 Nov 1999 02:50:31 -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 WAA39578; Wed, 3 Nov 1999 22:03:16 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Wed, 3 Nov 1999 22:03:15 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Marc Slemko Cc: freebsd-security@FreeBSD.ORG Subject: Re: Examining FBSD set[ug]ids and their use In-Reply-To: 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, Marc Slemko wrote: > On Wed, 3 Nov 1999, Robert Watson wrote: > > > 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 > > No they can't. It is schg for this very reason. Not the best solution, > but it works. > > man did have numerous security holes that let you easily compromise the > man uid and then replace the binary, but the known ones (ie. the ones I > found and maybe a couple more) were fixed in... 1996 at thet same time it > was made immutable. I must have missed the commit on that (doh). However, the argument does hold for the following binaries in /usr/bin, which are owned by non-root and not schg: -r-sr-sr-x 1 uucp dialer - 110760 Oct 26 09:07 cu* -r-xr-xr-x 1 uucp dialer - 34096 Oct 26 09:13 tip* -r-sr-xr-x 1 uucp wheel - 79112 Oct 26 09:07 uucp* -r-sr-xr-x 1 uucp wheel - 33480 Oct 26 09:07 uuname* -r-sr-sr-x 1 uucp dialer - 86556 Oct 26 09:07 uustat* -r-sr-xr-x 1 uucp wheel - 79936 Oct 26 09:07 uux* Which all fit into the UUCP category. I'm not clear why tip, which is not setuid, is owned by UUCP, btw. > > 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... > > setgid introduces the problem that then the user running it has > permissions to modify the generated file. This is _not_ desirable. > > The alternative is a setuid root program that setuid()s to the appropriate > uid then executes the program. Then no code that is executed has to be > modifiable by that uid. There are still potential issues with that > though. The alternative I generally prefer to setuid in passwd/etc is to have a daemon running that receives local IPCs via a UNIX domain socket using ancillary data to authenticate. However, you don't want to have a mand, etc, etc. A uucpd might make a lot of sense though, but I don't see anyone rewriting UUCP at this point. The best bet for UUCP may be to move it out of the way of normal users (preferably into a package or separate distibution, as with X et al) so they don't have to be exposed to the risk. I see the objection of the UUCP people to the package option, but given that *man pages* are in a separate distribution object, I would think that that option would be acceptable :-). 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