Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 3 Nov 1999 16:16:16 -0700 (MST)
From:      Marc Slemko <marcs@znep.com>
To:        Robert Watson <robert+freebsd@cyrus.watson.org>
Cc:        freebsd-security@FreeBSD.ORG
Subject:   Re: Examining FBSD set[ug]ids and their use
Message-ID:  <Pine.BSF.4.20.9911031603560.89877-100000@alive.znep.com>
In-Reply-To: <Pine.BSF.3.96.991103122522.35508K-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

> 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.



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.4.20.9911031603560.89877-100000>