/etc/shutdown permissions

Jim Rosenberg jr at amanue.UUCP
Sun Nov 20 07:12:24 AEST 1988


In article <1349 at umbc3.UMD.EDU> alex at umbc3.UMD.EDU (Alex S. Crain) writes:
>In article <234 at safari.UUCP> dave at safari.UUCP (dave munroe) writes:
>>In release 3.5 at least, /etc/shutdown has permissions -rwxr-xr-x, which is
>>obviously a bad idea.
>
>	Yea, but does it really matter? I think that you have to be root
>to have /etc/shutdown work anyway, because the shutdown system call 
>(in syslocal(5)) must be executed by the root user.
>
>	Now -rwsr-sr-x would be a different story....

For a while I had an account on my machine for a student programmer type.  He
was working part time for a company I was also consulting for, & I needed a
way for us to be in touch by email on days when I woulnd't be down there.  I
run process accounting & kept a very sharp eye on what he did on my machine.
(Yes, Virginia, process accounting works on the 3b1, even if they were too
negligent to give us the utilities to turn it on or log the results!)  I just
about jumped out of my skin when I saw killall in the log.  I had his login
shell as ksh & was able to peruse his history file, & sure enough, he had
executed /etc/shutdown.  It is *very* true that he didn't in fact succeed in
shutting my system down, but it gave me a very nasty scare!!  I went through
/etc with a fine tooth comb removing permissions left and right.

This fellow *would* crack a system if it were easy for him.  He was more the
kind of guy who would pull a lever just because it happened to stick out from
the wall -- just to see what would happen -- rather than a determined cracker.
I'm not at all comfortable with the idea of o+x permissions on /etc/shutdown,
relying on the fact that shutdown is smart enough not to let anyone but root
succeed.  If a user is allowed to execute shutdown that may convey an idea that
security is lax on your machine, and that person may go wandering around
looking for a more serious target.  Of course the opposite case could be argued
too:  a determined cracker likes nothing better than a challenge.

The most obvious approach to security is the ring approach where you hope you
have in place a ring of defenses, and that it will take several successive
failures before you get cracked.  Lax permissions on system administration
commands is not a ring, it's an open door.  YOU ARE ASKING FOR TROUBLE if you
don't tighten up on /etc, in my opinion.

To be truthful, I can hardly believe in light of all the concern for security
prompted by the (apparently) Morris Worm that anyone would seriously propose
leaving 755 permissions on something like /etc/shutdown, for crying out loud!
The off-the-shelf permissions on the 7300 are probably the worst of any
commercially released UNIX box ever seen on the face of the earth.  You should
give your machine a thorough going over.

Hey folks, wormville & virusville mean a whole new ball game when it comes to
security!!!  If your machine has a security hole you might very well never get
cracked.  In order to be cracked you have to have (1) a security hole (2) a
cracker who has access to your machine or knows its phone number (3) the
cracker has to know how to exploit the hole (4) the cracker has to have the
desire to invoke the hole.  Only so many machines with a given hole will in
fact get cracked through it.  Viruses & worms make it a whole different ball
game.  *EVERY* machine with a virusable hole is *QUITE LIKELY* to be cracked.
The fingerd bug that the Morris Worm used still has me shaking my head.  How
may other programs are suceptible to that same attack??  Are we *REALLY* sure
that uuxqt can't be penetrated?  Think about it.  For crying out loud, being
safe and sane in your permissions for system administration commands is the
*SIMPLEST* security thing you can do.  Do it, do it today, for heavens sake!!
-- 
 Jim Rosenberg
     CIS: 71515,124                         decvax!idis! \
     WELL: jer                                   allegra! ---- pitt!amanue!jr
     BIX: jrosenberg                  uunet!cmcl2!cadre! /



More information about the Unix-pc.general mailing list