barba@ALMSA-1.arpa (02/03/87)
Need some help. I would like to develop a c program which will check an authorization table of users PRIOR to execution of the 'su' command. Ideally this program will allow the user to logon as usual, however, if the user keys in the 'su' command (root privileges) the userid will be checked against a table of authorized users. Should the userid be invalid, the system will respond with a "sorry, not authorized" type of response and either exit from the system or bring the user back to a $ prompt. If the userid is valid the program continues and executes the 'su' program. Does this type of program already exist? We are currently running under BRL VAX UNIX [4.2BSD]. Any ideas would be appreciated. Thanks, Barb Archambault
rgoguen@MIKEY.BBN.COM (02/03/87)
Barbara Under 4.3bsd, If you are NOT in group wheel (I think), you are denied access to root privillages, even if you have the correct passwd. /rjg
ron@BRL.ARPA (02/03/87)
If you use the latest version of BRL VAX UNIX which is just about to be released (or BSD 4.3 which it is based on). The use of the "su" program is restricted to people who are listed in the /etc/group file as being in the "0" group. =Ron
jxs7451@ritcv.UUCP (jeff) (02/04/87)
In article <4212@brl-adm.ARPA> ron@BRL.ARPA (Ron Natalie) writes: >"su" program is restricted to people who are listed in the /etc/group >file as being in the "0" group. Not quite, People of group 1(adm here, 0 is now default) are the only ones able to su to root. su can still be used to su to other users. When a user in not of group 1, then it rejects the command before a passwd is asked for to. (4.3 on 780). Jeff ritcv!jxs7451
rgenter@j.bbn.COM (02/05/87)
A program to check a table of users to see if they are authorized to execute 'su' is of limited utility, if any. If a user has the root password and they are excluded from running 'su', there is nothing to prevent them from just running 'login' and logging in as the superuser. If you are going to modify 'su', you might as well modify 'login' as well, perhaps to ask a second password or to check from which terminal the login is being attempted (except that I believe System V already does this through the use of /etc/securetty?). - Rick -------- Rick Genter BBN Laboratories Inc. (617) 497-3848 10 Moulton St. 6/512 rgenter@bbn.COM (Internet new) Cambridge, MA 02238 rgenter@bbnj.ARPA (Internet old) seismo!bbn.com!rgenter (UUCP)
guy@gorodish.UUCP (02/05/87)
>>"su" program is restricted to people who are listed in the /etc/group >>file as being in the "0" group. > >Not quite, People of group 1(adm here, 0 is now default) are the only >ones able to su to root. Ron's right, you're wrong. From the vanilla 4.3BSD "su.c": /* * Only allow those in group zero to su to root. */ if (pwd->pw_uid == 0) { struct group *gr; int i; if ((gr = getgrgid(0)) != NULL) { for (i = 0; gr->gr_mem[i] != NULL; i++) if (strcmp(buf, gr->gr_mem[i]) == 0) goto userok; fprintf(stderr, "You do not have permission to su %s\n", user); exit(1); } userok: setpriority(PRIO_PROCESS, 0, -2); }
guy@gorodish.UUCP (02/06/87)
>A program to check a table of users to see if they are authorized to >execute 'su' is of limited utility, if any. If a user has the root >password and they are excluded from running 'su', there is nothing to >prevent them from just running 'login' and logging in as the superuser. Actually, there is something to prevent them from doing that; give them a ".login" or ".profile" that blows a raspberry and exits. Of course, if you have an "su" that supports an option that says "run the new shell as a login shell", this won't work. >If you are going to modify 'su', you might as well modify 'login' as >well, perhaps to ask a second password or to check from which terminal >the login is being attempted (except that I believe System V already >does this through the use of /etc/securetty?). 4.2BSD does, 4.3BSD uses "/etc/ttys" instead, System V doesn't. S5's "login", at least in S5R3, is built with an option that only allows root logins on "/dev/console". 4.3BSD's "login" also will call "syslog" to log a message indicating that somebody has logged in as the super-user.
loverso@sunybcs.UUCP (02/08/87)
In article <4193@brl-adm.ARPA> barba@ALMSA-1.arpa (Barbara Archambault) writes: > Need some help. I would like to develop a c program which will check an > authorization table of users PRIOR to execution of the 'su' command. > > Ideally this program will allow the user to logon as usual, however, if > the user keys in the 'su' command (root privileges) the userid will be > checked against a table of authorized users. Should the userid be invalid, > the system will respond with a "sorry, not authorized" type of response and > either exit from the system or bring the user back to a $ prompt. If > the userid is valid the program continues and executes the 'su' program. We've got a locally developed program called "sudo" that does just this. It was posted to net.sources sometime last summer, I believe. I reads a permission file of who's allowed to execute what, and logs all sucessful and failed commands (in separate logs). An example sudoers file: coggs all colonel all forys all howlett all kensmith all loverso all operator PATH=/etc:/usr/ucb:/bin:/usr/local/bin dump inetd kill lpc lprm netwall restore rdump renice rrestore shutdown wall /etc/dump /etc/inetd /etc/restore phillips all soon /bin/passwd sue all tim all sudo does various checking with path variables and explicit paths. "all" means the user is allowed to execute anything. As our local version stands, if you are in the sudoers file, then once logged in you can sudo at will. This opens *some* possible security holes with insecure hosts. UC/Boulder runs a hacked version which asks for your passwd upon your first sudo command, and then you can sudo at-will until a time limit of no sudo'd commands is reached (default=5 mins), after which your next sudo will reprompt for your passwd. This handles some problems (like leaving terminals unattended), but adds others. sunybcs!sue and sunybcs!tim will fill mail requests for the source. If demand warrents, it could be sent to mod.sources. John -- John Robert LoVerso @ SUNY/Buffalo Computer Science (716-636-3190) LoVerso@Buffalo.EDU -or- ..!{nike,watmath,allegra,decvax}!sunybcs!loverso
kimcm@olamb.UUCP (02/13/87)
In article <4263@brl-adm.ARPA>, rgenter@j.bbn.COM (Rick Genter) writes: > A program to check a table of users to see if they are authorized to > execute 'su' is of limited utility, if any. If a user has the root > password and they are excluded from running 'su', there is nothing to > prevent them from just running 'login' and logging in as the superuser. > If you are going to modify 'su', you might as well modify 'login' as > well, perhaps to ask a second password or to check from which terminal > the login is being attempted (except that I believe System V already > does this through the use of /etc/securetty?). > - Rick [1] If a user has the root password he can do what he want's to including putting himself on the list of allowed su users. But that's not the point. A user in the su allowed group doesn't have to know the root password. There's nothing that prevents modifying the su program to check the tty from where the su is attempted to see whether it is a securetty, I believe that even would be a win. thereby you'll prevent super-user sessions from unwanted ttys such as dial in lines etc. [2] The system V approach (at least on my 3B computer) is even more restrictive with root login's. No it doesn't follow the BSD standard with /etc/securetty, but have hardcoded into the login program that root is only allowed to log in on the console. Too bad if you like me doesn't have the source code, yes you can make a new login program that have all the "nasty" & nice features of BSD systems like /etc/securetty ~/.hushlogin /etc/nologin etc... Kindly Regards Kim Chr. Madsen
arosen@ulowell.UUCP (02/19/87)
>[1] If a user has the root password he can do what he want's to... > There's nothing that prevents modifying the su program to > check the tty from where the su is attempted to see whether it is a > securetty... An unauthorized user with the root password can do nothing if: 1: Root logins are restricted to the console. (This, of course, assumes the console is physically protected from unauthorized users). 2: SU has been modified to allow only certain users to 'su root'. The user needs the root password and a way to get a root shell. If these two restrictions are put on a system, it won't let him in anywhere even with the password. UUCP : wanginst!ulowell!arosen USnail: Andy Rosen ULowell, Box #3031 Lowell, Ma 01854