UNIX System Administration Handbook - Evi Nemeth [389]
Rootly entries
The only distinguishing feature of the root login is its UID of zero. Since there can be more than one entry in the /etc/passwd file that uses this UID, there can be more than one way to log in as root.
A common way for hackers to install a back door once they have obtained a root shell is to edit new root logins into /etc/passwd. Programs like who and w refer to the name stored in /etc/utmp rather than the UID that owns the login shell, so they cannot expose hackers that appear to be innocent users but are really logged in as UID 0.
The defense against this subterfuge is a mini-script similar to the one used for finding logins without passwords:5
perl -F: -ane ’print if not $F[2];’ /etc/passwd
This script prints out any lines in the passwd file that have null or 0 UIDs. You could easily adapt it to find entries with suspicious groups or UIDs that are the same as those of key people within your organization.
You should also check for passwd entries that have no username or that have punctuation as a username. These entries may seem nonsensical, but they will often allow a hacker to log in.
21.4 SETUID PROGRAMS
Programs that run setuid, especially ones that run setuid to root, are prone to security problems. The setuid commands distributed with UNIX are theoretically secure; however, security holes have been discovered in the past and will undoubtedly be discovered in the future.
The surest way to minimize the number of setuid problems is to minimize the number of setuid programs. Think twice before installing a software package that needs to run setuid, and avoid using the setuid facility in your own home-grown software.
Setuid shell scripts are especially apt to cause security problems. Under at least one common shell, they are automatically and entirely insecure. Shells tend to be highly customizable, which makes them relatively easy to trick. Although a shell spawned to execute a script doesn’t necessarily read the user’s shell configuration files, it can be influenced by the user’s environment, by the contents of the current directory, or by the manner in which the script is invoked.
There’s no rule that says setuid programs must run as root. If all you need to do is restrict access to a particular file or database, you can add a pseudo-user to the passwd file whose only reason for existence is to own the restricted resources. Follow the normal pseudo-user conventions: use a low UID, put a star in the password field, and make the pseudo-users’s home directory be /dev/null.
Most systems allow setuid and setgid execution to be disabled on individual filesystems through use of the -o nosuid option to mount. It’s a good idea to use this option on filesystems that contain users’ home directories or that are mounted from less trustworthy administrative domains.
It’s useful to scan your disks periodically to look for new setuid programs. A hacker who has breached the security of your system will sometimes create a private setuid shell or utility to facilitate repeat visits. Some of the tools discussed starting on page 663 will locate such files, but you can do just as well with find. For example,
/usr/bin/find / -user root -perm -4000 -print |
/bin/mail -s "Setuid root files" netadmin
will mail a list of all setuid root files to the “netadmin” user.
21.5 IMPORTANT FILE PERMISSIONS
Many files on a UNIX system must have particular permissions to avoid security problems. Some vendors ship software with permissions set for their own “friendly” development environment. These permissions may not be appropriate for you.
On some systems, the device file /dev/kmem allows access to the kernel’s own virtual address space. It is used by programs such as ps that need to look at kernel data structures. This file should only be readable by the owner and group, never by the world. Programs that need to access this file should be setgid to the group that owns the file, usually “kmem”.
In the past, a few vendors have carelessly distributed systems