1. Rootly Powers
Chapter 3

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. Chapter 3 - Rootly Powers