Linux &
containers Your production runs here even if your laptops don't. Processes, permissions, systemd, auditd — then the container abstractions built on top of them, and the Kubernetes attack paths that follow.

-rwxr-xr-x  1 root root   /usr/bin/passwd
 │└┬┘└┬┘└┬┘
 │ │  │  └── other:  r-x
 │ │  └───── group:  r-x
 │ └──────── owner:  rwx
 └────────── type:   - file, d dir, l symlink

• SUID (4000) — runs as the file's owner, not the caller. find / -perm -4000 -type f 2>/dev/null is the first command in every privesc playbook; an unexpected SUID binary is a finding.
• SGID (2000), sticky bit (1000) — group inheritance and delete-protection in /tmp.
• Capabilities — finer-grained than root/not-root: getcap -r / 2>/dev/null. cap_setuid or cap_sys_admin on a binary is effectively root.
• sudo — sudo -l shows what you may run. NOPASSWD entries for anything with a shell escape (vi, find, awk, tar) are game over.

Files worth knowing by heart

/etc/passwd  /etc/shadow  /etc/group  /etc/sudoers  /etc/sudoers.d/
~/.ssh/authorized_keys        persistence in one line
/etc/ssh/sshd_config          PermitRootLogin, PasswordAuthentication
/etc/crontab  /etc/cron.d/    /var/spool/cron/
/etc/systemd/system/          unit files = modern persistence
/proc/<pid>/{cmdline,exe,environ,cwd}   live process truth

systemctl list-units --type=service --state=running
systemctl cat nginx.service        read the unit, check ExecStart
journalctl -u sshd --since "1 hour ago"
journalctl -p err -b               errors this boot

# auditd rules that earn their keep
-w /etc/passwd -p wa -k identity
-w /etc/sudoers.d/ -p wa -k sudoers
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_exec
-w /root/.ssh -p wa -k ssh_keys

Auth events to alert on: Accepted publickey/password for root, sudo: … COMMAND= for unexpected users, useradd/usermod, and repeated Failed password followed by a success — the classic brute-force-then-in pattern.

A container is a normal Linux process with three kernel features applied: namespaces (its own view of PIDs, network, mounts, users), cgroups (resource limits) and usually seccomp/AppArmor (syscall restriction). There is no VM boundary — the host kernel is shared.

• Image layers — every RUN creates a layer; a secret deleted in a later layer is still present in the earlier one. Scan images, and never COPY credentials.
• Escape paths worth knowing: --privileged, mounting the Docker socket (/var/run/docker.sock) into a container, hostPID/hostNetwork, dangerous capabilities like CAP_SYS_ADMIN, and writable host mounts.
• Running as root inside is still the default in too many images; combined with any of the above it is direct host compromise.

# quick container posture checks
docker inspect <id> --format '{{.HostConfig.Privileged}} {{.HostConfig.Binds}}'
grep -q docker /proc/1/cgroup && echo "we are in a container"
capsh --print                     what capabilities do we hold?

Detections that generalise: exec into a production pod, creation of a privileged pod, a service account suddenly listing secrets cluster-wide, anonymous or unauthenticated API access, and images pulled from outside approved registries.

1. No SSH passwords, no root login — keys or, better, short-lived certificates via a bastion/SSM. Remove long-lived keys entirely where you can.
2. Immutable infrastructure — rebuild rather than patch in place; a server nobody logs into is a server with very few detections needed.
3. Minimal base images — distroless or slim; fewer packages, fewer CVEs, no shell for an attacker to use.
4. Non-root containers, read-only root filesystem, dropped capabilities, seccomp profile.
5. auditd or eBPF runtime detection forwarded to the SIEM.
6. CIS Benchmark baseline for the distro, measured continuously rather than at build time.

Forward at minimum: auth logs, sudo, auditd execve for root, SSH sessions, package installs, and container runtime events. That set answers "who got in, as whom, and what did they run" — which is 80% of any incident question.