5. Users, Identity and Access Control

Introduction and Context

Linux is a multiuser operating system. Its security model assumes that many people, services, applications, and automated processes may use the same kernel and storage resources, often at the same time. The operating system therefore needs more than a login screen: it must establish who or what is requesting access, determine what that identity is permitted to do, record relevant activity, and prevent a compromised process from acquiring unnecessary authority.

These responsibilities are commonly described through the security objectives of identification, authentication, authorization, and accountability. Identification claims an identity, authentication verifies the claim, authorization evaluates permissions, and accounting records activity. In Linux, these functions are implemented through users and groups, file ownership and mode bits, Pluggable Authentication Modules (PAM), sudo, access-control lists, capabilities, directory services, and, where required, mandatory access-control frameworks such as SELinux or AppArmor.

The distinction between discretionary access control (DAC) and mandatory access control (MAC) is particularly important. Traditional Linux permissions are primarily discretionary: the owner of an object, subject to administrative authority, can often change its permissions. MAC systems apply centrally defined security policies that users cannot freely override. Effective Linux security depends not on one mechanism but on the interaction of several layers.

Learning Objectives

After studying this chapter, the student should be able to:

• distinguish identification, authentication, authorization, and accounting;
• explain Linux users, groups, UIDs, GIDs, supplementary groups, and service identities;
• interpret ownership, mode bits, special permission bits, umask, and ACLs;
• describe PAM authentication stacks and the role of NSS in identity lookup;
• design controlled administrative access with sudo;
• explain Linux capabilities and their relationship to least privilege;
• compare DAC, MAC, and role-based approaches to access control;
• integrate Linux hosts with centralized identity services;
• evaluate security risks, operational trade-offs, and governance requirements.

Identity in the Linux Operating System

A Linux account has both a human or organizational meaning and a kernel-level representation. The kernel identifies processes and file owners primarily through numeric user IDs (UIDs) and group IDs (GIDs), not through names. Names such as `alice` and `developers` are resolved by user-space libraries using local files or network information services.

The local account database is commonly represented by `/etc/passwd`, while password hashes are stored in the protected `/etc/shadow` file. A passwd entry contains an account name, UID, primary GID, descriptive information, home directory, and login shell. The shadow database contains password-aging and password-hash information and should not be readable by ordinary users. Group definitions are commonly stored in `/etc/group`, with protected group information in `/etc/gshadow` on systems that use it.

The root account traditionally has UID 0 and is not constrained by ordinary file permission checks in the same way as regular users. This power makes direct root login, especially over a network, a significant risk. Modern administration normally uses individual accounts combined with narrowly controlled `sudo` privileges, providing attribution and reducing the time during which elevated authority is active.

A process normally has a real UID, an effective UID, and sometimes a saved-set UID. The real UID identifies the account that started the process; the effective UID is central to permission decisions. Set-user-ID programs can run with the effective identity of their owner, which is useful for carefully designed utilities but dangerous when vulnerabilities exist. Similar concepts apply to group IDs. Administrators should treat set-ID binaries as sensitive assets and regularly audit them.

Groups support collective authorization. A user has one primary group and may have supplementary groups. The command `id` displays effective identity information, while `getent passwd`, `getent group`, and `getent passwd username` query the configured identity sources. Group membership should represent job responsibilities rather than convenience. A user placed in groups such as `sudo`, `docker`, or storage-administration groups may acquire authority far beyond what the group name suggests.

Service accounts represent daemons and applications. A well-designed service account has no interactive shell, no unnecessary home directory, and access only to the files, devices, sockets, and capabilities required by the service. Separating service identities improves containment and auditing: compromise of one service need not automatically expose another.

Authentication: From Login Attempt to Session

Authentication verifies an identity claim. Linux supports passwords, public-key authentication, hardware-backed credentials, smart cards, certificates, one-time passwords, and federated mechanisms. Strong authentication is not merely a matter of password length; it also depends on protecting credential storage, resisting online guessing, managing recovery, and requiring additional factors for high-risk operations.

PAM provides a modular framework for authentication and related account decisions. Applications such as `login`, `sshd`, `sudo`, and display managers call PAM rather than implementing all authentication logic themselves. PAM configuration is organized around management groups:

