Linux Foundations for Security

• Navigate files, permissions and processes with the core command set
• Inspect logs and running services for evidence
• Reason about privilege boundaries on a Unix host

• Nearly every lab in this track runs in Linux — command fluency is prerequisite for everything that follows.
• Incident response on a Linux host means reading /var/log, processes and listening sockets fast.
• The permission model (mode bits, umask, sudo) is the everyday mechanics of least-privilege enforcement.
• Attack tooling (Metasploit, others) is mostly Linux-first; defenders must be as fluent as the tooling.

The librarian knows the cataloging, the aisles and who is allowed to borrow what. An analyst maps this to: filesystem, processes and permissions — knowing every resource's location, state and access rules.

• Everything is a file: devices, sockets and regular data all live under the filesystem tree.
• Permissions are mode bits: rwx per owner/group/other, plus special bits (setuid, sticky).
• Processes are tracked by PID, run as a user, and inherit a permission context.
• Logs live under /var/log (journald, syslog) and daemons register services the OS supervises.
• sudo grants controlled elevation; root is all-powerful and ops must avoid operating as root.

• First response on an IR case: `ps aux`, `ss -tulnp`, `journalctl | tail`, then a hash-and-diff of binaries.
• A hardening checklist applies least privilege: non-root service accounts, disabled root login, umask 027.
• A SOC analyst greps auth.log for accepted-address anomalies to spot account takeovers before the attacker pivots.

• Operate with least privilege: normal users, dedicated service accounts, sudo only when needed.
• Enable and centralize logging: standardize journald to a SIEM with rotation policy.
• Document the baseline: list expected binaries, listeners and users so a change stands out.
• Patch and inventory: know what's installed before the scanner does.

• Running everything as root because 'it just works' — every mistake becomes a privilege escalation.
• Relying on 'nothing looks weird' instead of a written baseline.
• Ignoring log rotation until the disk fills and logging stops — attackers love silent sensors.

• Strace a failing binary to see exactly where it dies (permissions, missing lib, network).
• Compare `ss -tulnp` before and after a suspected intrusion; a diff is evidence.
• When a service 'doesn't start', read journalctl -u <svc> -n 50 before touching the config.

• setuid binaries are classic escalation paths; scan for them (`find / -perm -4000`).
• World-writable paths and sticky-bit abuse let attackers plant trojans; audit /tmp consistently.