jack@spock.UUCP (Jack Kingsley off) (11/22/85)
Here at Choate we have a program that allows specified users to either become root, by just typing root, or just executing a command by typing root command. This program has a crypted database of all people who are able to become root, so it is secure. There is one problem though, and that is is one of the selected people who are included in the database leave him/herself logged in, the person who finds the terminal can have free run of the system. Jack Kingsley '87 decvax!yale!spock!jack Glacier!spock!jack
jdb@mordor.UUCP (John Bruner) (11/24/85)
There is an important consideration if you have (or are considering the implementation of) a program which gives a root shell to specified users without prompting for a password. This sort of program effectively multiplies the number of passwords than can be used to obtain "root". Rather than protecting a single password, it is now necessary to protect N+1 (where N is the number of privileged users. In general, is easier to find one out of N+1 passwords than it is to determine a single password. Also, since correct setuid programs are difficult to write, you must now worry not only about setuid-root programs but also setuid-priv programs (where "priv" is any user in the privileged class). A buggy setuid-priv program might be exploited to obtain a setuid-priv shell which could then be used to obtain root. -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758 UUCP: ...!ucbvax!dual!mordor!jdb ...!seismo!mordor!jdb
peter@graffiti.UUCP (Peter da Silva) (11/27/85)
> Also, since correct setuid programs are difficult to write, you must > now worry not only about setuid-root programs but also setuid-priv > programs (where "priv" is any user in the privileged class). A > buggy setuid-priv program might be exploited to obtain a setuid-priv > shell which could then be used to obtain root. This is not the case. When you run a setuid program while you are setuid-ed to someone else, it thinks you have your original uid, not whomever you have setuid to. To demostrate this, try to perform an rmdir on someone's empty directory while you are setuid to them. This is either a bug or a feature depending on your perspective. -- Name: Peter da Silva Graphic: `-_-' UUCP: ...!shell!{graffiti,baylor}!peter IAEF: ...!kitty!baylor!peter
tim@ISM780B.UUCP (11/28/85)
For a while one place I was at did the following: There was a file that contained names of people who were allowed to be root, and encrypted passwords for each person. To become root you run a program, 'nsu', which has the same user interface as 'su' ( and much of the same insides... ), which checks to see if you are in the file, and you know the password in the file. There is a program, 'npasswd', which changes your password in the previously mentioned file. Each person who could become root would have a different password for 'nsu'ing. So to break into root, one would have to both get on the account of someone who was allowed to 'nsu', and know that persons 'nsu' password. It would be easy for it to ask also for the password of the person trying to 'nsu', so that they must know both passwords, instead of just watching you 'nsu' once, and waiting for you to leave a terminal unattended. Also, if you decide to take root access away from someone, you can simply remove them from the file. You don't have the hassle of telling everyone else the new root password. Tim Smith ima!ism780!tim ihnp4!cithep!tim
levy@ttrdc.UUCP (Daniel R. Levy) (12/03/85)
In article <476@graffiti.UUCP>, peter@graffiti.UUCP (Peter da Silva) writes: >When you run a setuid program while you are setuid-ed >to someone else, it thinks you have your original uid, not whomever you have >setuid to. To demostrate this, try to perform an rmdir on someone's empty >directory while you are setuid to them. This is either a bug or a feature >depending on your perspective. >-- >Name: Peter da Silva I noticed something else funny (peculiar etc.) with respect to this. If I am root and run cu to another system and attempt to do a ~%take from the remote, I am DENIED PERMISSION to divert except to a publicly writeable directory like /tmp !!! (cu is setuid uucp) This is when I log in on the console as root. (This points out a bug in cu anyway; it also would be nicer if upon getting the builtin ~%take sequence, cu would first check whether it is indeed possible to write or create the desired file before telling the remote to send it. I have added this feature to a cu I have running here but that's beside the point anyhow; the point is setuid.) -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!ihnp4!ttrdc!levy