Workstations: owner root access (summary)

Sat Sep 3 06:40:00 AEST 1988

Sorry for the long delay in actually getting a reply out; between
going on course and losing my feed, it's taken a while to get it
together...

My request dealt with workstation root access:  whether there were
any good reasons for providing this and if so how extensively.
Note that we run an NFS system; my summary on NFS security (posted
to comp.unix.wizards) might be a good read for anyone interested
in this topic.

Excerpts follow...note that some messages (containing duplicate
information) were not republished.  Referenced messages were not printed
in favour of printing the messages containing the references.
 I appreciate your input, but I'd like to keep this posting as short as I can.

-----------------------------------------------------------------------------

From: david at geac.UUCP (David Haynes)
Date: 13 Aug 88 11:26:28 GMT
Organization: Champion of Lost Causes Everywhere

As a system administrator in a (small) workstation environment, I
think I should make a small plea for a voice of reason here. I don't,
as a rule, give out root passwords to every Tom, Dick or Susan who
asks for it, but I do give root access to those individuals who are
competant enough (in my opinion) to have it. Why so?

The releasing of the root password, even on a single workstation, can
spell some long hours of recovery on your part as the result of a
typical novice Unix user's mistake (such as rm * .tmp in the root
directory). However, it is equally a pain in the ass to have to
su somebody in and out of root perms because they are installing
a package on their workstation that has root level daemons or
requires other "high" privileges. Basically, I try to use common sense
wherever possible. 

-----------------------------------------------------------------------------

From: denbeste at bgsuvax.UUCP (William C. DenBesten)
Date: 15 Aug 88 14:39:41 GMT
Organization: Bowling Green State University B.G., Oh.

>From article <8338 at smoke.ARPA>, by gwyn at smoke.ARPA (Doug Gwyn ):
> In article <125 at leibniz.UUCP> tpc at leibniz.UUCP (Tom Chmara) writes:
>>   Are there any cogent arguments for or (gulp) against root access?
> 
> The most serious problem is that, in many networking implementations,
> super-user access on one system is tantamount to super-user access on
> all machines in the entire (local) network.

Networks that have this problem are not properly set up.  BGSU's
network has 3 computers that are 'trusted hosts' to one another.
Other machines are not in the trusted host list.  This means that the
machine that we allow entire classes (as in 30 students) to have su
access to does not compromise the security of the rest of the
computers.  When you ftp, rlogin, etc from that machine, or any other
machine on the network, it requires that you type the root password on
the destination machine.

> The UNIX "super-user" UID should really be used only by privileged
> utilities, not by people.  There should be NO NEED, in a properly
> configured system, for a person to type "su" in order to perform
> system-administrative actions.

Yea, right.  See my .signature.

-----------------------------------------------------------------------------

From: Ross Wetmore <bnr-di!watmath!grand!rwwetmore>
To: bnr-di!leibniz!tpc
Organization: U. of Waterloo, Ontario

  Given the ability of a single rogue machine to completely disrupt a
local network, to monitor and perhaps even simulate privileged communications
and a host of other global maintenance and security headaches, it is no
wonder a central support service does not want to get into this arena. At
the moment, network robustness and security features are sufficiently
immature that to permit such things as NFS, or almost any transparent
intermachine functionality, means root access from any machine on that 
network is almost sufficient to gain total control of any component on
that network.
  Even simple things like maintaining passwd file consistency across an
NFS domain would be upset by permitting local users minimal local
autonomy. All one needs to do is create a userid with a privileged uid
on another machine and bingo ... you are in the backdoor.

>  You write...
>   The prevailing attitude in the E.E. is 
>that people are going to mess up bad, 
  This *will* happen often enough to be a significant disruption of many
peoples time and efforts.
>that they don't need the access, and 
  Grey area ... they probably don't need *root* access, but for example
something like a menu of canned root functions is not an unreasonable
request to bypass the bureaucratic service problems alluded to above, 
but at the same time to insure that naive users can't do untold damage.
>that they're going to be uneducated and irresponsible.  
  Idiots are incredibly ingenious ... therefore making something idiot
proof is next-to-impossible. This will be the source of 99% of the 
problems. The 1% remaining presumes knowledgeable users, hence problems
are deliberately caused and one is faced with the hassles of tracking
down and disciplining malicious abusers. Both are incredibly time
consuming and messy jobs. Front-end control is always easier.

  Deliberate intent, or irresponsibility is not a pre-requisite for
