Rootly Powers Chapter 3

Chapter 3 - Rootly Powers Introduction Every file and process on a UNIX system is owned by a particular user account. Other users can’t access these objets without the owner’s permission. System files and processes are owned by a fictitious user called “root”, also known as the superuser. To make administrative changes, you’ll need to use one of the methods of accessing the root account described in this chapter. Chapter 3 - Rootly Powers

Chapter 3 - Rootly Powers Introduction The root account has several “magic” properties. Root can act as the owner of any file or process. Root can also perform several special operations that are off-limits to other users. The account is both very powerful and, in untrained or malicious hands, very dangerous. This chapter introduces the basics of superuser access for administration. Chapter 21 - Security - describes how to avoid unwanted and embarrassing superuser access by others Chapter 27 - Policy and Politics - covers the relevant political and administrative aspects. Chapter 3 - Rootly Powers

1. Ownership of Files and Processes Every UNIX file has both an owner and a “group owner” The owner of the file enjoys one special privilege that is not shared with everyone on the system The ability to modify the permission of the file. We will take up the subject of permissions in Chapter 5 - The Filesystem. While the owner of a file is always a single person, many people may be group owners of the file, so long as they are all part of a single UNIX group. Groups are defined in the /etc/group file Chapter 3 - Rootly Powers

1. Ownership of Files and Processes UNIX actually keeps track of owners and groups as numbers rather than as text names. UID’s are mapped to user names in the /etc/passwd file GID’s are mapped to group names in /etc/group The text names are only defined for the convenience of the system’s human users. So, when commands such as ls want to display ownership information in a human-readable format, they must look up each name in the appropriate file or database. Chapter 3 - Rootly Powers

1. Ownership of Files and Processes Processes have not two but four identities associated with them A real and effective UID A real and effective GID The real are used for accounting and the effective are used for the determination of access permissions. Normally the real and effective are the same. Chapter 3 - Rootly Powers

1. Ownership of Files and Processes While it is not normally possible for a process to alter its four ownership credentials, there is a special situation in which the effective user and group IDs may be changed. When a command is executed that has its setuid or setgid permission bit set, the effective UID or GID of the resulting process may be set to the UID or GID of the file containing the program rather than the UID or GID of the user that ran the command. The identity of the process is thus “promoted” for that specific command. Chapter 3 - Rootly Powers

1. Ownership of Files and Processes The setuid facility allows programs run by ordinary users to make use of the root account in a limited and tightly controlled way. For example: the passwd command is a setuid program. It modifies the /etc/passwd file in a well defined way and then terminates. Chapter 3 - Rootly Powers

Chapter 3 - Rootly Powers 2. The Superuser The defining characteristic of the root account is its UID of 0. UNIX does not prevent you from changing the username on this account or from creating additional accounts whose UIDs are 0, but both actions are very bad ideas. Such changes have a tendency to create inadvertent breaches of system security. They also engender confusion and scorn from other people who have to deal with the strange way you’ve configured your system. Chapter 3 - Rootly Powers

Chapter 3 - Rootly Powers 2. The Superuser UNIX permits the superuser to perform any valid operation on any file or process. In addition, some system calls may be executed only by the superuser Changing the root directory of a process with chroot Creating device files Setting the system clock Raising resource usage limits and process priorities Setting the system’s hostname Configuring network interfaces Shutting down the system Chapter 3 - Rootly Powers

Chapter 3 - Rootly Powers 2. The Superuser An example of superuser powers is the ability of a process owned by root to change its UID and GID. The login program is a case in point. The process that prompts you for your password when you log in to the system is initially run as root. If the password and username that you enter are legitimate, login changes its UID and GID to your UID and GID and executes your shell. Once a root process has changed its ownerships to become a normal user process, it can’t recover its former privileged state. Chapter 3 - Rootly Powers

3. Choosing a Root Password What should be said here…. It should be secure You should change the root password At least every three months or so. Every time someone who knows the password leaves your site Whenever you think security may have been compromised Chapter 3 - Rootly Powers

Chapter 3 - Rootly Powers 4. Becoming Root Introduction Logging in directly as root leaves no record no record of what was done or who did it (if multiple people work on the system) or when they did it…. For these reasons, most systems allow root logins to be disabled on terminals and across the network (everywhere except the system console) See secure terminals - Chapter 21 - to find out how to do this. Chapter 3 - Rootly Powers

Chapter 3 - Rootly Powers 4. Becoming Root su: substitute user identity a slightly better way to access the root command is the su command without any parameters it asks for the root password. su username asks for the password for username On many systems, you must be a member of the group “wheel” in order to use su Chapter 3 - Rootly Powers

Chapter 3 - Rootly Powers 4. Becoming Root sudo: a limited su Since the privileges of the superuser account cannot be subdivided, it is hard to give someone the ability to do one task (backups for example) without giving that person free run of the system. One solution to these problems is a program called sudo sudo checks the user, and the argument (command to run) with the file /etc/sudoers If they are there sudo prompts for the user’s own password. Chapter 3 - Rootly Powers

Chapter 3 - Rootly Powers 4. Becoming Root sudo keeps a log of the command lines that were executed the people who requested them the directory they were run in the times at which they were invoked Chapter 3 - Rootly Powers

Chapter 3 - Rootly Powers 4. Becoming Root The use of sudo has the following advantages Accountability is much improved Operators can do chores without unlimited root privileges The real root password can be known to only one or two people. It’s faster to use sudo than to run su or to login as root. Privileges can be revoked without the need to change the root password. 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. Chapter 3 - Rootly Powers

Chapter 3 - Rootly Powers 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 is common 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 Let’s look at some of these pseudo-users Chapter 3 - Rootly Powers

Chapter 3 - Rootly Powers 5. Other Pseudo-Users daemon: owner of unprivileged system software Usually 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 helps avoid some security hazards. There is also a UNIX group called “daemon” that exists for similar reasons Chapter 3 - Rootly Powers

Chapter 3 - Rootly Powers 5. Other Pseudo-Users 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 Dedicating a special account to this task is often regarded as superfluous (or perhaps even slightly insecure) most modern systems generally use the root account. Chapter 3 - Rootly Powers

Chapter 3 - Rootly Powers 5. Other Pseudo-Users sys: owner of the kernel and memory images On some systems the user sys owns special files such as /dev/kmem - Kernel’s address space /dev/mem - physical memory of the system /dev/drum or /dev/swap - an image of the system’s swap space On some systems, a group called “kmem” or “sys” is used instead of a “sys” user account. Chapter 3 - Rootly Powers

Chapter 3 - Rootly Powers 5. Other Pseudo-Users nobody: the generic NFS user Most versions of UNIX define a user called nobody with UID -1 or -2 See Chapter 17 for more info on Nobody Typically used to represent root on other systems Some daemons, such as fingerd, run as nobody nobody should NOT own any files…. Chapter 3 - Rootly Powers

Chapter 3 - Rootly Powers