UNIX & Linux: Access Control & Root Powers

• Chapter 3 discusses access control and rootly powers in UNIX and Linux systems.
• The outline includes an introduction, standard UNIX access control, management of the root account, and extensions to the standard access control model.

Introduction

• Access control involves the kernel and its delegates making security-related decisions.
• It is an active research area and a major challenge in operating system design.
• UNIX and Linux have seen a Cambrian explosion of new access control options in the last decade.
• Access control is now open to change and experimentation like any other aspect of UNIX.
• The traditional access control system remains standard for UNIX and Linux and is adequatefor most installations.

Standard UNIX Access Control

• Access control depends on the user attempting an operation, or their membership in a UNIX group.
• Objects (files, processes) have owners with broad control over them.
• You own the objects you create.
• The "root" account can act as the owner of any object.
• Only root can perform certain sensitive administrative operations.
• Certain system calls (e.g., settimeofday) are restricted to root.

Standard UNIX Access Control (1)

• Other system calls (e.g., kill) involve ownership matching and special provisions for root.
• Filesystems have their own access control systems, implemented with the kernel's VFS layer.
• Filesystem access controls are generally more elaborate than those found elsewhere in the kernel.
• The kernel and filesystem are intertwined; devices are controlled through files in /dev, which are subject to filesystem access control semantics.

Standard UNIX Access Control (2)

• Every file has an owner and a group.
• The owner sets the permissions of the file.
• The owner of a file is always a single person, but many people can be group owners if they are part of the same group.
• Groups are defined in the /etc/group file.
• The owner specifies what group owners can do with the file, allowing sharing among projectmembers.
• File ownership can be determined using ls -l.
• The kernel and filesystem track owners and groups as numbers (UIDs and GIDs) rather than text names.
• UIDs are mapped to usernames in /etc/passwd, and GIDs are mapped to group names in/etc/group.

Standard UNIX Access Control (3)

• The owner of a process can send signals to the process and reduce its scheduling priority.
• Processes have a real, effective, and saved UID; and a real, effective, and saved GID.
• Linux also has a "filesystem UID" used to determine file access permissions.
• Real numbers are used for accounting, while effective numbers are used for determining access permissions.
• Saved UIDs and GIDs are parking spots for IDs not currently in use but available.
• Saved IDs allow a program to repeatedly enter and leave a privileged mode of operation.

Standard UNIX Access Control (4)

• The root account, or superuser account, has a UID of 0.
• Traditional UNIX allows a superuser (effective UID is 0) to perform any valid operation on any file or process.
• Certain operations (like executing files without execute permissions) are forbidden even to the superuser.
• Examples of restricted operations: creating device files, setting the system clock, raising resource limits, setting the hostname, configuring network interfaces, opening privileged network ports (below 1,024), and shutting down the system.
• Superuser powers include the ability of a process owned by root to change its UID and GID.

Standard UNIX Access Control (5)

• Traditional UNIX access control is complemented by an identity substitution system implemented by the kernel and filesystem.
• This allows specially marked executable files to run with elevated permissions, usually root which allows unprivileged admins and users to perform structured privileged operations.
• When the kernel runs an executable file with the "setuid" or "setgid" permission bits set, it changes the effective UID or GID of the resulting process to the UID or GID of the file containing the program image rather than the UID and GID of the user running the command.
• Privileges are promoted just for the execution of that specific command only.
• For instance, passwords must be changed by users, as user passwords are (traditionally) stored in the protected /etc/master.passwd or /etc/shadow file, and users will need a setuid passwd program to mediate their access.
• To minimize the number of setuid problems, the number of setuid programs should be minimized.

Management of the Root Account

• Root access is required mainly for system administration and security purposes, therefore proper husbandry of the root account is crucial.
• Logging in directly to the root account is not ideal.
• Root logins don't record what operations were performed as root and who was logging in as root.
• Most systems disable root logins on terminals, window systems, and across the network.
• Using the "su" command to substitute user identity to access root is preferable.
• When invoked without arguments, "su" prompts for the root password and starts a root shell.
• Root privileges persist until the shell is terminated with <Control-D> or the exit command.

Management of the Root Account (1)

• "Su" does not record the commands executed as root, but it logs who became root and when.
• The su command substitutes identities other than root, useful for reproducing/debugging user problems.
• To reproduce a user's problem, use "su" to their account to replicate their environment.
• If aware of a password for another user's account, you can access the account directly with su - username, which prompts for the user account password.
• The dash option (-) with su spawns the shell in login mode for the replaced user

Management of the Root Account (2)

• On some systems, the root password allows an su or login to any account.
• On others, you must first su explicitly to root before suing to another account; root can su to any account without entering a password.
• On most systems, you must be a member of the "wheel" group to use su.
• The su command should be kept for emergencies, such as fixing situations where sudo has been broken or misconfigured.

Management of the Root Account (3)