total chaos ... most people never realize when they are getting in over
their heads, or the full extent of the ramifications of what they are
doing.

  I'd like to see robust workstations that didn't require high privilege
maintenance, or robust/secure networking that could tolerate any problems
arising from a single component. Unfortunately, neither exist and therefore
there is a critical tradeoff in maintainability/security between distributed
and centralized maintenance and the privileges needed to handle it. Too a
large extent, the decision on what to permit and what not, is probably 
going to be determined by the smallest threshold of security or disruption
potential which can be tolerated on the network. 
  Then too in many cases, the political aspects (centralized vs distributed
control, additional workload or the lack of it - ie power and financial or
job security issues) are sometimes overwhelming considerations.
  There is no single solution ...
-----------------------------------------------------------------------------

From: bnr-di!xios!greg (Greg Franks)
To: nrcaer!bnr-vpa!bnr-di!leibniz!tpc
Organization: XIOS Systems Corporation

If any of your programs need root access (eg, programs which use the
stupid berserkeley socket stuff), then you need to be root to suid them.
The main reason I am root is for this purpose.  The Evil Empire attends
to the drudgery of file system maintenance.  But then again, the evil
empire trust me.

-----------------------------------------------------------------------------

From: bnr-di!uunet!apctrc!zjat02 (Jon A. Tankersley)
Newsgroups: comp.unix.questions
Organization: Amoco Production Co, Tulsa Research Center

I'd be more in favor of closing down root access than opening it up.
It is one thing to have local root access only and to have that access
leak onto other systems.  Amoco has quite a few workstations at present,
and very few root access personnel.  When a requirement for root access
presents itself one of the root people is called.  We've been trying to
log what that access involved and have developed quite a few 'asroot'
functions that are fairly secure to do those 'precise' functions.

The lpd is a good example.  There is a resetprinter function in /usr/local/bin
that will attempt to clear the lpd and printer if one exists.  If this fails
then I have to go back to work.

The other people that have root access that aren't support personnel have
that access and are logging its use so that more of these utilities can
be developed, but early on problems developed.  I had one making 10's
of symlink's as root in /.  Because he couldn't make it work as a user.
Turned out that he had protections wrong on some directories, and he didn't
think about the problem.

Another problem we've had is in the area of backups.  Because the dumps can't
be initiated by non-root I have written some asroot functions to kick off
a dump if the correct userid requests it.  But this has some other problems
when done across the network.  Root access is required if you can't use
the userid.host:/dev/mtdevice form.  That 'feature' is also going away with
newer releases of OS functionality and can't be portably counted as being
there.  Hence on our disk full systems root can access the major tape
systems which are our diskless client servers.  I don't want anybody in
general to have THAT access.  Screwing up on a diskless or small disk system
is one thing, doing the same stuff accidently on a larger server is a whole
different issue.

If it weren't for the dump problem, it would not be as critical.  We are
addressing that by writing our own dump program....

