[1605] in linux-security and linux-alert archive
[linux-security] Re: Re: Security Concern..
daemon@ATHENA.MIT.EDU (Zygo Blaxell)
Thu Sep 18 08:08:39 1997
Date: Tue, 16 Sep 1997 19:50:36 -0400
From: Zygo Blaxell <zblaxell@fiction.org>
To: linux-security@redhat.com
In-Reply-To: <199709161652.MAA31468@ding.mailhub.com>
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
In article <199709161652.MAA31468@ding.mailhub.com> you write:
>[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)]
Keeping the BS to a minimum is the first and last job of any moderator.
Unfortunately, we need contributors to contribute better content...
>> >-rwsr-xr-x 1 root bin 17196 May 22 1996 /usr/bin/at
>> there are some exploits for it. I suggest you chmod -s it.
>Silly advice. There were some exploits of atrun about 2 *years* ago.
I object to the term "silly." Security vulnerabilties are not silly at
all when you've got them and someone else knows about it!
You can't just dismiss problems by saying "it was a problem two years
ago" and assume that it has been fixed and has *stayed* fixed. 'at'
was a problem six years ago on SunOS too, but that didn't automatically
mean it was fixed four years later on Linux, and some vendors with
low computer expertise (can you say "bookstores"?) are still selling
circa-1994 Linux Slackware distributions. Either *verify* that your
system has a recent version of 'at', one that has been fixed, or admit
that you're not taking all of the simple and effective security measures
possible and that you're happy with that.
An administrator whose primary concern is security can just turn off all
privileged executables and services, then turn them back on if and when
they are needed. This is the first and easiest way to get a lot of
security in a hurry. *Don't* do this on any active machine where
productivity is more important than security, because you *will*
disable something important unless you know what you're doing and make
no mistakes. Don't do this unless you *intend to learn* what components
you need and which ones you can remove or replace. *Do* do this on a new
machine when you are configuring it for later production use, because it's
notoriously difficult to fix problems once the system is in the field.
Always allow for error--both yours and someone else's. Two unrelated
"minor" security problems can add up to a root-compromising vulnerability.
You might change your system configuration in some apparently harmless
way, but in fact set up preconditions for a security hole in software
on your system that you've never heard of. New "merely theoretical"
attacks become practical and effective exploit scripts in about three
months. Pay attention and you can have solutions in place weeks or even
years before they even become problems.
What we need from resources like this mailing list is *information*
that can be used to make these decisions. What was the 'at' exploit,
how do we test for it, which distributions have been fixed, and exactly
what impact does disabling the 'at' service have, anyway? We have
several users who don't even know that 'at' exists, and wouldn't miss
it even if they did, so why is it such a big deal to disable it? Heck,
why did we install it in the first place? It's taking up 0.000089 gigs
of disk space! ;-)
In the case of 'crontab', removing the setuid bit makes cron
reconfiguration only available to root, but doesn't actually disable cron
for any user. This means that users can't change their crontabs, but root
can, and in any case cron continues to work. This isn't a problem for me,
my users, or my software, but it might be a problem for you, your users,
or your software. Please keep that in mind and keep the biased editorial
commentary to a minimum.
Of course most of this information should be on web sites with
references to it in the list, because nobody on this list has time to
read messages nearly as long as this one. ;-)
Finally, one technical error:
>> >-rwsr-xr-x 1 root bin 13937 Dec 5 1995 /usr/bin/rcp
>> and also this one
>
>losing rcp functionality.
Nope. 'rcp' calls the privileged 'rsh' to perform the actual protocol.
'rcp' itself doesn't need privileges at all, and IIRC it tries to throw
them away if it discovers that it has them.
