Date: Mon, 15 Jul 1996 11:00:23 -0400 (EDT) From: Paul Danckaert <pauld@umbc.edu> To: Mike Newell <mnewell@kaizen.net> Cc: jbhunt <jbhunt@mercury.gaianet.net>, freebsd-security@freebsd.org, root@mercury.gaianet.net Subject: Re: New EXPLOIT located! Message-ID: <Pine.SGI.3.91.960715104720.7723A-100000@umbc7.umbc.edu> In-Reply-To: <Pine.SGI.3.92.960715103831.1447A-100000@dada.kaizen.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 15 Jul 1996, Mike Newell wrote:
> On Mon, 15 Jul 1996, Paul Danckaert wrote:
>
> > The normal policy we use when setting up machines here is to do a find
> > for suid and sgid files on the system. Pick off the essential ones, and
> > strip the bits off any others. Its saved us from several irix and sun
> > holes in the past.. and one or two bsd ones now too.
>
> What do you consider "essential ones"? I realize that a case-by-case
> analysis of the pros/cons of what to/not keep SUID would be a book in
> itself [:-)], especially since the usefulness of each is dependent on what
> the system is being used for. However it would be nice to know what
> utilities *must* be SUID for a baseline system, and especially what
> utilities are "safely" SUID and what aren't.
Well, the case-by-case basis of it makes it sort of difficult to come up
with a real list. Some things I am unsure of, since I don't know if they
will adversely affect the system.. but in general
PPP/slip (ppp{,d}, sliplogin)
Multicast (mrinfo,mrtrace)
SuidPerl (sperl*, suidperl*)
Rdist (I run usc's rdist)
timed (timedc.. I run xntpd anyway.)
mount_* commands
If its a server box, and doesn't have to be very user friendly, I take a
more restrictive approach and nuke things like at{,q,rm}, lock, and
things like that.
Now, I'm sure that most of these are safe.. however, if they are not
necessary for the system to run, and I don't use them, I don't see the
point of leaving them suid root. After all, I can make them suid later
if I need them..
One question I do have, on an unrelated topic, is if people have a way of
setting up a box so people can't just ^C the boot, and get a root
prompt? Perhaps putting a trap in the rc scripts, or something else?
paul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SGI.3.91.960715104720.7723A-100000>