OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
FreeBSD Security Archives: Re: Examining FBSD set[ug]ids and th

Re: Examining FBSD set[ug]ids and their use


Robert Watson (robertcyrus.watson.org)
Wed, 3 Nov 1999 12:29:38 -0500 (EST)


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

robertfledge.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 majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message



This archive was generated by hypermail 2.0b3 on Wed Nov 03 1999 - 11:49:51 CST