• sudo is a limited su, serving as the primary method to access root accounts.
• sudo takes a command line to be executed as root (or another restricted user).
• sudo consults the /etc/sudoers file to verify authorized users and their permitted commands.
• If authorized, sudo prompts for the user's password and executes the command.
• Additional sudo commands can be executed without a password for a configurable period (e.g., 5 minutes) after the initial authentication.
• This timeout serves as a protection against unattended terminals.
• sudo maintains a log of executed commands, hosts, users, directories, and invocation times logged by syslog or a file.

Management of the Root Account (4)

• Using sudo improves accountability with command logging.
• Enables users to perform specific tasks without granting unlimited root privileges.
• Limits knowledge of the root password to a few individuals.
• Using sudo is faster than su or logging in as root.
• Allows quick revocation of privileges without root password change.
• Maintains a clear list of users with root privileges through sudoers configuration.
• Reduces likelihood of unattended root shells.
• Centralizes access control for the entire network in one file (sudoers).
• Sudo downsides: any security breach in a sudoer's personal account puts root security at risk.
• Recommendations: Caution sudoers to protect their accounts, and regularly check sudoer passwords to ensure good password selections.

Management of the Root Account (5)

• The "sudo" command subdivides the priviledges of the root account, superior in some cases to many drop-in access control systems.
• Privileges can be subdivided to great precision.
• Simple to set up configurations are common and have easy maintenance and understanding.
• The "sudo" command runs on all UNIX and Linux systems and managing different solutions on different platforms is unnecessary.
• You can easily share a singular configuration file throughout a site with high-quality logging for free.
• The system is vulnerable to catastrophic compromise if the root account is penetrated, causing the potential attack access expanding to include all admin accounts.
• Is well used for administrators who need general access to root privileges.

Management of the Root Account (6)

• Root logins can be disabled entirely by setting root's encrypted password to "*" or another fixed string.
• On Linux, passwd -l locks an account by prepending ! to the encrypted password.
• The * and ! are mere conventions and not explicitly enforced, but they invalidate password hashes.
• Root cannot log in, even on the console.
• Users cannot execute su, as the action requires the root password check as well
• The root account continues to exist, and sudo works normally.

Management of the Root Account (7)

• Disabling the root account eliminates the need to record and manage root's password.
• It also reduces risk of compromised password, though rarely used passwords are already low risk.
• System accounts other than root can be identified by their low UIDs, typically less than 100 and act as sham accounts.
• UIDs under 10 are typically system accounts, while those between 10 and 100 are pseudo-users, that are associated with software.
• The encrypted password field can be replaced with a star in the shadow or master.passwd files for these special users to prevent logins.
• Their shells are set to /bin/false or /bin/nologin to prevent remote logins exploiting password alternatives, and SSH keys.

Management of the Root Account (8)

• System accounts utilize system-related groups with system-related GIDs.
• Defining pseudo-accounts and pseudo-groups is safer than using the account to provide access to resources.
• The Network File System (NFS) commonly uses “nobody” as an account to represent root users on other systems, to strip them of rootly powers.
• The remote UID 0 maps to something other than the local UID 0.
• The nobody account is a generic alter ego, powerless user, it is not allowed to own files, and if nobody does own files, remote roots can control them.

Extensions to the Standard Access Control Model

• The standard model: the root account creates a single point of failure, where the integrity of the entire system is violated.
• The only method to subdivide the priviledges of the root account is by writing setuid programs, which is challenging to secure and can become potential targets.
• The standard has limitations about the network, with no verification and trustedness in physical access to accurately represent ownerships.
• Group definition in the standard model is a privileged operation, where there is no expression for a generic user to express to alice and bob to have express to a file.
• Access control rules are often embedded in individual commands in the passwd program, and redefinition cannot happen without modifying the source code and recompilation, making it impractical and error prone.
• Auditing and logging has little and almost no support where groups do not permit tracking of elevated privileges and the operations they performed.

Extensions to the Standard Access Control Model (1)

• Pluggable Authentication Modules (PAM) provides a wrapper for authentication libraries.
• Administrators configure authentication methods and contexts.
• Programs uses the PAM system with a call that authenticates users rather than their implementation.
• PAM calls authorization that the system has appointed, and is not a access control technology.
• PAM is on components of a system and its configuration is a common administrative task.

Extensions to the Standard Access Control Model (2)

• Similar to PAM, Kerberos deals with authorization than access control and is a authentication framework used as a particular method
• PAM and Kerberos function with PAM being the wrapper and being the implementation that uses a third party.
• No authentication to the using machine is needed, other than providing your credentials to the Kerberos service.
• Key information has great usefulness to show that is a standard authentication used by Active Directory for over a decade with widespread use

Extensions to the Standard Access Control Model (3)

• Filesystem access control lists are so central to UNIX and Linux.
• Most common addition: support for access control lists (ACLs), where the general permissions are set with users/group together at once, traditional model.
• ACLs are utilized on a form of file system implementations that support major UNIX and Linux file systems.
• Support commonly utilized, with an early POSIX that never adopted, and a system standardized by NFSv4 that adapts, which adapts ACs for Windows.

Explore access control in UNIX and Linux systems, focusing on security decisions made by the kernel. Reviews standard UNIX access control and root account management. Also covers extensions to the access control model in these operating systems.