UNIX System Administration Handbook - Evi Nemeth [36]
• A canonical list of all users with root privileges is maintained.
• There is less chance of a root shell being left unattended.
• A single file can be used to control access for an entire network.
There are a couple of disadvantages as well. The worst of these is that any breach in the security of a sudoer’s personal account can be equivalent to breaching the root account itself. There is not much you can do to counter this threat other than to caution your sudoers to protect their own accounts as they would the root account.
sudo’s command logging can be subverted by tricks such as shell escapes from within an allowed program or by sudo csh and sudo su if you allow them.
3.5 OTHER PSEUDO-USERS
Root is the only user that has special status in the eyes of the UNIX kernel, but several other pseudo-users are defined by the system. It’s customary to replace the encrypted password field of these special users in /etc/passwd with a star so that their accounts cannot be logged in to.
daemon: owner of unprivileged system software
The daemon account usually has UID 1. Files and processes that are part of the operating system but that need not be owned by root are often given to daemon. This convention helps to avoid the security hazards associated with ownership by root. There is also a UNIX group called “daemon” that exists for similar reasons.
bin: owner of system commands
On some systems, the bin user owns the directories that contain the system’s commands and most of the commands themselves as well. Dedicating a special user account to this task is often regarded as superfluous (or perhaps even slightly insecure), so modern systems generally just use the root account.
sys: owner of the kernel and memory images
On some systems, the user sys owns special files such as /dev/kmem, /dev/mem, and /dev/drum or /dev/swap, which are, respectively, the kernel’s address space, the physical memory of the system, and an image of the system’s swap space. Few programs access these files, but those that do run setuid to sys if this ownership convention is in use. On some systems, a group called “kmem” or “sys” is used instead of a “sys” user account.
nobody: the generic NFS user
Most versions of UNIX define a user called “nobody” with UID -1 or -2. The architects of Solaris were moved to select UID 60,001 (and to add the user “noaccess” at UID 60,002), which just shows how difficult it can be to kick the habit of gratuitous changes.
The Network File System (NFS) uses the nobody account to represent root users on other systems for purposes of file sharing. To strip remote roots of their rootly powers, the remote UID 0 has to be mapped to something other than the local UID 0. The nobody account acts as the generic alter ego for these remote roots.
See page 491 for more information about the nobody account.
Since the nobody account is supposed to represent a generic and relatively powerless user, it shouldn’t own any files. If nobody does own files, remote roots will be able to take control of them. Nobody shouldn’t own no files!
Some daemons, such as fingerd, run as nobody.
UIDs are often represented as short integers and thus -1 might appear as 32,767. This wrapping can thwart the scheme for determining the next available UID that is used by many adduser programs.
1. In fact, the permissions can be set so restrictively that even the owner of a file cannot access it, a feature that is actually more useful than it may seem.
2. Some systems no longer store this information in text files. See Chapter 18, Sharing System Files, for more information.
3. “Valid” is an important weasel word here. Certain operations (such as executing a file on which the execute permission bit is not set) are forbidden even to the superuser.
4. For the same reason, we highly recommend that you not include “.” (the current directory) in your shell’s search path. While convenient, this configuration makes it easy to inadvertently run “special” versions of system commands that a user