Traditional UNIX administration limitations

root administrative account

Traditionally, AIX and other UNIX operating systems have defined a single system administrator account named root (normally designated with a UID of 0) that can perform all privileged system administration tasks on the system. Reliance on a single user for all system administration tasks is a problem in regard to the separation of duties. While a single administrative account is acceptable in certain environments, many environments require multiple administrators, with each administrator responsible for different system administration tasks.

In order to share the administration responsibilities with multiple users of the system, the historical practice was to either share the password of the root user or create another user with the same UID as the root user. This method of sharing system administration duties presents security issues, since each administrator has complete system control and there is no method to limit the operations that an administrator can perform. Since the root user is the most privileged user, root users can perform unauthorized operations and can also erase any audits of these activities, making it impossible to track these administrative actions.

Privilege escalation through SUID

Access control in UNIX operating systems has historically been performed by using the UID associated with the process to determine access. However, the root UID of 0 has traditionally been allowed to bypass permission checks. Therefore, a process that is running as the root user can pass any access checks and perform any operation. This is a security issue for the UNIX concept of setuid applications.

The setuid concept allows a command to run under a different identity then the user who invoked the command. This is necessary when a normal user needs to accomplish a privileged task. An example of this is the AIX passwd command. Since a normal user does not have access to the file that stores user passwords, an additional privilege is needed to change the user's password, so the passwd command is setuid to the root user. When a normal user runs the passwd command, it appears to the operating system that the root user is accessing the file and the access is granted.

While this concept does provide the desired functionality, it carries with it an inherent risk. Since the setuid program is effectively running in the root context, if an attacker successfully takes over the program before it exits, then the attacker has all of the powers of root and can then bypass all operating system access checks and perform all operations. A better solution is to only assign a subset of the root user privileges to the program so that the Least privilege principle is followed and the threat is mitigated.