tpc@leibniz.UUCP (Tom Chmara) (09/03/88)
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@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@bgsuvax.UUCP (William C. DenBesten) Date: 15 Aug 88 14:39:41 GMT Organization: Bowling Green State University B.G., Oh. >From article <8338@smoke.ARPA>, by gwyn@smoke.ARPA (Doug Gwyn ): > In article <125@leibniz.UUCP> tpc@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@sun.uucp (Greg Limes) Date: 17 Aug 88 17:52:42 GMT Organization: Sun Microsystems, Inc. In article <183@ndc.UUCP> sgf@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@sun.com] for uucp, backbone!ucbvax!sun!limes ----------------------------------------------------------------------------- From: morrison@ficc.UUCP (brad morrison XNX SE#) Date: 17 Aug 88 18:33:11 GMT Organization: Xenix/Unix Support In article <183@ndc.UUCP>, sgf@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@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@cbnews.ATT.COM> lvc@cbnews.ATT.COM (Lawrence V. Cipriani) writes: # In article <25952@think.UUCP> barmar@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@BNR.CA