• auth verifies credentials;
• account determines whether the account is permitted to authenticate, considering expiration or access restrictions;
• password changes credentials and applies password policies;
• session performs actions when a session opens or closes, such as resource limits or audit setup.

PAM modules are arranged in a stack. Control flags such as `required`, `requisite`, `sufficient`, and `optional` affect how results are combined. A `required` failure is recorded but the stack may continue, whereas `requisite` generally stops processing immediately. The exact behavior is configuration-dependent; administrators should not modify PAM files without testing a recovery path. A syntactically valid but logically incorrect PAM configuration can lock out every administrator.

PAM is an authentication and account-policy framework, not a complete authorization model. It can help enforce multifactor authentication, account restrictions, and session policies, but file access remains governed by other mechanisms. Authentication configuration should be managed through distribution-supported tools where available, protected by version control, and tested from an independent session.

Linux also separates identity lookup from authentication. The Name Service Switch (NSS), configured through `/etc/nsswitch.conf`, determines where users, groups, hosts, and other information are obtained. A system may consult local files first and then LDAP, Active Directory-compatible services, or other sources. PAM may authenticate a user through one mechanism while NSS obtains the corresponding UID, group memberships, and home-directory information through another. This separation is powerful but can create confusing failures when services disagree about identity data.

Authorization Through Files and Objects

Every file and directory has an owner UID, group GID, and permission mode. For ordinary files, read permits obtaining contents, write permits modification, and execute permits execution. For directories, read permits listing names, write permits creating or removing directory entries, and execute permits traversal and access to entries whose names are known. Directory permissions are therefore not simply a larger version of file permissions.

The familiar mode string, such as `-rwxr-x---`, contains permissions for owner, group, and others. The kernel evaluates the relevant class rather than combining all classes. If the process owner matches the file owner, owner permissions apply; otherwise, if one of the process's groups matches the file group, group permissions apply; otherwise, other permissions apply. This explains why adding a user to a group does not necessarily add permissions when the owner class already matches.

The `chmod`, `chown`, and `chgrp` commands modify modes and ownership. Administrators should avoid broad recursive commands such as `chmod -R 777`, because they destroy meaningful distinctions between readers, writers, and executors. The principle of least privilege favors explicit ownership and group design, private home directories where appropriate, and directories with controlled inheritance.

The set-user-ID and set-group-ID bits cause an executable to run with the file owner's or group’s effective identity. On a directory, set-group-ID commonly causes newly created entries to inherit the directory’s group, which is useful for collaborative project directories. The sticky bit on a directory restricts deletion or renaming of entries to the entry owner, directory owner, or privileged administrator; `/tmp` is a familiar example.

The umask removes permission bits during object creation. It does not add permissions; it masks them from the application’s requested defaults. A security-conscious umask helps prevent newly created files from being readable or writable by unintended users, but it does not replace deliberate directory and ACL design.

ACLs and More Expressive File Policies

Traditional mode bits provide only one owner, one group class, and others. POSIX access-control lists extend this model with named users and groups. The commands `getfacl` and `setfacl` inspect and modify ACLs. A named ACL entry may grant a particular user access without changing the file’s owner. The ACL mask limits the effective permissions of named users, named groups, and the owning group; overlooking the mask is a common administrative error.

Default ACLs on directories define inherited permissions for newly created files and subdirectories. They are useful for shared workspaces, but inheritance does not eliminate the need to understand application umasks and file-creation behavior. ACLs can also make authorization difficult to review because the mode string may not reveal the complete policy. When ACLs are used, they should be documented, audited, and included in backup and migration procedures.

Sudo and Controlled Administration

`sudo` allows an authorized user to run a command as another identity, normally root. It is superior to shared root passwords because it supports individual accountability, command restrictions, logging, time-limited elevation, and integration with multifactor authentication. Rules are stored in `/etc/sudoers` and files under `/etc/sudoers.d`; `visudo` should always be used to validate edits.

A sudo rule should specify the smallest practical combination of user, host, target identity, and command. Granting a user unrestricted access to an editor, interpreter, backup tool, or package manager may effectively grant unrestricted root access because such programs can execute arbitrary commands or modify protected files. Thus, command-name allowlisting alone is not always least privilege. Arguments, environment variables, writable configuration files, and symbolic links must also be considered.

Administrative design should distinguish routine operational tasks from exceptional emergency access. Logs should identify the requesting user, target account, command, time, and outcome, and should be forwarded to a protected central logging system where feasible. Periodic access reviews should remove rules that are no longer justified.

Capabilities and Least Privilege

Traditional privilege is concentrated in UID 0. Linux capabilities divide selected privileged operations into units such as `CAP_NET_BIND_SERVICE`, which permits binding to low-numbered network ports, and `CAP_DAC_READ_SEARCH`, which affects some discretionary access checks. A process can therefore receive a narrowly defined privilege without becoming fully root.

Capabilities are associated with process sets and, for executable files, with file capability metadata. Common sets include permitted, effective, inheritable, ambient, and bounding sets. Their interactions are subtle, particularly across `execve()` transitions and service managers. Tools such as `capsh` and `getcap` help inspect capability state. Capabilities reduce privilege concentration but do not automatically make a program safe: a vulnerability may still allow misuse of the granted capability.

Service managers can combine user isolation, capability bounding, filesystem restrictions, read-only paths, private temporary directories, and system-call filtering. Container runtimes also use namespaces, cgroups, capabilities, and security profiles. A container running as root inside its namespace is not automatically harmless; the host kernel and exposed capabilities remain important.

DAC, MAC, and Other Access-Control Models

DAC allows resource owners to make discretionary decisions, subject to system administration. Linux mode bits and POSIX ACLs are DAC mechanisms. DAC is flexible and familiar, but a compromised process acting under a user’s identity can often access every object that user can access.

MAC assigns security decisions to centrally managed policy. SELinux labels subjects and objects and evaluates rules based on types, domains, and transitions. AppArmor commonly associates profiles with executable paths and specifies permitted operations. In both cases, access may be denied even when DAC permissions appear to allow it. MAC is valuable for containing services and enforcing organizational policy, but it requires accurate policy design, operational expertise, and diagnostic tooling.

Role-based access control (RBAC) assigns permissions to roles, which are then assigned to users. In practice, sudo rules, directory groups, identity-management systems, and MAC policy may collectively implement role-oriented administration. Attribute-based decisions can additionally consider attributes such as department, device state, location, or data classification. These models should not be treated as mutually exclusive: a production system may use centralized groups for role assignment, DAC for ordinary files, MAC for service confinement, and sudo for administrative elevation.

Directory Integration and Centralized Identity

Organizations often manage accounts centrally using LDAP, Kerberos, Active Directory-compatible services, or identity-management platforms. Centralization reduces duplicate account administration and enables consistent group membership, password policy, and auditing. Linux clients commonly use NSS for identity lookup and PAM or Kerberos-aware components for authentication.

Integration introduces dependencies. Network availability, DNS, time synchronization, certificate trust, service-principal configuration, and failover all affect login. A workstation that cannot contact a directory service may require cached credentials or a carefully controlled local break-glass account. Such an account must be protected, monitored, and tested rather than assumed to work.

Centralized identity also changes the impact of mistakes. An incorrectly assigned group can grant access across many systems. Join procedures, privileged group management, lifecycle events, segregation of duties, and periodic recertification are therefore governance activities as well as technical tasks.

An Applied Case: Protecting a Research Computing Cluster

Background

Consider an illustrative university research cluster used by faculty, students, and automated data-processing services. Researchers collaborate in project directories, students require limited access to compute nodes, and administrators maintain the operating system. The initial deployment uses shared accounts, broad group membership, password-based SSH, and several world-writable directories.

Situation and Analysis

The arrangement creates weak attribution, excessive lateral movement, and accidental disclosure. A student who knows a shared password cannot be reliably distinguished from another user. A compromised data-processing script can read files belonging to unrelated projects. Administrators also discover that a project group has write access to a directory containing executable scripts owned by a privileged service, creating a potential privilege-escalation path.

Approach

Each person receives an individual directory-backed account with multifactor authentication for SSH. Shared accounts are removed except for narrowly justified service identities. Project membership is represented by centrally managed groups, and collaborative directories use set-group-ID directories with carefully designed ACLs and default ACLs. Service accounts receive noninteractive shells and only the capabilities and directories required by their services.

Administrative work is divided into roles. Help-desk personnel may reset passwords but cannot obtain root access. Operations staff may restart approved services through restricted sudo rules. A small platform team receives broader, audited privileges. Direct root SSH login is disabled. SELinux or an equivalent MAC profile confines exposed services, while file permissions and ACLs continue to protect ordinary project data.

The organization also establishes account joiner-mover-leaver procedures, quarterly access reviews, centralized logs, tested recovery accounts, and documented approval for exceptional access. Configuration is managed as code so that PAM, sudo, ACL, and MAC policy changes can be reviewed and reproduced.

Outcome and Learning Points

The resulting system improves attribution and reduces the blast radius of a compromised account or service. It also makes administration more complex: directory outages, ACL interpretation, and MAC denials require operational knowledge. The central lesson is that least privilege is a process of continuous design and review, not a single command. Identity data, authentication, authorization, monitoring, and governance must agree.

Risks, Limitations, and Professional Practice

Common errors include using shared accounts, granting `777` permissions, placing users in powerful convenience groups, editing PAM without a recovery plan, assuming a successful login implies authorization, and treating a passing `sudo` rule as safe without analyzing command behavior. Another frequent mistake is confusing encryption with authorization: encrypted storage protects data at rest, but it does not determine which logged-in process may read a mounted file.

Access reviews should consider dormant accounts, orphaned files, nested groups, service-account ownership, emergency credentials, and permissions inherited through ACLs or directory services. Logs should be protected against alteration and should avoid exposing passwords, tokens, or unnecessary personal data. Authentication and authorization systems process personal information, so retention, access to logs, and monitoring practices should follow institutional policy and applicable law.

Automation is valuable for provisioning, configuration validation, drift detection, and recertification. However, automation can distribute an incorrect policy at scale. Changes should be tested in nonproduction environments, reviewed by more than one person for high-impact systems, and supported by rollback procedures. Contemporary deployments increasingly combine short-lived credentials, hardware-backed authentication, policy-as-code, zero-trust principles, and continuous verification. These practices complement rather than replace sound Linux permissions and careful system administration.

Best-Practice Framework

A practical least-privilege program can be organized around five questions:

1. Who is the subject? Use unique identities, reliable directory data, and strong authentication.

2. What is the subject attempting to do? Define the resource, operation, context, and business purpose.

3. Which policy layer should decide? Use mode bits and groups for ordinary ownership, ACLs for exceptions, sudo for administrative elevation, capabilities for narrow privilege, and MAC for containment or centrally enforced policy.

4. Can the action be observed and reversed? Record administrative activity, protect logs, and maintain recovery paths.

5. Is the access still justified? Review privileges after role changes, project completion, software changes, and security incidents.

This framework prevents the common tendency to solve every access problem by adding users to a powerful group or making a directory world-writable.

Chapter Summary

Linux access control begins with identity represented by UIDs, GIDs, groups, and service accounts. Authentication verifies identity through mechanisms coordinated by PAM, while NSS resolves identity information from local or centralized sources. Authorization is implemented through ownership, mode bits, special bits, ACLs, sudo, capabilities, and MAC frameworks. DAC gives owners discretion; MAC applies centrally managed policy; role-oriented administration combines groups, sudo, and policy systems.

Effective security requires least privilege, individual accountability, controlled elevation, careful directory integration, protected logging, and periodic review. The most secure design is layered: strong authentication establishes trustworthy identity, DAC protects ordinary resources, specialized mechanisms handle exceptions, capabilities reduce privilege, and MAC confines important services. Technical controls must be supported by governance, testing, recovery planning, and professional judgment.

Key Terms

Authentication: Verification that an asserted identity is genuine.

Authorization: The decision about whether a subject may perform an operation.

Accounting: Recording actions and security-relevant events for accountability.

UID: Numeric identifier used by Linux to represent a user.

GID: Numeric identifier used to represent a group.

Supplementary group: Additional group membership used during authorization.

PAM: Modular framework for authentication, account, password, and session management.

NSS: Mechanism that selects sources for resolving users, groups, hosts, and related data.

DAC: Access control in which owners or authorized administrators can make discretionary decisions.

MAC: Centrally enforced access control that users cannot ordinarily override.

ACL: Extended permission list containing named users or groups.

Umask: Process setting that removes permission bits during object creation.

Sudo: Controlled mechanism for executing commands as another user.

Capability: A distinct unit of privileged kernel authority.

Set-user-ID: File permission feature causing an executable to use its owner’s effective UID.

Least privilege: Granting only the authority necessary for an approved task.

Service account: Identity used by an application or daemon rather than a person.

RBAC: Model in which permissions are assigned to roles and roles to users.

Review Questions

Short Answer Questions

1. Distinguish identification, authentication, authorization, and accounting.

2. Why are UIDs and GIDs more fundamental to the kernel than user and group names?

3. What functions are handled by the four major PAM management groups?

4. Explain the difference between a file ACL and a default directory ACL.

5. Why should service accounts normally have noninteractive shells?

Long Answer Questions

1. Explain how Linux users, groups, ownership, mode bits, special bits, and umask cooperate to control file access.

2. Describe PAM and NSS, emphasizing how they differ and how they interact during login.

3. Compare DAC, MAC, and RBAC, including appropriate Linux technologies and operational trade-offs.

4. Discuss how sudo and capabilities support least privilege, and explain why neither automatically guarantees security.

5. Design an access-control architecture for a multiuser university Linux server, including identity, authentication, authorization, logging, and review.

Analytical / Application Questions

1. A user has read permission through a named ACL, but the ACL mask permits only write access. Predict the effective result and explain how you would diagnose it.

2. A web service needs to bind to a low-numbered port but should not run as root. Which Linux mechanism would you consider, and what additional risks would you evaluate?

3. A directory-backed user can authenticate successfully but cannot access a project directory. Develop a systematic investigation covering NSS, group membership, DAC, ACLs, MAC, and mount or network dependencies.

22. Multiple Choice Questions with Answers

Question 1

Which Linux component primarily determines where user and group identity information is looked up?

A. PAM

B. NSS

C. sudo

D. SELinux

Correct Answer: B. NSS

Question 2

A user can authenticate successfully but is denied access to a file. Which conclusion is most accurate?

A. Authentication necessarily failed

B. Authorization is being evaluated separately from authentication

C. The UID is always zero

D. PAM has disabled all file permissions

Correct Answer: B. Authorization is being evaluated separately from authentication

Question 3

What is the principal purpose of the set-group-ID bit on a collaborative directory?

A. It encrypts all files in the directory

B. It causes new entries to inherit the directory's group

C. It prevents the owner from deleting files

D. It grants root privileges to all group members

Correct Answer: B. It causes new entries to inherit the directory's group

Question 4

Why is unrestricted sudo access to an editor potentially equivalent to full root access?

A. Editors cannot read protected files

B. Editors may provide a way to execute commands or modify protected files

C. sudo only works for text files

D. The editor automatically changes the user's UID permanently

Correct Answer: B. Editors may provide a way to execute commands or modify protected files

Question 5

Which statement best distinguishes MAC from ordinary Linux DAC?

A. MAC policies can override or deny access even when DAC permissions allow it

B. MAC is controlled entirely by the file owner

C. DAC requires security labels on every process

D. MAC applies only to passwords

Correct Answer: A. MAC policies can override or deny access even when DAC permissions allow it

Question 6

A service needs permission to bind to a low-numbered network port but does not otherwise need root authority. Which mechanism is most directly relevant?

A. A broader supplementary group

B. A Linux capability such as CAP_NET_BIND_SERVICE

C. The sticky bit

D. A default ACL on /tmp

Correct Answer: B. A Linux capability such as CAP_NET_BIND_SERVICE

Question 7

What is the main security weakness of shared human accounts?

A. They always consume excessive disk space

B. They prevent reliable individual attribution and lifecycle management

C. They cannot be used with groups

D. They automatically disable PAM

Correct Answer: B. They prevent reliable individual attribution and lifecycle management

Question 8

What does a default ACL on a directory primarily control?

A. Permissions inherited by newly created entries

B. The kernel version used by files

C. Whether users can authenticate through SSH

D. The directory's filesystem type

Correct Answer: A. Permissions inherited by newly created entries

Question 9

Which practice best protects administrators from a faulty PAM configuration?

A. Edit production PAM files without testing

B. Keep an independent recovery session and test changes before deployment

C. Remove all account restrictions permanently

D. Replace all users with root

Correct Answer: B. Keep an independent recovery session and test changes before deployment

Question 10

A user is placed in a powerful group merely to solve one narrow access problem. What principle is most clearly violated?

A. Least privilege

B. Name Service Switch

C. Data compression

D. Process scheduling

Correct Answer: A. Least privilege