Month 5: Who are you, and who said so?

PAM: one stack for every login

Pluggable Authentication Modules (PAM) let login programs (sshd, sudo, login, su) share one configurable stack instead of each coding its own password checks. Each service has a file in /etc/pam.d/. Lines have a type (auth proves identity, account checks if login is allowed now, password handles changes, session sets things up), a control flag and a module.

# /etc/pam.d/password-auth (excerpt)
auth     required    pam_env.so
auth     required    pam_faillock.so preauth
auth     sufficient  pam_unix.so
account  required    pam_unix.so
password requisite   pam_pwquality.so
session  required    pam_limits.so

Exam tip RHEL shares system-auth and password-auth (managed by authselect). Debian shares common-auth, common-password...

Control flags

required: must pass, but the stack keeps going (so attackers can't tell which module failed). requisite: must pass, and failure stops right away. sufficient: success is enough on its own if nothing required failed before it. optional: only matters if it's the only module. Useful modules: pam_unix (local passwords), pam_faillock (lockouts), pam_pwquality (strength), pam_limits (limits.conf).

Exam tip Editing PAM? Keep a root shell open in another window until you've tested a new login.

Polkit: permission for privileged actions

Polkit decides whether an unprivileged process may ask a privileged system service to do something over D-Bus: reboot, mount a disk, manage a unit, change the network. It's the reason a desktop user can shut down without sudo, and the prompt behind pkexec. Rules live in /etc/polkit-1/rules.d/ (written in JavaScript).

Sam: PAM asks 'are you really Rosa?' Polkit asks 'may Rosa do this one thing?'

Exam tip sudo = run a command as root. polkit = may this user ask that service for this action?

LDAP and Kerberos

LDAP is the protocol for directories: a tree of entries such as uid=sam,ou=people,dc=kibbleco,dc=example, holding users, groups and attributes (port 389, or 636 for LDAPS). Kerberos handles authentication with tickets: you prove your password once to the KDC, get a ticket-granting ticket (kinit, klist), and then log in to other services without sending the password again. That's single sign-on.

Exam tip Kerberos fails when clocks differ by more than about 5 minutes. Check time sync first.

SSSD, Winbind and realm

SSSD (System Security Services Daemon) connects Linux to central identity: Active Directory, FreeIPA or plain LDAP plus Kerberos. It caches credentials, so people can still log in if the directory is briefly down. realm join kibbleco.example (realmd) discovers the domain and sets up SSSD in one step. Winbind, from Samba, is the older alternative for joining Active Directory.

$ sudo realm join kibbleco.example -U admin
$ id sam@kibbleco.example
$ realm list

Samba

Samba speaks SMB, Windows' file and print sharing protocol. It shares Linux directories to Windows clients (smb.conf), mounts Windows shares on Linux, and can even act as an Active Directory domain controller. Its Winbind piece maps Windows users and groups to Linux IDs.

Exam tip Samba = SMB service. SSSD = identity. Both can talk to Active Directory, for different jobs.

The journal and rsyslog

journalctl reads systemd's journal: -u sshd (one unit), -b (this boot), -p err (errors and worse), --since "1 hour ago", -f (follow), -k (kernel). Make it survive reboots with Storage=persistent (or by creating /var/log/journal). rsyslog writes classic text logs under /var/log using facility.priority rules, and can forward to a central server.

# /etc/rsyslog.d/50-central.conf
authpriv.*   /var/log/secure
*.*          @@logs.kibbleco.example:514

Exam tip Login events: /var/log/auth.log on Debian/Ubuntu, /var/log/secure on RHEL. @@ forwards over TCP, @ over UDP.

logrotate

logrotate keeps logs from filling the disk: it renames the current log, starts a fresh one, compresses old ones and deletes the oldest. Global defaults in /etc/logrotate.conf, per-app rules in /etc/logrotate.d/. It runs daily from a timer or cron.

/var/log/labeld/*.log {
    weekly
    rotate 8
    compress
    missingok
    postrotate
        systemctl reload label-print
    endscript
}

Exam tip postrotate tells the app to reopen its log, or it keeps writing to the renamed file.

auditd

The Linux audit system records kernel events: file access, system calls, logins, command execution. auditd writes them to /var/log/audit/audit.log. Persistent rules go in /etc/audit/rules.d/*.rules (augenrules merges them into audit.rules). -w watches a path, -p picks r/w/x/a (attribute change), -k tags it so you can search later with ausearch -k; aureport summarizes.

-w /etc/shadow -p rwa -k shadow
-w /etc/sudoers -p wa -k sudoers

$ sudo ausearch -k shadow -i

Exam tip auditctl -l lists the loaded rules. Rules added with auditctl alone vanish at reboot.

Password policy that helps

Length beats complexity: a long passphrase is stronger and easier to remember than P@ssw0rd!. Set rules with pam_pwquality (/etc/security/pwquality.conf: minlen, dictionary checks). History/reuse: pam_pwhistory remember=5 blocks the last five. Expiration: chage -M sets a maximum age. Current guidance (NIST) avoids routine forced changes, and forces one when a password may be compromised.

# /etc/security/pwquality.conf
minlen = 14
dictcheck = 1
usercheck = 1

Exam tip Exam wording: complexity, length, expiration, reuse, history. Know what sets each one.

MFA and breach lists

Multifactor authentication (MFA) combines factors: something you know (password), have (phone app, hardware key) or are (fingerprint). For SSH: keys plus a TOTP code through a PAM module, or a FIDO2 hardware key (ed25519-sk). Checking existing breach lists: reject passwords that already appear in known breach collections, because attackers try those first.

Exam tip A password from a breach list is weak no matter how complex it looks.

Lockouts: pam_tally2 and pam_faillock

pam_tally2 counted failed logins and locked accounts on older distros. It's been removed; today's module is pam_faillock (settings in /etc/security/faillock.conf: deny=, unlock_time=). faillock --user rosa shows the failures; faillock --user rosa --reset unlocks her.

Exam tip The objectives still list pam_tally2. Know it's the old one, replaced by pam_faillock.

Restricted shells and not being root

Service accounts get /sbin/nologin (or /usr/sbin/nologin) as their shell: login is refused with a polite message. /bin/rbash (restricted bash) allows a login but blocks cd, changing PATH, commands containing / and output redirection: useful for a kiosk-style account. Avoid running as root: log in as yourself and use sudo per command, run services as their own accounts, and lock or restrict direct root login.

Exam tip nologin = no interactive login at all. rbash = a login, with a short leash.

journald and journalctl

systemd's journal collects logs from services and the kernel.

• journalctl -u sshd: one service
• journalctl -f: follow live
• journalctl -b (this boot), -b -1 (previous boot)
• journalctl -p err: errors and worse
• journalctl --since '1 hour ago'
• Make it persistent across reboots: create /var/log/journal (or Storage=persistent in /etc/systemd/journald.conf)

rsyslog, /var/log and logrotate

rsyslog writes classic text logs and can forward to a central server (rules in /etc/rsyslog.conf, /etc/rsyslog.d/). Common files: /var/log/messages (RHEL) or /var/log/syslog (Debian), /var/log/secure or auth.log (logins), dmesg/kern logs. logrotate rotates, compresses and deletes old logs on a schedule (/etc/logrotate.conf, /etc/logrotate.d/).

Exam tip Disk filling with logs: check logrotate settings and journald's SystemMaxUse.

What it records

auditd records security-relevant events from the kernel: who changed a file, who ran a command, failed access, system calls. Logs go to /var/log/audit/audit.log.

• Rules: **/etc/audit/rules.d/*.rules** (compiled into audit.rules by augenrules)
• auditctl -w /etc/passwd -p wa -k identity: watch writes/attribute changes
• auditctl -l: list rules
• ausearch -k identity, aureport --login: search and report

Where it's set

Password rules are spread across a few files and PAM modules:

• Complexity and length: pam_pwquality in /etc/security/pwquality.conf (minlen=14, minclass, dcredit, ucredit...)
• Expiration: /etc/login.defs (PASS_MAX_DAYS) and chage per user
• Reuse/history: pam_pwhistory (remember=5) so users can't cycle old passwords
• Lockout after failures: pam_faillock (deny=5, unlock_time)

Modern guidance

Current NIST guidance favors long passphrases and checking against breached-password lists over frequent forced changes and odd character rules; many organizations still require expiration, and the exam expects you to know both settings.

Why

Passwords that appeared in previous data breaches are tried first by attackers (credential stuffing and dictionary attacks). Policies should reject them even if they meet complexity rules.

• Services such as Have I Been Pwned offer a k-anonymity API (only a hash prefix is sent)
• pam_pwquality's dictionary check (cracklib) rejects common words
• Password managers and identity providers often check breach lists automatically

Two tools

/sbin/nologin (or /usr/sbin/nologin) as an account's shell refuses interactive logins with a polite message; use it for service accounts and SFTP-only users. /bin/rbash (restricted bash) allows a login but blocks cd, changing PATH, running commands with a /, and output redirection, so users can run only what you put in their PATH.

Exam tip rbash is easy to escape if the user can run editors or interpreters; it's a speed bump, not a sandbox.