tchrist@convex.com (Tom Christiansen) (09/12/89)
Some site are known to have multiple uid 0 accounts so not
everyone needs to know the root password. I seem to recall
that this is considered a poor idea for security reasons.
Could someone please explain why?
thanks,
--tom
Tom Christiansen {uunet,uiucdcs,sun}!convex!tchrist
Convex Computer Corporation tchrist@convex.COM
"EMACS belongs in <sys/errno.h>: Editor too big!"gwyn@smoke.BRL.MIL (Doug Gwyn) (09/12/89)
In article <1723@convex.UUCP> tchrist@convex.com (Tom Christiansen) writes: >Some site are known to have multiple uid 0 accounts so not >everyone needs to know the root password. I seem to recall >that this is considered a poor idea for security reasons. >Could someone please explain why? The main thing is that it doesn't make sense. It is UID 0 that has privileges, not username "root". In any case, nobody should be logging in as "root". You should set up your system so that system administration can be done by some nonprivileged UID. UID 0 should only be assumed by carefully-checked utilities that apply access controls.
tr@madeleine.ctt.bellcore.com (tom reingold) (09/12/89)
On the subject of "Multiple Root ID's considered evil?",
tchrist@convex.com (Tom Christiansen) writes:
$ Some site are known to have multiple uid 0 accounts so not
$ everyone needs to know the root password. I seem to recall
$ that this is considered a poor idea for security reasons.
$ Could someone please explain why?
The practice of having multiple privileged logins is criticized because
it is said that this gives the cracker more chances at cracking a
privileged password.
I disagree with this outlook. While it is true that the cracker has
more chances, I think this is more than outweighed by several
advantages. Primarily is that people -- who even trust each other --
don't share passwords. Therefore, when you need to give out a
superuser password temporarily, you don't give out the one that
everyone knows and depends upon staying the same. Instead you make a
temporary one and destroy it later, leaving the regular superuser
passwords in place.
Another small advantage, not to be counted upon heavily, is that
crackers who don't have your password file may start by assuming that
there is a "root" login and try to crack that password. If you have a
"*" as the password field, you rest assured that the cracker can try
all he likes at that account.
Tom Reingold |INTERNET: tr@bellcore.com
Bellcore |UUCP: bellcore!tr
444 Hoes La room 1H217 |PHONE: (201) 699-7058 [work],
Piscataway, NJ 08854-4182 | (201) 287-2345 [home]rayan@cs.toronto.edu (Rayan Zachariassen) (09/12/89)
gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >In any case, nobody should be logging in as "root". You should set >up your system so that system administration can be done by some >nonprivileged UID. UID 0 should only be assumed by carefully-checked >utilities that apply access controls. You have to be *very careful* in doing this, because of the assumption spread throughout most unix code that uid 0 is the only one that should be special-cased. It is in general easier to break into non-0 accounts due to such oversights in various ``secure'' code, and it is hard to get rid of the problem areas. The only long-term solution I see is a user-configurable policy routine for each system, because people will do things their own way no matter what and the security policy should adapt. We did start out with most of our binaries owned by a non-0 id for ideological reasons, but quickly reverted to root ownership because of these problems. It is easier to firewall root than a zoo of other ids.
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/13/89)
In article <89Sep12.115240edt.2385@neat.cs.toronto.edu> rayan@cs.toronto.edu (Rayan Zachariassen) writes: >We did start out with most of our binaries owned by a non-0 id for >ideological reasons, but quickly reverted to root ownership because of >these problems. It is easier to firewall root than a zoo of other ids. Yes, but the idea is to have a set-UID (0 in this case) program for installing the software, not to turn loose humans with elevated permissions.
connelly@deimos.cis.ksu.edu (Paul Connelly) (09/13/89)
In article <1723@convex.UUCP> tchrist@convex.com (Tom Christiansen) writes: >Some site are known to have multiple uid 0 accounts so not >everyone needs to know the root password. I seem to recall >that this is considered a poor idea for security reasons. >Could someone please explain why? > uid 0 is root for all intents and purposes. Passing out multiple uid 0 accounts defeats the purpose in not letting other people know "root"'s passwd.
bill@twwells.com (T. William Wells) (09/13/89)
In article <1723@convex.UUCP> tchrist@convex.com (Tom Christiansen) writes:
: Some site are known to have multiple uid 0 accounts so not
: everyone needs to know the root password. I seem to recall
: that this is considered a poor idea for security reasons.
: Could someone please explain why?
If done for the reason you suggest, that is an _awful_ idea! Root is
root. Anyone who gets uid 0 is god. On the other hand, we have three
root logins: one that uses / as the home directory and does not do
any interesting stuff in its .profile and two for the root "user"
(one using the Bourne shell and one using the C shell) which gets a
normal user environment; we treat these accounts as the same account
and give them the same password. The first account is there so that
we have a root login that won't break just because some wierdness is
going on in the network. The others are used for normal root activity
(but we have C shell fanatics and Bourne shell fanatics and never the
twain shall meet. :-)
---
Bill { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.comtcurrey@x102c.harris-atd.com (currey tom 76327) (09/13/89)
Today, everyone is very concerned about security measures to there machine. It seems to me that "root" is used for system maintience more than anything else. I agree that the root password must be protected, but multiple uid 0 restricted logins are very helpful and secure. It is easy to write a small C program that calls specific commands under specific conditions. Make the executable the initial shell in the /etc/passwd file. Bingo, a protected controlled 0 uid process. This does assume that there are no backdoors or calls like "exec /bin/csh" in the code. These shells become a definate advantage to control privilaged operations.
tchrist@convex.COM (Tom Christiansen) (09/13/89)
In article <1989Sep13.082607.981@twwells.com> bill@twwells.com (T. William Wells) writes: >If done for the reason you suggest, that is an _awful_ idea! Root is >root. Anyone who gets uid 0 is god. Certainly. I perhaps misrepresented my reason. The real reason was to grant or remove superuser priv's to specific users without having to constantly muck with the One True Root Password. I personally don't do it that way at my site, preferring people to log in as themselves and su. --tom Tom Christiansen {uunet,uiucdcs,sun}!convex!tchrist Convex Computer Corporation tchrist@convex.COM "EMACS belongs in <sys/errno.h>: Editor too big!"
bill@lxn.eds.com (Bill Doviak) (09/13/89)
In article <17601@bellcore.bellcore.com> tr@madeleine.UUCP (tom reingold) writes: >On the subject of "Multiple Root ID's considered evil?", >If you have a "*" as the password field, you rest assured that the cracker >can try all he likes at that account. After checking both PASSWD(4) and PASSWD(1), I can't determine the signifcance of an asterisk in the password field unless you wish to prevent logins entirely for that account. Is this the intention or is there some other purpose for the "*"? -- Bill Doviak | US MAIL: Electronic Data Systems (EDS) UUCP: vu-vlsi!lxn!bill | Lanark Building or bill%lxn.uucp@rutgers.edu | Center Valley, PA 18034 or lehi3b15!lxn!bill | Voice: (215) 282-1213
pcf@galadriel.bt.co.uk (Pete French) (09/14/89)
From article <435@lxn.eds.com>, by bill@lxn.eds.com (Bill Doviak): > > After checking both PASSWD(4) and PASSWD(1), I can't determine the signifcance > of an asterisk in the password field unless you wish to prevent logins > entirely for that account. Is this the intention or is there some other > purpose for the "*"? Yup - you gotit ! The star is 'traditional' for some reason. technically known as being 'starred out'. -Pete. -- -Pete French. | British Telecom Research Labs. | "The carefree days are distant now, Martlesham Heath, East Anglia. | I wear my memories like a shroud..." All my own thoughts (of course) | -SIOUXSIE
envbvs@epb2.lbl.gov (Brian V. Smith) (09/15/89)
< > I perhaps misrepresented my reason. The real reason was < >to grant or remove superuser priv's to specific users without having < >to constantly muck with the One True Root Password. I personally < >don't do it that way at my site, preferring people to log in as < >themselves and su. < < What's the diff? That way you have an audit trail of people who have su'ed, either in /var/log/authlog (SunOs4.0) or /usr/adm/sulog (Ultrix X.X). _____________________________________ Brian V. Smith (bvsmith@lbl.gov) Lawrence Berkeley Laboratory I don't speak for LBL, these non-opinions are all mine.
bph@buengc.BU.EDU (Blair P. Houghton) (09/15/89)
In article <1738@convex.UUCP> tchrist@convex.COM (Tom Christiansen) writes: >In article <1989Sep13.082607.981@twwells.com> bill@twwells.com (T. William Wells) writes: >>If done for the reason you suggest, that is an _awful_ idea! Root is >>root. Anyone who gets uid 0 is god. > >Certainly. I perhaps misrepresented my reason. The real reason was >to grant or remove superuser priv's to specific users without having >to constantly muck with the One True Root Password. I personally >don't do it that way at my site, preferring people to log in as >themselves and su. What's the diff? --Blair "I hear a throng of voices, all speaking those words, voices that are not delayed so much as the net propagation..."
cpcahil@virtech.UUCP (Conor P. Cahill) (09/15/89)
In article <4157@buengc.BU.EDU>, bph@buengc.BU.EDU (Blair P. Houghton) writes: > In article <1738@convex.UUCP> tchrist@convex.COM (Tom Christiansen) writes: > >Certainly. I perhaps misrepresented my reason. The real reason was > >to grant or remove superuser priv's to specific users without having > >to constantly muck with the One True Root Password. I personally > >don't do it that way at my site, preferring people to log in as > >themselves and su. > > What's the diff? One big difference is that you do not have to pass out the single root password to every user that needs root privileges. This makes it simpler to maintain and/or control access to root privileges without having to walk around the building giving everybody the password. I have worked for clients that use this same functionality with a slight bend. They have a setuid root program that has a list of users and individual passwords (well protected, of course) that allow those users to assume root privileges without having to pass out the root password. These solutions are not used to distinguish the root account from other 0-id accounts, but just a managment tool for limiting the distribution of a single password. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
kencr@haddock.ima.isc.com (Kenny Crudup) (09/16/89)
From article <435@lxn.eds.com>, by bill@lxn.eds.com (Bill Doviak): > After checking both PASSWD(4) and PASSWD(1), I can't determine the signifcance > of an asterisk in the password field unless you wish to prevent logins > entirely for that account. Is this the intention or is there some other > purpose for the "*"? In article <347@galadriel.bt.co.uk> pcf@galadriel.bt.co.uk (Pete French) says: >Yup - you got it ! >The star is 'traditional' for some reason. technically known as being >'starred out'. One day while bored at work, I got out a piece of paper and traced back the DES crypt routine for some popular combinations of salt/key. If anyone is intrested, I have the passwords that make *, x, X, and 13 X's and 13 x's work. Send me E-mail. -- Kenneth R. Crudup, Contractor, Interactive Systems Co.(386/ix), Cambridge MA Not all men are fools; some are still single! Phone (617) 661 7474 x238 {encore, harvard, spdcc, think}!ima!haddock!kencr kencr@ima.ima.isc.com
bph@buengc.BU.EDU (Blair P. Houghton) (09/16/89)
In article <347@galadriel.bt.co.uk> pcf@galadriel.bt.co.uk (Pete French) writes: >From article <435@lxn.eds.com>, by bill@lxn.eds.com (Bill Doviak): >> >> After checking both PASSWD(4) and PASSWD(1), I can't determine the >>signifcance of an asterisk in the password field unless you wish to >>prevent logins entirely for that account. Is this the intention or is >>there some other purpose for the "*"? > >Yup - you gotit ! > >The star is 'traditional' for some reason. technically known as being >'starred out'. But, and this is important, it's not perfect, or even very close. With a * in the password field, and a hostname in his .rhosts, a user can log in without a password from that "trusted" host. Make up your own method to fix this. I think I'll just rot13 the .rhosts of people who "don't need" their access, after starring them out. --Blair "Speaking from experience, of course..."
kencr@haddock.ima.isc.com (Kenny Crudup) (09/16/89)
You guys remember when I said..... >One day while bored at work, I got out a piece of paper and traced back >the DES crypt routine for some popular combinations of salt/key. If >anyone is intrested, I have the passwords that make *, x, X, and 13 X's >and 13 x's work. Send me E-mail. Uh, people, I was *KIDDING*....... Trace back DES on *a piece of paper*?? /usr(/mail/kencr) on haddock is beginning to over-flow here. Besides.... s'impossible.... comp.unix.wizards indeed.... :-) -- Kenneth R. Crudup, Contractor, Interactive Systems Co.(386/ix), Cambridge MA Not all men are fools; some are still single! Phone (617) 661 7474 x238 {encore, harvard, spdcc, think}!ima!haddock!kencr kencr@ima.ima.isc.com
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (09/17/89)
In article <14617@haddock.ima.isc.com> kencr@haddock.ima.isc.com (Kenny Crudup) writes: >One day while bored at work, I got out a piece of paper and traced back >the DES crypt routine for some popular combinations of salt/key. If >anyone is intrested, I have the passwords that make *, x, X, and 13 X's >and 13 x's work. Send me E-mail. All valid passwords encode to 13 characters. The strings '*', 'x', 'X', and so on, all have no valid passwords. In particular, the string '*' is an impossible valid encryption as '*' is not even present in the output alphabet since the alphabet is [a-zA-Z0-9./]. This is very important since '*NO PASSWORD*' is 13 characters long. It is also an impossible encryption as both '*' and ' ' do not exist in the above alphabet! This is your best bet as a string to put in the password file as it documents your intentions clearly. I am wondering if Kenny has the clear-text for the string 'lotsabullshit' on his notepad ;-) -- John F. Haugh II +-Quote of the month club: ------------ VoiceNet: (512) 832-8832 Data: -8835 | It's not that important, InterNet: jfh@rpp386.cactus.org | it's only USENET. UUCPNet: {texbell|bigtex}!rpp386!jfh +-------------- -- Rich $alz ----
paul@uxc.cso.uiuc.edu (09/17/89)
Re: multiple su accounts:
By and large we don't use them here. The exception is for people like me
who act as floating fire-fighter and network cowboy on several systems.
Keeping track of the root password on machines administered by different
people isn't possible w.o. writing them down. By having an individual su on
those machines (with a strong password that's regularly changed) I can
fix problems w.o. tracking down the sysadmin. All of our systems allow
direct root login from the console only.
The Next machine has a good idea: anyone in group 0 may su using their own
password. The key here is to make sure those people pick good passwords.
Once someone no longer needs root access, simply edit /etc/group to remove
their user-id from the 0 group.
Paul Pomes
Univ of Illinois, CSOnight@pawl.rpi.edu (Trip Martin) (09/17/89)
In article <4183@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >With a * in the password field, and a hostname in his .rhosts, a user >can log in without a password from that "trusted" host. > >Make up your own method to fix this. I think I'll just rot13 the .rhosts >of people who "don't need" their access, after starring them out. The method I've seen, and used on at least one occasion to plug that hole is to make their login shell something that can't be executed, usually /dev/null. I think I can guarantee that no one's going to log in using that account without a login shell. Trip Martin KA2LIV night@pawl.rpi.edu Finite state machinist night@uruguay.acm.rpi.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/17/89)
In article <14617@haddock.ima.isc.com> kencr@haddock.ima.isc.com (Kenny Crudup) writes:
-One day while bored at work, I got out a piece of paper and traced back
-the DES crypt routine for some popular combinations of salt/key. If
-anyone is intrested, I have the passwords that make *, x, X, and 13 X's
-and 13 x's work. Send me E-mail.
I could believe XXXXXXXXXXXXX and xxxxxxxxxxxxx, but not a non-13 character
encrypted password.mouse@mcgill-vision.UUCP (der Mouse) (09/17/89)
In article <17601@bellcore.bellcore.com>, tr@madeleine.ctt.bellcore.com (tom reingold) writes: > On the subject of "Multiple Root ID's considered evil?", > tchrist@convex.com (Tom Christiansen) writes: >> Some site are known to have multiple uid 0 accounts so not everyone >> needs to know the root password. I seem to recall that this is >> considered a poor idea for security reasons. Could someone please >> explain why? > The practice of having multiple privileged logins is criticized > because it is said that this gives the cracker more chances at > cracking a privileged password. This is perfectly true, and it's one of the things you must consider when deciding what your security tradeoffs are. > Another small advantage, not to be counted upon heavily, is that > crackers who don't have your password file may start by assuming that > there is a "root" login and try to crack that password. If you have > a "*" as the password field, you rest assured that the cracker can > try all he likes at that account. Anyone sophisticated enough to have much hope of cracking a password given nothing but your passwd file is surely smart enough to search for other super-user codes. (And to not try to crack an uncrackable password field!) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
jeenglis@nunki.usc.edu (Joe English) (09/17/89)
kencr@haddock.ima.isc.com (Kenny Crudup) writes: >One day while bored at work, I got out a piece of paper and traced back >the DES crypt routine for some popular combinations of salt/key. If >anyone is intrested, I have the passwords that make *, x, X, and 13 X's >and 13 x's work. Send me E-mail. Wow! You must have been extremely bored... But I'd check your work, since the DES algorithm isn't supposed to yield 1-character strings. --Joe English jeenglis@nunki.usc.edu. BTW, if you've got some spare time on your hands, could you factor 1001314159265692877 for me? Thanks.
bob@wyse.wyse.com (Bob McGowen Wyse Technology Training) (09/20/89)
In article <14617@haddock.ima.isc.com> kencr@haddock.ima.isc.com (Kenny Crudup) writes: >From article <435@lxn.eds.com>, by bill@lxn.eds.com (Bill Doviak): >> After checking both PASSWD(4) and PASSWD(1), I can't determine the signifcance >> of an asterisk in the password field unless you wish to prevent logins ---deleted--- >One day while bored at work, I got out a piece of paper and traced back >the DES crypt routine for some popular combinations of salt/key. If >anyone is intrested, I have the passwords that make *, x, X, and 13 X's >and 13 x's work. Send me E-mail. > I was under the impression (I do not remember from which document) that an encrypted password would "ALWAYS" be 13 characters, which would imply that *, x and X would never be generated and would therefore be totally safe. Is this wrong or am I missing some other information that isn't in the docs? Also, under XENIX the asterix has been replaced with NO LOGIN, which certainly tells what is intended and is not equal to 13 characters. Is there any inherent danger in using this? Thanks. Bob McGowan (standard disclaimer, these are my own ...) Customer Education, Wyse Technology, San Jose, CA ..!uunet!wyse!bob bob@wyse.com
rusty@cadnetix.COM (Rusty Carruth) (09/20/89)
In article <3812@helios.ee.lbl.gov> envbvs@epb2.lbl.gov (Brian V. Smith) writes: >< >... preferring people to log in as >< >themselves and su. > >< What's the diff? > >That way you have an audit trail of people who have su'ed, >either in /var/log/authlog (SunOs4.0) or /usr/adm/sulog (Ultrix X.X). > >Brian V. Smith (bvsmith@lbl.gov) However, I would like to remind you that, should someone become root who wishes to hide that fact, and should /var/log/authlog be someplace that the root-ed person can touch... well, lets just say that your log means nothing in this case, since root can go edit that file and remove the entries. Or even change them to reference someone else rather than themselves. Nope, sorry, but once someone becomes root the logs mean nothing if that person knows where they are (and how to change them). I could tell you a long story about this as it relates to the Univac 1100 series, but then this is comp.UNIX.wizards.... ^^^^ ---------- Rusty Carruth UUCP:{uunet,boulder}!cadnetix!rusty DOMAIN: rusty@cadnetix.com Daisy/Cadnetix Corp. (303) 444-8075\ 5775 Flatiron Pkwy. \ Boulder, Co 80301 Radio: N7IKQ 'home': P.O.B. 461 \ Lafayette, CO 80026
greg@tcnz2.tcnz.co.nz (super) (09/20/89)
There are some cases where multiple root id's are ok. We have various root level logins with limited access right for certain tasks :- full system backups - so that not permission hangups will lose a file spooler - the /dev and various other directories are protected against any one less than root fooling around in them. The spooler sometimes needs to kill and restart devices with root permissions. operator access - we have operators who can perform various functions such as killing all the processes for a terminal which is hung who we do not want to give full root access, and who we wish to be able to individually track their actions. These are all restricted in how they can operate, and can gain access to only very limited areas of the system. Works fine. 'Gotta get me a Telefunken u47 onna these days' -- Greg Calkin Thomas Cook N.Z. Limited, ...!uunet!vuwcomp!dsiramd!marcamd!tcnz2!greg PO Box 24, Auckland CPO, or greg@tcnz.co.nz New Zealand. Phone (09)-793920
mrd@sun.soe.clarkson.edu (Michael DeCorte) (09/21/89)
In article <9560@cadnetix.COM> rusty@cadnetix.COM (Rusty Carruth) writes: >However, I would like to remind you that, should someone become root >who wishes to hide that fact, and should /var/log/authlog be someplace >that the root-ed person can touch... well, lets just say that your >log means nothing in this case, since root can go edit that file True but sometimes is not a question of trust but I want a trail so that I can say "Hey did you do this? Yeah... Well that ain't the way to do it" (eg someone accidently blew away /dev/null and didn't recreate it properly) -- Michael DeCorte // H215-546-0497 W386-8164 Fax386-8252 // mrd@clutx.bitnet 2300 Naudain St. "H", Phil, PA 19146 // mrd@sun.soe.clarkson.edu --------------------------------------------------------------------------- Clarkson Archive Server // commands = help, index, send, path archive-server@sun.soe.clarkson.edu archive-server%sun.soe.clarkson.edu@omnigate.bitnet dumb1!dumb2!dumb3!smart!sun.soe.clarkson.edu!archive-server ---------------------------------------------------------------------------
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (09/21/89)
I don't see anything wrong with multiple root logins. There are two main areas of use, the first being limited root operations like shutdown or backup, accessible to operators or trusted users, and the second being a regular root login for each type of shell normally run on the machine. Root is too powerful to trust users to either always change shells or not to type the wrong thing by instinct. Many of the systems here have a Korn shell login and in some cases a csh login as well. I see no virtue in leaving anything manual which can be automated. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
barnett@crdgw1.crd.ge.com (Bruce Barnett) (09/21/89)
In article <7383@rpi.edu>, night@pawl (Trip Martin) writes: >The method I've seen, and used on at least one occasion to plug that >hole is to make their login shell something that can't be executed, >usually /dev/null. I think I can guarantee that no one's going to >log in using that account without a login shell. Just a small point: This will not affect someone using a TOPS account. (TOPS is Sun's Mac file server software). That is, if someone has an account and password, but the shell of /dev/null, they can still use the TOPS account. Also - I seen to recall that something complained when I used /dev/null. Perhaps a log file. I have since then used /bin/true. I don't know which technique is better. -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
jc@minya.UUCP (John Chambers) (09/22/89)
In article <1989Sep13.082607.981@twwells.com>, bill@twwells.com (T. William Wells) writes: > In article <1723@convex.UUCP> tchrist@convex.com (Tom Christiansen) writes: > : Some site are known to have multiple uid 0 accounts so not > : everyone needs to know the root password. I seem to recall > : that this is considered a poor idea for security reasons. > : Could someone please explain why? > > If done for the reason you suggest, that is an _awful_ idea! Root is > root. Anyone who gets uid 0 is god. Not necessarily. On several systems, I've installed special packages for admin purposes that have to be super-users (have you ever tried to do a backup in a non-root id?); the account had its own "shell" for the use of novices, that held their hands and led them through some menus that let them do only a few things. It's pretty easy to make this quite secure, as long as you don't let them do things like run a shell or vi or such. (Actually, I always include a shell escape; I just don't mention it in the documentation. Anyone who posts to this group would probably guess the syntax the first time; the operators never guess it. ;-) Another reason that I like to make new super-users is that I find it much easier (and safer) to work in a familiar environment. If I make myself a super-user account with my home directory and the same shell, then I don't get surprised by commands doing different things when I'm su than when I'm myself. Well, not quite; I won't say what I'd like to do to the geniuses who decide that commands like ls should behave differently for user 0 than for all other users. Let's just say that it has on occasion had some very unpleasant consequences, which wouldn't have happened if it had ignored the .* files like it's supposed to. It's especially annoying to think that the little monster wastes cpu cycles every time it's called, just so it can do this to me.... Recently I had a bit of fun at a place where I was doing some consulting. I had the usual user account, and after a couple of weeks, I was asked if I needed the root password for some things they'd asked me to do. I said no; I'd already made myself a super-user account, and I preferred to use it, since its environment was set up like I liked it. They were duly impressed.... [I'm just a boy named 'su' ;-] -- #echo 'Opinions Copyright 1989 by John Chambers; for licensing information contact:' echo ' John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)' echo '' saying
harrys@tons61.UUCP (Harry Skelton) (09/22/89)
We have a problem of multible logins as root (actually su's since our login program prohibits direct root access) and I was thinking of adding something like the "session" program to the shell and have it save the session to the console hardcopy printer - regarless! I don't think the user will be able to get rid of the hard copy without notice, change tty's in midwork, nor get by the idea that a deamon opens a file for audit then unlink()'s it while still open to hide it (fsck will fix it later in lost+found) and/or the deamon can "add" an entry to the directory with the propper inode information...etc. Some users try to remove the .history file but fsck picks it up later and they don't know I keep a second copy elsewhere...:-) I feel if security (or system) is so bad you need direct root access, then have a lot of passwords involved! Perhaps put the "root terminal" on a 'dialup' device to force two passwords...etc. Perhaps the best method is a hard copy terminal in a locked box (keys accessable though..). -- Harry Skelton - Senior Systems Administrator - U.S. Dept. of Transportation ..!attctc!tons61!harrys ..!obdient!tons61!harrys ..!tfd!tons61!harrys [ Views expressed by Harry Skelton are not those of the US Gov. or CBSI ]
rcd@ico.ISC.COM (Dick Dunn) (09/26/89)
In article <114@tons61.UUCP>, harrys@tons61.UUCP (Harry Skelton) writes: > We have a problem of multible logins as root (actually su's since our login > program prohibits direct root access) and I was thinking of adding something > like the "session" program to the shell and have it save the session to > the console hardcopy printer - regarless!... Be careful with approaches like this! All too often, when you need to su, it's because something has gotten thoroughly hosed up. You have at least one machine I/O-wedged, or CPU-wedged (or both, if it's one of *those* days); you can't tell what's causing the problem, it gets worse by the minute; you've GOT to get a few commands through to avoid bringing every- thing to its knees. In cases like this, you DON'T want a lot of baggage hanging off everything you do as root. You want to depend on the fact that if only simple things are working, you can do simple things and get out of the mess. If you have to piece a system back together, you don't want some magic which has to work before you can do it. In short, you don't need stuff going on behind your back... >...I don't think the user will be > able to get rid of the hard copy without notice, change tty's in midwork, > nor get by the idea that a deamon opens a file for audit then unlink()'s... [various additional precautionary games] If you've got this sort of problem with people who have a root password, I don't think you can solve it by administrative procedures. If you need this much distrust of people with root, your organization is broken. That is, you've got people problems. In a UNIX environment with hostile users, you don't give the hostile users a root password, period. -- +---------+ Dick Dunn rcd@ico.isc.com ico!rcd (303)449-2870 | In this | 4th annual MadHatterDay [10/6/89]: | style | A Kinder, Gentler Fool's Day |__10/6___|