dce@mips.UUCP (02/04/87)
I have posted 3 articles to net.sources: modifications to /bin/su (described
below), manual page modifications, and a new manual page.
Some background: When I worked in commands development at Tektronix, I
implemented an idea brought up by the Small Systems Support Group, which
was to add an option to su to cause it to retain all of the current
environment, including the shell. That is, instead of me becoming user X,
using user X's shell, and other parts of X's environment, I would get
the permissions of user X, but retain my shell, aliases, home directory,
and so forth.
When I came to Mips, there existed a command called "ssu". This command
set the userid to 0 and executed "/usr/local/bin/csh" or, if commands were
given on the command line, the specified commands. The userids of the
people allowed to use the command were compiled into the code. This command
was nice, but lacked some things such as system logging and group setting.
Finally, when 4.3BSD was released, I found that it required users to be
in group wheel (group 0, for you non-BSD types) to be able to su. This was
not acceptable to us in our development environment.
Taking all of this into account, I decided to provide some new functionality
for su:
1. -e option retains the environment
2. -c option causes su to execute any arguments given after the
username directly, instead of passing them to the shell
3. If the effective groupid is 0, the user does not have to be
in group 0 (this can be effected by making su setgid(0))
4. If called as "ssu", the command line is parsed as if it was
'su -e -c root {user-supplied arguments}', so 'ssu vipw'
is the same as 'su -e -c root vipw'
5. For su'ing to root, the file /etc/su_people is searched to see
if the user can su without a password
In order to provide more security, su_people must be mode 600, owned by
userid 0, and have groupid 0. In order to aid in maintaining this file
in a network of many hosts, the su_people entries may have a list of
hosts for which the user is authorized, or a list of hosts for which the
user is not authorized.
The su_people file only applies to root, since we found that it was
easier to implement and maintain, and since you can always say something
like
ssu su -c news /usr/lib/news/expire -e 10
if you want to run expire as news.
Comments and suggestions are welcome.
--
David Elliott
UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!dce, DDD: 408-720-1700jdb@mordor.UUCP (02/05/87)
In general, you do NOT want "su" to search an "/etc/su_people". Having such a file multiplies the number of accounts which must be secured against intrusion. It is difficult enough to protect one account (root). With N entries in "/etc/su_people" there are (effectively) N root accounts which can be attacked. It is much harder to protect N passwords, N accounts' files, etc. than it is to protect a single root password and the system directories. [If you're using NFS, such a change is suicidal. NFS as distributed from Sun [even in release 3.2] can be compromised to allow a local user to read/write any non-root-only file (on an exported filesystem). It is easy to create a mode 4755 file owned by anyone (except root), which can be used to get a shell running under any user-id (bad enough), which can be used to get a root shell via a permissive "su".] -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor.s1.gov (415) 422-0758 UUCP: ...!ucbvax!decwrl!mordor!jdb ...!seismo!mordor!jdb
dce@mips.UUCP (02/07/87)
In article <1599@mordor.s1.gov> jdb@mordor.UUCP (John Bruner) writes: >In general, you do NOT want "su" to search an "/etc/su_people". >Having such a file multiplies the number of accounts which must >be secured against intrusion. It is difficult enough to protect >one account (root). With N entries in "/etc/su_people" there are >(effectively) N root accounts which can be attacked. It is much >harder to protect N passwords, N accounts' files, etc. than it is >to protect a single root password and the system directories. > I agree that these modifications can be quite dangerous, and I tried to point this out in the changes to the manual page. On the other hand, there are people that are going to want this (try convincing the people here that this command should not exist, and you'll see what I mean). A lot of the hassles we solve by using "ssu" should be solveable by using groups, but it has been felt that trying to implement groups at this time would not be worth the trouble. In any environment other than a software development environment, free root access is very bad. On the other hand, many of our customers are software developers. One thing you must admit, though, is that these modifications are a lot more manageable than the setuid shell script that says: #!/bin/sh ${SHELL-"/bin/sh"} or the setuid C program that checks a list of userid numbers and executes a shell. At least there is some semblance of "safety". I would like to thank you for pointing out the problem with NFS, and this information will certainly be found in our NFS release. -- David Elliott UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!dce, DDD: 408-720-1700
gamiddleton@watmath.UUCP (02/17/87)
In article <1599@mordor.s1.gov> jdb@mordor.UUCP (John Bruner) writes: > In general, you do NOT want "su" to search an "/etc/su_people". > Having such a file multiplies the number of accounts which must > be secured against intrusion. It is difficult enough to protect > one account (root). With N entries in "/etc/su_people" there are > (effectively) N root accounts which can be attacked. It is much > harder to protect N passwords, N accounts' files, etc. than it is > to protect a single root password and the system directories. We have made similar modifications to SU here, except that everybody in /etc/super-users (our name for the file) has their OWN password, and root itself usually has no password. So to become root, you now have to know two passwords: that of somebody in /etc/super-users, and their (private) root password. -Guy Middleton, University of Waterloo MFCF/ICR, gamiddleton@watmath