perry@vu-vlsi.UUCP (02/02/87)
In article <263@aramis.RUTGERS.EDU> mende@aramis.RUTGERS.EDU (Bob Mende) writes: > >> Below is included a nice little feature program, it can be used as an >> alternative to su(1) or in conjunction with it. > > Here at rutgers we have a local hack that is called slide. Slide >is a program that can be as simple as Both of these programs (performing password-free su) seem dangerous to me- if one of the authorized users were to accidently leave themself logged on, anyone could come along and su from their terminal. Also, it makes the knowledge of an authorized sus/slide users password equivalent to knowing the root password. ...Rick ..{cbmvax,pyrnj,bpa}!vu-vlsi!perry perry@vuvaxcom.bitnet
brisco@caip.UUCP (02/03/87)
From perry@vu-vlsi.UUCP (Rick Perry) Mon Feb 2 11:48:49 1987 >> >>> Below is included a nice little feature program, it can be used as an >>> alternative to su(1) or in conjunction with it. >> >> Here at rutgers we have a local hack that is called slide. Slide >>is a program that can be as simple as > >Both of these programs (performing password-free su) seem dangerous >to me- if one of the authorized users were to accidently leave themself >logged on, anyone could come along and su from their terminal. Also, >it makes the knowledge of an authorized sus/slide users password >equivalent to knowing the root password. Here at Rutgers we only give out group `slide' (the group which one must belong to for successful completion of "slide") rather sparingly (but maybe not sparingly enough ...). However, it is well known by anyone in this group that leaving a terminal in any public place unattended will result in loss of this group access (as well as job termination in some cases). However, I'd like to think that we could trust these people not to give out their passwords (strictly verboten), and chose good enough passwords such that they aren't easily guess-able. I think that this beats allowing a position where the person might write down the root password (if you only need to be root twice a year ...). Also, it is a lot easier in terms of maintanance (wanna notify some 20 users every time you change the password?) In addition, for security reasons, we have at least one password change for slide users per year. Any time there is a even a *hint* of password leakage (is there a better term?), all slide group membership is taken away from everyone until their password has been confirmed as changed. As with any type of root access, there are security holes, but we feel we have minimalized them. What better to trust? Giving out the root password (to be written down, forgotten, changed) or to trust a person to not leave a logged in job unattended? Of course, the truly best way to do this would be to not allow root access to anyone -- or to allow root access to everyone. tp. -- ---------------------------------------------------------- - ARPA: Brisco@rutgers - - UUCP: (ihnp4!ut-sally, allegra!packard) !caip!brisco - ----------------------------------------------------------
perry@vu-vlsi.UUCP (02/03/87)
In article <4055@caip.RUTGERS.EDU> brisco@caip.RUTGERS.EDU (Thomas Paul Brisco) writes: >... > As with any type of root access, there are security holes, but >we feel we have minimalized them. What better to trust? Giving out the >root password (to be written down, forgotten, changed) or to trust a >person to not leave a logged in job unattended? What we have been doing is to have separate root logins for each user that can su. The login directory for these su's are in sub-dir's of the normal user's login. For example, ~perry is my normal login, and 'su rickp' makes me root with $HOME as ~perry/rickp. That way, each su has a separate tcsh .history file which can be useful not only for the user, but also handy in backtracking when someone screws up something. Also, an individual su can be easily deleted without having to change a global root password and notify everyone [and that's a nice feature of the 'sus' access file and 'slide' group stuff too, agreed]. I do see the usefullness of the sus/slide password-free su's for people who need it a lot and are hassled by always having to type a password in the normal setup. I was really tempted to make something like that here but have decided against it due to paranoia I guess. Also, we only have four su's, perhaps the management situation would be different if we had 20 or more... ...Rick
ignatz@aicchi.UUCP (02/04/87)
A couple of years ago I ran into the problem of providing root capabilities to several people, any one of which could disappear at any time. I abhor the overhead of changing the root password every time one of these people leaves; so I don't have to do it anymore. Simply, I re-wrote 'su' from scratch; it behaves exactly like Sys V su, EXCEPT there's a privileged user file (/etc/privuser). This file has a list, one per line, of the people priviliged to become root, and an encrypted password PER USER, similar to that in /etc/passwd.e., "ignatz:QIXPkVxTEYlYk ". (When a user is first entered in the file by the system administrator, the password is set to a known ASCII string by the SA.) When that priviliged login executes 'su', if the ASCII string is found in the privuser file, the person must then set their root password; thereafter, until they reset it, that's their personal root password. Nobody except the 'real' system administrator ever need know the 'real' root password; and revoking privileges consists of deleting one line from the privuser file (and, as usual, 'scrubbing' the system for Trojan horses, etc.; but you always have to do that, if you don't trust the person leaving...) It's worked reliably and efficiently now for 2-3 years. -- Dave Ihnat Analysts International Corporation (312) 882-4673 ihnp4!aicchi!ignatz || ihnp4!homebru!ignatz
trt@rti-sel.UUCP (02/04/87)
> Both of these programs (performing password-free su) seem dangerous > to me- if one of the authorized users were to accidently leave themself > logged on, anyone could come along and su from their terminal. Short reply: Yes a password-free su (PWFSU) is dangerous. So is typing the root password all the time. I feel that the security trade-off is a wash, and PWFSUs win because they are more convenient. Long reply: This weakness occurs on all normal UN*X systems anyway. Anyone can come along and install a trojan horse 'su', in the authorized user's bin, which steals the root password. There are lots of other ways to exploit a logged-in terminal. There is always "find / -exec rm -f {} ';'", just to be malicious. > Also, > it makes the knowledge of an authorized sus/slide users password > equivalent to knowing the root password. Again, this is true on normal UN*X systems with or without PWFSUs. If you know the authorized user's password, to a large degree you *are* that authorized user. You can masquerade as him to the OS and (more importantly) to other users. And you can set up a fantasy world for the "real" authorized user in which every communication between that user and the OS is examined and altered as desired. (Yes a 'trusted path' would avoid much, but not all, of this insecurity.) Years ago Brian Kernighan explained the power of UNIX pipes and filters, saying that other operating systems could obtain the same effect but that "It isn't enough for it to be possible, it must be easy". In UNIX lots of things were easy. It had chdir (cd), which made it easy to snoop in other users' files. Did that make UNIX insecure? Lots of people thought UNIX was insecure, and I am sure chdir was a subconscious part of that thought. On Duke's IBM OS/MVT system all kinds of amazingly important files were readable *and writable* but were 'safe' because without chdir and ls the files were too much trouble to hunt down and exploit. PWFSUs make an existing security problem (unattended terminals) easier to exploit. Should we ban PWFSUs, or go after the real problem? Maybe terminals should 'lock up' after being idle for a while. Maybe terminals should have a user-proximity detector, and require re-authentication after the user is no longer proximate. Or just do what we do -- threaten our users with bodily harm if they exploit security weaknesses. Works great. Tom ("just kidding") Truscott
gore@nucsrl.UUCP (02/06/87)
> Yes a password-free su (PWFSU) is dangerous. > So is typing the root password all the time. > I feel that the security trade-off is a wash, > and PWFSUs win because they are more convenient. Here we use a program, called 'su2', which consults /usr/lib/super-users to see if the invoking account is authorized to use it. Then it asks for the password *to the invoking account*. Thus, authorized users can leave their terminals unattended if nobody knows their password. (If somebody does know that password, that somebody doesn't need an unattended terminal.) On the other hand, if an authorized user always uses 'su2' on a terminal in a secure place (like a private office), a "+" can be put in front of that user's login name in /usr/lib/super-users, and that user won't be asked for a password. This, I feel, is the best possible solution. With 'su2', we don't have to give out the root password, and change it every time we want to remove a person from the ranks of the privileged. At the same time, the eligible superusers don't have to be paranoid when they are operating in their own, unpriveleged accounts. That program also has other neat features. Unfortunately, while there are no copyright notices in it, I do know that it was written by an HP employee, and I don't feel free to post it. Jacob Gore Northwestern University, Computer Science Research Lab {ihnp4,chinet}!nucsrl!gore
charles@hpcvcd.UUCP (02/09/87)
>> Both of these programs (performing password-free su) seem dangerous >> to me- if one of the authorized users were to accidently leave themself >> logged on, anyone could come along and su from their terminal. > >Short reply: >Yes a password-free su (PWFSU) is dangerous. >So is typing the root password all the time. >I feel that the security trade-off is a wash, >and PWFSUs win because they are more convenient. At this site we have a program called su2 which requires the user to type his OWN password. He never knows the root password, but can still get access to that power occasionally. Naturally, su2 only allows authorized users to become superuser. Some advantages to this are that the real superuser can change the root password as often as he likes. He can remove users from the su2 list without asking their permission and without changing the root password. He also does not need to know their passwords. ---------------------------------------------- I did not write su2. Sorry, I can not post it. ---------------------------------------------- >Long reply: >This weakness occurs on all normal UN*X systems anyway. >Anyone can come along and install a trojan horse 'su', >in the authorized user's bin, which steals the root password. Wrong. I am not even a superuser and I don't allow anything that weak on my path. All common commands are in protected directorys, and are early in my PATH. I have two unprotected directorys on my PATH, and they are at the end of it. One of them is ".", and I am sometimes tempted to remove it altogether. I know many people put "." first on their PATH. This is like hanging a "Kick Me" sign on your back. I am tempted to put a program called "ls" in one of my directorys. The program would do nothing but make it look like it had caused them damage. >There are lots of other ways to exploit a logged-in terminal. >There is always "find / -exec rm -f {} ';'", just to be malicious. "rm -rf /" is shorter. >> it makes the knowledge of an authorized sus/slide users password >> equivalent to knowing the root password. Alas, this is a problem. >Or just do what we do -- threaten our users with bodily harm >if they exploit security weaknesses. Works great. > Tom ("just kidding") Truscott >---------- I know of someone unknowingly running the equivalent of "rm -rf /users/*". Charles Brown hplabs!hp-pcd!charles
bob@acornrc.UUCP (02/11/87)
I've seen all these variations on 'su' flying across the net. None of them
are secure; they all seem to ignore the fact that once an authorized user
has superuser privileges, he can do *anything*.
For example, what's to prevent the su-ed user from copying the source to
the original su, taking out the password check, and installing the
resulting program somewhere where he can get to it later? Or simply
writing su from scratch? It is a trivial program, after all. One can
even copy one's favorite shell and make it suid root.
So all one has to do is generate his own private su, make it setuid root,
and hide it somewhere in the bowels of the system. Then if he's taken
off the authorized list, he can still su. System administrators would have
to sweep the entire disk for setuid root programs every time a user was
de-authorized. And I've seen complaints from people who find it a chore to
change the root password!
Bottom line: once a superuser, always -- potentially -- a superuser.
--
Bob Weissman
Internet: bob@acornrc.UUCP
Usenet: ...!{ ames | decwrl | oliveb }!acornrc!bob
Arpanet: bob%acornrc.UUCP@AMES.ARPAberry@solaria.UUCP (02/12/87)
In article <288@acornrc.UUCP> bob@acornrc.UUCP (Bob Weissman) writes: > System administrators would have >to sweep the entire disk for setuid root programs every time a user was >de-authorized. System administrators should do this *anyway* on a regular basis. Good security is *not* easy! -- "We can't stand around doing nothing -- people will think we're workmen!" Prof. Ned Quatermass -- Berry Kercheval -- berry@mordor.s1.gov -- {ucbvax!decwrl,siesmo}!mordor!berry Lawrence Livermore National Laboratory, Special Studies Program ("O" division)
hedrick@topaz.UUCP (02/12/87)
>.. System administrators would have >to sweep the entire disk for setuid root programs every time a user was >de-authorized. And I've seen complaints from people who find it a chore to >change the root password! Careful system administrators use "find" to look at all setuid and setgid programs on a regular basis. It's not a big chore. That's what programs are for.
tcm@sun.UUCP (02/12/87)
A quick and easy way to get most of the advantages of improved su programs
involves only adding new entries to /etc/passwd. An example file might be:
root:*:0:1: .....
tcmsu:khjasdfghjdf:0:1: .......
tcm:mvbnczxvczxv:100:110: .......
Each person entitled to be root gets two entries in /etc/passwd
Some paranoid shell scripts which check for userid "root" cause problems,
but I was able to work as system administrator for an HP-UX (Sys V flavor)
set up as above.
Terrence Miller
tcm@sun.comchris@mimsy.UUCP (02/12/87)
>>.. System administrators would have to sweep the entire disk for >>setuid root programs every time a user was de-authorized. In article <9150@topaz.RUTGERS.EDU> hedrick@topaz.RUTGERS.EDU (Charles Hedrick) writes: >Careful system administrators use "find" to look at all setuid and >setgid programs on a regular basis. It's not a big chore. That's >what programs are for. Your `find' has been doctored. Your compiler has been hacked; when you compile it, it inserts code that recognises itself and find. Want more? Ask Ken Thompson. All you can decide is how much effort to spend on security. The more effort, the more security, but one approaches `secure' only asymptotically. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu
jc@cdx39.UUCP (02/12/87)
> >to sweep the entire disk for setuid root programs every time a user was > > Careful system administrators use "find" to look at all setuid and > setgid programs on a regular basis. This pairing is a nice illustration of something I've found to be a problem on a lot of systems. Many security discussions include warnings about "setuid" programs being inherent security risks, when the warning should be that "setuid root" programs are risky. It is certainly understandable that people try to save words, but this particular shorthand has a rather undesirable effect. There are a lot of sysadmins that take such warnings at face value, and hunt down all setuid (to non-root ids) programs on their systems, harassing their owners until they are changed. The result is often a real decrease in system security. The fact is that programs that are setuid to non-super-users are very useful for increasing system security. This is done by uucp, for instance, and it reasonably effective. The recent 'append' program in net.sources is a nice example of a setuid program that can significantly improve system security while increasing sharing among its users. But asserting that all setuid programs are security risks and must be eliminated is not helpful. This newsgroup is probably not the right one for a discussion of security topics. When do we get a comp.security newsgroup? And maybe a comp.security.usg, comp.security.bsd, comp.security.vms, comp.security.ibm-pc (:-) and so on? Anyone wanna set one up? Or has this one been discussed to death already? [I would, but I'm in the middle of a job switch right now, so it's not a very opportune moment.] -- John M Chambers Phone: 617/364-2000x7304 Email: ...{adelie,bu-cs,harvax,inmet,mcsbos,mit-eddie,mot[bos]}!cdx39!{jc,news,root,usenet,uucp} Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193 Clever-Saying: Uucp me out of here, Scotty; there's no AI on this node!
kimcm@olamb.UUCP (02/13/87)
In article <608@vu-vlsi.UUCP>, perry@vu-vlsi.UUCP (Rick Perry) writes: : In article <263@aramis.RUTGERS.EDU> mende@aramis.RUTGERS.EDU (Bob Mende) writes: : > : >> Below is included a nice little feature program, it can be used as an : >> alternative to su(1) or in conjunction with it. : > : > Here at rutgers we have a local hack that is called slide. Slide : >is a program that can be as simple as : : Both of these programs (performing password-free su) seem dangerous : to me- if one of the authorized users were to accidently leave themself : logged on, anyone could come along and su from their terminal. Also, : it makes the knowledge of an authorized sus/slide users password : equivalent to knowing the root password. : : ...Rick ..{cbmvax,pyrnj,bpa}!vu-vlsi!perry : perry@vuvaxcom.bitnet So what! as a SA you'll have to put you faith in people you give your trust. The exact same thing could happen if you allow them to have the super-user's password, and what have you gained a more complicated scenario. Look at it this way: The people you give a simple and quick way to shift between being themeselves and superuser, is less likely to run a permanent super-user shell, thus reducing the risk of disasterous commands as rm'ing everything. I wrote the sus program to allow certain users (especially myself as SA) to just execute an arbitrary command as superuser and then return to myself, or if that wouldn't suffice run a shell. But the hassle of giving password each and everytime you want to remove garbage log-files wasn't worth leaving the su(1)'ed shell so I just went on using the su-shell instead of running as an unpriviledged user whenever possible! I know I'm kind of lazy but aren't you? The sus/slide approach also gives you the freedom to change the super-user password as often as you like without having to inform the whole staff about the new password, thus keeping the superuser passwd even more secure I admit that sus, should never be allowed to be called from a dialup-terminal, but just as the list of users who is allowed to use the program a list of terminals from where it is allowed to use the program would be a great help. This also solves some of the problems where people accidently leaves their sus'ed terminal, because most SA's terminals are separated from the casual user's terminals (in another room). At last you're absolutely free to just make one entry in the allow file, for yourself the SA - the program isn't meant to allow every user to become root. If other users call the program it will act just as the normal su(1) cmd. Kindly Regards Kim Chr. Madsen
mouse@mcgill-vision.UUCP (02/20/87)
In article <288@acornrc.UUCP>, bob@acornrc.UUCP (Bob Weissman) writes: > I've seen all these variations on 'su' flying across the net. None > of them are secure; No system with a superuser is ever really secure. Actually, make that: No system is ever really secure. > they all seem to ignore the fact that once an authorized user has > superuser privileges, he can do *anything*. > For example, what's to prevent the su-ed user from copying the source > to the original su, taking out the password check, and installing the > resulting program somewhere where he can get to it later? Absolutely nothing. Except, of course, threat of various possible forms of retalitory action (how'd you like to find your entire thesis crypted? Or just plain gone?). > System administrators would have to sweep the entire disk for setuid > root programs every time a user was de-authorized. And I've seen > complaints from people who find it a chore to change the root > password! If you care enough about security to worry about "authorized" and "unauthorized" super-users you should be sweeping for suid root programs regularly *anyway*. At a minimum. > Bottom line: once a superuser, always -- potentially -- a superuser. True. As someone else said, you can only approach a "secure" system; such a system exists only in the limit, not in the real world. However, you can make it fairly tough to keep su status - but you will have quite a time stopping someone who's good enough to doctor the C compiler as outlined by one of the Original UNIX Gurus (Ken Thompson was it?). What it comes down to is: you must not, ever, give su access to any person you can't trust with it. Because, as you point out, once they have it you can't stop 'em. der Mouse USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!musocs!mcgill-vision!mouse think!mosart!mcgill-vision!mouse Europe: mcvax!decvax!utcsri!musocs!mcgill-vision!mouse ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu