From: gary@sci34hub.sci.com (Gary Heston)
Subject: Re: temparary superuser
Reply-To: gary@sci34hub.sci.com (Gary Heston)
Organization: SCI Systems, Inc., Huntsville, Al.
Distribution: usa
Date: Fri, 9 Oct 1992 15:06:59 GMT

This is on the verge of degenerating into a flamewar, but...

In article <1992Oct8.002114.23261@RedBrick.COM> mmt@RedBrick.COM (Maxime Taksar) writes:
>In article <1992Oct5.144903.21460@sci34hub.sci.com>, gary@sci34hub.sci.com (Gary Heston) writes:
  [ .... ]
>> Note the last two words, there: "without permission". They imply that 
>> experimenting *with* permission is OK; so that my statement was not
>> a flat prohibition against experimentation in general.

>What I'm trying to say is that giving a user an account on a machine,
>this is GIVING PERMISSION to expreminent (pay close attention here).
>If you leave security holes lying around, you're giving permission
>to experiment as root.

It may be where you are, but this is a business. Users are provided access
and accounts to do assigned work. *Nobody* around here has been assigned
the job of cracking the system, or experiment as root.

>No, I actually don't believe in such extremes, but I am trying to
>point out the concept of an "attractive nuisance."

Because the company has eight NetWare servers and a half-dozen Unix 
hosts for people to work on, we're maintaining an "attractive nuisance"?
Wow, all this time I thought it was application of technology to improve
productivity and efficiency (not to mention providing me with a job).
But we're providing an "attractive nuisance". Huh?

>> If I (a Unix/NetWare admin) caught a user trying to get root/supervisor
>> privledges in the course of "experimenting" on this network, you may rest
>> assured their account would be disabled *immediately*, and they would
>> probably lose their NIC until after there'd been a discussion of the 
>> matter with either our managers or VP. I won't tolerate crackers.

>I see.  So you're going to play gestapo with your users?  I
>certainly understand the concept that crackers are a Bad Thing,
>but why be downright paranoid?  When I see some suspicious
>activity (such as numerous "su root" failures in the logs),
>I will go and speak with the user and get an explanation.
>It's amazing how much "suspicious activity" is caused by an
>honest mistake or a buggy script.

No, I don't play gestapo. I do my job, which is to insure that the
network and hosts are up and running for legitimate use. And I'll 
disable an account as a precaution, rather than risk serious disruption
of ~150 peoples jobs. Part of my network supports a manufacturing line
that produces about $500,000 worth of computers per shift, at capacity.
*You* may be willing to risk losing a few hundred thousand dollars and
the associated customer discontent; I can't. I enjoy getting a paycheck
every two weeks, and have made a habit of it. 

Further, one or two occasions of an "su root" wouldn't be a trigger, but
continual (i.e., two or three a day from the same person) or a sudden 
burst of attempts (particularly with a "crack" script running) would.
Credit me with some judgement, please. 

>I'm not paranoid about someone cracking one of my systems.  Why?
>Because I make sure to use good security practices.

Ah, how much concrete is your system embedded in? Otherwise it's not
secure. I know that increasing security degrades usability, and that 
there must be a tradeoff. My net is fairly open, which makes it my
respossibility to keep a closer eye on things. I have to analyze 
activity which may be suspicious, and stop abuses. It's part of the
job. I could institute extreme hardware/software security measures, 
but then the users would spend more of their time working through 
the maze of logins and permsissions than they would doing useful
work. I'd rather not do that.

>The original poster wouldn't be able to get root priveleges
>to experiment on the system, assuming he didn't have permission
>and the system was properly set up and maintained.

The original poster was seeking ways to *get* root privledges 
*without* having ask his admin. I.e., he did *not* have permission
to engage in his experimentation. Granted that a poorly maintained
system is easier to crack, breaking in is still breaking in. A 
later posting from one of the admins at that site indicated he did
not have permission. There is a difference between authorized use
and unauthorized use. Having a checking account at a bank doesn't
authorize you to clean out the vault.

>You seem to have a fixation with crackers.  A user in training
>*is* a would-be cracker.  An experienced, veteran user is also 
>a would-be cracker.

No. They're potentials. A "would-be" cracker is someone who is making
an attempt. Most experience users can crack fairly easily, particulalry
with hardware access, if they want to. Having the ability does not 
automatically indicate intent. I studied martial arts for a time, which
my instructors were quite explicit that the purpose of it was "to kill".
Does that make me a would-be murder? I don't think so...

>You want to talk about rm -rf /?  I have only one word in response:
>Backups.
>
>With proper backups, even the nasty, recursive rm (which
>can simulate a complete disk failure) isn't devastating.

I'm glad your organization won't be negatively impacted by being 
totally shut down for 6-8 hours. In my case, even though I *do*
make backups, it takes time to get the systems to the point that
they can be reloaded. (And the backup software for the NetWare 
servers takes ~5 hours to restore; it's slow.) If we got shut
down for a shift, it would cost at least $500K in missed shipments,
plus the salaries of several managers, about 40 engineers, programmers,
and technicians, 30 clerks and secretaries, and 80 or so manufacturing
workers. Not a trivial amount.

And if the breach was determined to be resulting from a failure on my
part to properly react to indications of cracking, it would probably 
cost me my job.
 
>> To those of you who understand what "without permission" means, my
>> apologies for the bandwidth consumption, but it appeared to be necessary.

>It's a shame you seem to think that everyone must have an
>identical concept of "permission" as you.

I define permission as "authorization to perform tasks in accordance with
assigned duties". I can't figure out what you define it as. Giving someone
an account to develop accounting software does not automatically give them
permission to try and break into the root account.

Would any impartial party out there care to take a poll amongst the
newsgroup to see how many others think providing an account == permission
to crack, or how many agree with me? I think it'll be lopsided towards
my viewpoint.....


-- 
Gary Heston    SCI Systems, Inc.  gary@sci34hub.sci.com   site admin
The Chairman of the Board and the CFO speak for SCI. I'm neither.
"...I looked out my window, and saw Kyle Pettys' car upside down, then I
thought 'One of us is in real trouble'." Davey Allison, re: a 150MPH crash 
Newsgroups: comp.unix.admin