ALA-R2: Access Control

ALA-R2

Access Control

Adv Linux / ALA-R2
< Course Index

Operational Briefing

Mission Context:

"Every process on your cell runs as a user. Every file belongs to a user and a group. The permission model is not complicated, but operators who cannot read it cold under pressure make mistakes that compromise the grid. This module is non-negotiable before Week 2."

User and Group Architecture

Every process runs as a user. Every file has an owner and a group. The identity of the calling process determines what files it can open, what commands it can run, and what damage it can do.

# Show current user's UID, GID, and all group memberships id # Print only the current username whoami # List all groups the current user belongs to groups # Look up a specific user's entry in /etc/passwd getent passwd operator # Look up who is in the sudo group getent group sudo

/etc/passwd format: username:x:UID:GID:comment:home:shell. The x means the hashed password lives in /etc/shadow. Service accounts typically have a shell of /usr/sbin/nologin or /bin/false to prevent interactive login.

Operational Context:

Every process on your cell runs as a user. Knowing who owns what is the foundation of every access decision you will make as an operator.

Permission Bits

The classic Unix permission model assigns read, write, and execute bits to three categories: owner, group, and others. Read the nine-character string in ls -la output as three triplets.

# Check permissions on a sensitive file ls -la /etc/shadow # Set permissions using octal notation chmod 640 /etc/myfile # Set permissions using symbolic notation chmod u+x,g-w script.sh
OctalSymbolicMeaning
755rwxr-xr-xOwner full; group + others read/execute
644rw-r--r--Owner read/write; others read-only
600rw-------Owner read/write; no access for anyone else
700rwx------Owner full; no access for anyone else
4755rwsr-xr-xSUID set: runs as file owner, not caller

Special bits: SUID (4) causes execution under the file owner's identity; SGID (2) on a directory causes new files to inherit the directory's group; Sticky (1) on a directory prevents users from deleting files they do not own (the classic use is /tmp).

Operational Context:

A misconfigured permission on a critical file is a vulnerability. Operators who cannot read rwxr-xr-- at a glance are not ready for Weeks 2-4.

Ownership: chown and chgrp

Ownership determines which permission triplet applies to a process accessing a file. Changing ownership correctly when deploying a new service is part of every cell hardening checklist.

# Change owner and group simultaneously sudo chown operator:ops /opt/cell-services/monitor.sh # Recursive ownership change for a web root sudo chown -R www-data:www-data /var/www/ # Change only the group sudo chgrp sudo /usr/local/bin/privileged-tool

Use -R (recursive) with caution on live service directories. Changing ownership recursively on /var/www/ while nginx is serving requests is safe. Doing it on /etc/ is not. Think before you run any recursive chown as root.

Operational Context:

When a new service is deployed into your cell, its files must be owned by the right service account, never by root unless unavoidable.

Access Control Lists (ACLs)

When classic permissions cannot express the access policy you need (a file readable by two users from different groups), ACLs extend the model without touching group membership.

# View the ACL on a file getfacl /etc/grid-config # Grant read access to a specific service account setfacl -m u:svc-monitor:r /var/log/cell-ops/ops.log # Set a default ACL on a directory (inherited by new files) setfacl -m d:u:operator:rwx /home/shared/ # Remove a specific ACL entry setfacl -x u:svc-monitor /path/to/file

A + at the end of ls -la output signals that an ACL is present beyond the standard bits. Use getfacl to see the full picture. The d: prefix in setfacl sets a default ACL on a directory, meaning every file created inside inherits that entry automatically.

Operational Context:

ACLs let you grant surgical read access to service accounts without changing group membership across the cell.

The sudoers File

sudo is the privilege escalation mechanism. The sudoers file defines exactly which commands each user or group may run as root or as another user. Every entry is a potential privilege escalation vector and must follow least privilege.

# Edit sudoers safely (validates syntax before saving) sudo visudo # Show what the current user is allowed to run via sudo sudo -l # Run a specific command as a service account sudo -u svc-monitor /opt/cell-services/run-check.sh

Drop-in files in /etc/sudoers.d/ are included automatically and are safer than editing /etc/sudoers directly. A NOPASSWD entry removes the password prompt and is appropriate only for automation accounts with tightly scoped commands. Granting ALL=(ALL:ALL) NOPASSWD: ALL to any account is a complete bypass of the access control model.

Operational Context:

Every sudo entry is a potential privilege escalation vector. Give only the command, not ALL.

PAM Basics (Preview for ALA-07)

Pluggable Authentication Modules (PAM) is the authentication middleware that sits between applications and the system. When you run sudo or log in via SSH, PAM decides whether to grant access by evaluating a stack of modules in order.

# The common authentication stack (Ubuntu 22.04) cat /etc/pam.d/common-auth # The sudo-specific PAM configuration cat /etc/pam.d/sudo # Per-user resource limits (sessions, processes, file sizes) cat /etc/security/limits.conf

PAM module control flags: required (must pass; failure continues the stack), requisite (must pass; failure stops immediately), sufficient (if it passes, skip remaining required modules), optional (result ignored unless it is the only module). Week 2 adds a TOTP module to this stack to implement 2FA.

Operational Context:

Week 2 implements 2FA via PAM. The PAM stack concept must not be new when it matters.

Self-Check

  1. What does the octal value 4755 mean? When is SUID appropriate and when is it dangerous?
  2. What is the difference between chmod and chown? Give a scenario where you need both.
  3. When would you use an ACL instead of changing a file's group? Give a concrete example.
  4. What is wrong with a sudoers entry that grants NOPASSWD: ALL? How would you fix it?

If you are comfortable with all of these, proceed to ALA-R3: Process Authority.