Root access on all systems would be nice to open up for some things, but not
everyone is UNIX-savvy.  I've one person with 3 months UNIX experience (lots
of other computer experience too) start using root for EVERYTHING on a shared
system (I couldn't remove the root priv either).  That is STUPID.  He
installed things that made assumptions of a specific environment trashed
stuff of other users.  It is possible that giving root access to users on
workstations that they could create setuid things 'to get the job done, you
understand' that would allow other to trip over and trash things.  If it can
happen on a shared system it can also happen in a workstation environment
with shared resources.  Just think of the goodies that most people share
nowadays.  I had a user that had a shell script that started emacs and looped
to go back in after exiting emacs.  Pretty simple.  But 5 workstations started
exhibiting no response.  Seems that emacs didn't exit correctly when suntools
was exited.  Hogged the CPU.  This was a non-root problem with UNIX in general.
Adding root can add even more problems.

-----------------------------------------------------------------------------

From: limes at sun.uucp (Greg Limes)
Date: 17 Aug 88 17:52:42 GMT
Organization: Sun Microsystems, Inc.

In article <183 at ndc.UUCP> sgf at ndc.UUCP (Sharon Gates-Fishman) writes:
>I work on a diskless microVAX 2000, so I don't do my own system 
>administration, but I occasionally _must_ have su privledge (sp?).
>That happens when my system must be rebooted, so I have to do a
>shutdown.  Now, my system administrator _could_ walk around to
>every uVax in the building (we don't have all that many), and
>reboot them herself, but it's a lot easier for her to call me
>(and the other VaxStation folks) and ask me to do it myself.

Actually, this can be solved without giving the workstation owner the
root password. Generate a small script that allows specific actions to
be done, and wire it up to a maintenance login:

	maint::0:1:Maintenance Account:/:/usr/local/bin/maint

Now give "maint" a password only known by the workstation's owner. This
"maint" program can be as simple or as complex as the installation
wants.

For an even easier case -- I administer a small lab, containing eight
workstations and a server. Sometimes I have to reboot machines, and
frankly I would rather not stand there at the console waiting to log in
as root. The solution? A "yoyo" account:

	yoyo::0:1:Bouncer:/:/yoyo

with a script that runs /etc/fastboot, if and only if it is run from the
console and there is nobody else on the system. No password needed.

Generalize for your installation, tune for smoke.

-- redhead [limes at sun.com]
   for uucp, backbone!ucbvax!sun!limes

-----------------------------------------------------------------------------

From: morrison at ficc.UUCP (brad morrison XNX SE#)
Date: 17 Aug 88 18:33:11 GMT
Organization: Xenix/Unix Support

In article <183 at ndc.UUCP>, sgf at ndc.UUCP (Fishman) writes:
> I work on a diskless microVAX 2000, so I don't do my own system 
> administration, but I occasionally _must_ have su priviledge.
> That happens when my system must be rebooted, so I have to do a
> shutdown.  Now, my system administrator _could_ walk around to
> every uVax in the building (we don't have all that many), and
> reboot them herself, but it's a lot easier for her to call me
> (and the other VaxStation folks) and ask me to do it myself.
>
You could use a "shutdown" login, which could run the shutdown program
as its "shell", with user id zero.  The password could also be "shutdown".
You could trap all of the interrupts, and even if someone was able to
interrupt the program, all they'd get would be a login prompt.

-----------------------------------------------------------------------------

From: greywolf at unisoft.UUCP (The Grey Wolf)
Date: 22 Aug 88 18:29:42 GMT
Organization: UniSoft Corporation (The Berkeley Port Authority), Emeryville, CA

In article <887 at cbnews.ATT.COM> lvc at cbnews.ATT.COM (Lawrence V. Cipriani) writes:
# In article <25952 at think.UUCP> barmar at kulla.think.com.UUCP (Barry Margolin) writes:
# >Why not just make shutdown setuid root, and executable only by a group
# >of which you are the sole member?
# 
# /etc/shutdown is a script, but can be worked around.  One other thing that
# must be done is to stay out of single user mode.  If you go to single user
# from multi-user the user is made root.

/etc/shutdown is a script only on SOME system V machines.  On most machines I
work with, it is an executable file.  And, to boot, under Berkelix 4.x, it
kills all the processes before going single-user on the console.  That solves
both problems.
[NOTE:  This is NOT to propogate another SysV/BSD war; they both have their
points, good and bad.]

# 
# >These are the kinds of tools someone was referring to when he said
# >that in a well-designed system you should rarely need to use "su".
# >"su" should only be for unusual circumstances.  Users shutting down
# >their workstations is not unusual, so there should be a standard tool
# >for it.
# 
# Indeed.  Isn't it rediculuous that the most mudane operations (backup,
# recover, creating users, etc.) on a eunuchs computer require the most
# powerful permissions possible.  Sheesh.

geez, you mean I can't add users to my own system without becoming root?
Aw, darn.  I can chown things to other people so that they are the ones who
appear to be taking up all the space on the system (under SysV, but then
I guess SysV doesn't support quotas (if it did, accounting procedures would
be for naught under current implementations, but this is another story)).

# -- 
# Larry Cipriani, AT&T Network Systems, Columbus OH, (614) 860-4999

----------------------------------------------------------------------------

Thanks to all for replying.
Hope this information is useful to someone/anyone.

        ---tpc---
-- 
------------------------------------------------------------------------
Tom Chmara			UUCP:  ..utgpu!bnr-vpa!bnr-di!leibniz!tpc
BNR Ltd.  			BITNET: TPC at BNR.CA