Date: Wed, 3 Nov 1999 22:03:15 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Marc Slemko <marcs@znep.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Examining FBSD set[ug]ids and their use Message-ID: <Pine.BSF.3.96.991103204049.39149B-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.20.9911031603560.89877-100000@alive.znep.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.991103204049.39149B-100000>