In message <199709161652.MAA31468@ding.mailhub.com>, "Alexander O.
Yuriev" writ
es:>
> [Mod: This message is a reason *why* linux-security is moderated list. This
> is also a reason why Rogier, myself, Alan Cox and others really do not want
> to have completely open lists that deal with security related aspects of
> running a system as way too many people just jump to conclusions and give
> suggestions without doing any reasearch on a subject. -- alex (co-moderator
> of linux-{security|alert}@redhat.com)]
Hmm. Not sure which way you''re arging here. :)
> Your message dated: Tue, 16 Sep 97 15:06:58 GMT
> > On Tue, 16 Sep 1997 09:50:08 -0400, pstewart
<pstewart@ONCOMDIS.ON.CA> wrot
> e:
> >
> > Well, first of all, as a general rule chmod -s all files except those
that
> > *really* need it... And you really need in your system.
> >
> > >-rwsr-x--- 1 root floppy 18300 Jul 5 1996
/usr/bin/fdmount
> > Do you use fd a lot ?
>
> Huh? It can be only executed frmo a group floppy.
IMHO, the original poster had the right idea here. While fdmount can
only be executed by group floppy, if there IS an exploit in fdmount,
then getting group floppy is the same as getting root.
When you''re trying to build a fairly tight machine you''re not
just
protecting against known exploits (those are the easy ones), you''re
also trying to protect against the exploits you don''t know about.
Now obviously, there are exploits for things other than setuid
programs, but that''s outside this discussion. Here , we''re
just
acknowledging that setuid programs are a prime target when attempting
to break root.
In the example above, unless you actually use the floppy drive as a
user (very unusual on a server machine), then leaving it setuid is an
accident waiting to happen. It may never happen, it may be very
unlikely, but the difference between ''very unlikely to be
exploited'',
and ''not possible to exploit'' is what is actually in question
here.
The VERY minor functionally gained by leaving it setuid costs you a
possible entry to root.
This is much the same in many of the other setuid executables. When
you''re tightening a machine, you _need_ to go thru every suid one by
one asking ''do I need this functionality''. If you''re
not sure, turn it
off. It a damned sight easier turning it back on latter then it is
fixing a machine that''s been cracked.
On a shell server machine for example, having mount and umount setuid
is pure insanity. The only possible reason for them being setuid is so
users could maybe access the floppy drive. Not too likely a server
they don''t have physical access to.
Things like crontab, at, you''re asking "is the user functionality
worth the decreased security?". Ditto rsh et al. They all continue to
work fine when run as root, and ''sudo'' can give the
functionality back
to users on a case-by-case basis.
Of course you''re going to install every fix that comes it. Not doing
so is silly. But every setuid program is a non-passworded entry to
root just waiting for an exploit to be found. Just because you don''t
know of an exploit, or there hasn''t been an exploit found
doesn''t
mean there won''t be one.
Moral: You turn off every setuid program you can, and you watch the
others like a hawk. :)
Michael.
