Improving systems security

World Oil, Oct, 2000 by Will Morse

SET-UID PROGRAMS

A set-uid program runs as owner of the program file rather than as the program user. Programs owned by root are the problem. Some programs have to be set-uid to do their job. You might not need that job to be done, however. A good example would be ufsdump and ufsrestore. If you use a tape backup system such as Veritas Netbackup, make ufsdump and ufsrestore non-root and turn off the set-uid and setgid and execute permissions. The same for other set-uid programs you do not use. You can always turn them back on if you need them.

Never permit shell scripts to be set-uid. It is NOT a good idea to execute shell scripts as root, even if you are driving. A shell script may call a compromised (Trojaned) program, which could then be executed as root. Make sure all shell scripts that might be run as root specify the PATH--even better, a hardcoded path--for each command. Make sure environment variables like IFS and ENV are unset. If you must use csh, make sure to specify the "-f" option to avoid reading a .cshrc or .login that may be compromised.

SUDO/SUPERUSER ACCESS PROGRAMS

Sudo and other limited superuser access programs use a rule base of permissions to allow an otherwise unprivileged user to perform tasks that normally require root privilege. For example, a normal data administrator may need to switch user to an Oracle account for certain maintenance work. Rather than give him the Oracle user password or the superuser password, just create a rule like:

Joeuser elvis:/bin/su - oracle

The user can type su - oracle (but only on system elvis), and sudo will let this happen. The user (joeuser) will have to enter his own password, not the Oracle password. The Oracle password can be changed from time to time without this user needing to know it. The password can be something hard to guess and the user won't need to write it on a yellow sticky pad.

There are important things to watch out for when using sudo. Never let a user use vi or more as superuser, because you can "shell out" of these programs and that will be a root shell. You could also use the sudo vito change/etc/passwd or other files that would defeat security.

You can make patterns with sudo that will prevent a lot of security problems. For instance, it is common for data administrators to need chmod and chown. You can give them a rule such as:

Joeuser elvis:/bin/chmod 770 /data*

This gives joeuser the ability to change permissions on elvis to 770, but only in directories starting with /data, which of course excludes /etc and /usr.

HOSTS.EQUIV AND .RHOSTS

Books on security recommend eliminating /etc/hosts.equiv and [sim]/.rhosts. Other authors suggest that, since there is nothing you can do to prevent a user from putting a .rhosts file in his home directory, you allow this method for users who actually require this feature rather than making it generally available using /etc/hosts. equiv.

Some authorities recommend avoiding wildcards (plus signs) in the hosts.equiv or .rhosts files. The problem with this is that you have to explicitly list each computer name and user on individual lines on each computer. For a network of any size, this quickly becomes completely unworkable and cannot be kept current.