DEV Community: Yaa Kesewaa Yeboah

10 Linux Security Incidents, Reproduced and Fixed

Yaa Kesewaa Yeboah — Sun, 01 Mar 2026 21:31:44 +0000

There's a difference between reading about Linux security and actually breaking things on purpose. This assignment made me do the latter; 10 real-world incidents, reproduced and fixed one by one.

I'll keep this post high-level. If you want the full commands, screenshots, and detailed documentation, it's all on my GitHub: github.com/Yaa-K/devsecops-linux-assignment

Scenario 1 — Shared Document Deletion Incident

An intern deleted a shared design document. I reproduced it by creating three users, a shared group, and a group-writable directory. As expected, any group member could delete any file inside — regardless of who created it.

The fix was chattr +i, which makes a file immutable at the filesystem level. Even root cannot delete it without explicitly removing the attribute first. This is the key difference between chmod and chattr — one enforces permissions, the other enforces filesystem-level constraints that sit below permissions entirely.

Scenario 2 — Log Overwrite Incident

One accidental > instead of >> destroyed over 100 lines of application logs instantly.

I restored the logs, backed them up using cp -p to preserve timestamps, and applied chattr +a (append-only) so no user — regardless of permissions — could overwrite the file again.

cp -p matters here because timestamps are forensic evidence. Without them, a backup file loses its evidentiary value — you can no longer tell when events actually occurred.

Scenario 3 — Permission & Ownership Drift

Copying files without the -p flag silently resets ownership and timestamps. A file that was dev_user:project_team 600 becomes your user's file after a plain cp. In production that kind of drift can expose secrets without anyone noticing.

The fix: always use cp -p for anything going to production.

Scenario 4 — Relative Path Deployment Failure

A deployment script used a relative path. It worked perfectly from the project directory and broke immediately when called from anywhere else — which is exactly what CI/CD systems do.

Switching to an absolute path fixed it completely. Relative paths are environment-dependent. Absolute paths are not.

Scenario 5 — Monitoring Failure After Log Cleanup

Removing a log file broke a symlink-based monitoring agent. A hard link to the same file survived without any issues.

A symlink is just a pointer to a path — remove the original and the symlink has nothing to point to. A hard link shares the same inode, so the data lives on as long as the link exists. For monitoring tools that need to survive log rotation, hard links are the safer choice.

Scenario 6 — Sensitive Data Exposure Hunt

Scanned an entire directory tree for exposed credentials using grep -r, multiple expressions with -e, and a pattern file with -f. Found passwords, API keys, and tokens sitting in plaintext in both config and log files.

Finding credentials in plaintext means immediate rotation. No exceptions.

Scenario 7 — Shared Directory Stability Controls

Developers were losing files because teammates were accidentally deleting each other's work. The fix was a single command — applying the sticky bit with chmod +t.

The sticky bit means only the file owner or root can delete a file, even if everyone in the group has write access. It's the same mechanism that keeps /tmp working safely on every Linux system.

Scenario 8 — Special Permission Risk Review

This one covered three special bits — sticky, setgid, and setuid — across a nested production-like directory path.

SetGID ensures new files inherit the directory's group automatically, so the whole team always has access without needing manual chgrp after every file creation.

For setuid, the difference between lowercase s and uppercase S is worth knowing. Lowercase means it's active. Uppercase means setuid was set without an execute bit — completely meaningless and always a misconfiguration.

Scenario 9 — Process Anomaly Investigation

A rogue infinite loop process was consuming 100% CPU. I identified it with ps and top, suspended it with kill -STOP, resumed it with kill -CONT, and terminated it gracefully with kill -15.

Always try kill -15 (SIGTERM) first. It lets the process clean up properly. kill -9 forces it dead with no cleanup — in production that can mean corrupted data or stuck locks.

Scenario 10 — Incident Documentation via Heredoc

Generated a structured incident report for all 10 scenarios using a heredoc directly in the terminal — no text editor needed.

What I Took Away

A few things that genuinely stuck with me:

chattr is underused. For files that should never be touched, it's a stronger guarantee than chmod — it sits below the permission layer entirely.

> vs >> matters more than people realise. In log management this is the difference between preserving forensic history and destroying it. Default to >>.

Uppercase S on a file is always a misconfiguration. Don't ignore it.

Absolute paths in scripts are not optional in production. They work from anywhere. Relative paths don't.

Hard links and symlinks are not interchangeable. Symlinks are convenient but fragile. Know when to use each.

This assignment was genuinely useful. These are not contrived scenarios — they reflect real incidents. If you want to dig into the full commands and evidence for each one, everything is documented on my GitHub: github.com/Yaa-K/parocyber-linux-assignment

Completed as part of the ParoCyber Linux Assignment, facilitated by Samuel Nartey Otuafo at ParoCyber LLC.

I Thought I Knew Linux. This Lab Proved Me Wrong.

Yaa Kesewaa Yeboah — Fri, 20 Feb 2026 21:57:19 +0000

I've been using Linux for a while. Commands like useradd, chmod, grep — I knew them. I could navigate the terminal without panicking. So when I started my first assignment in the ParoCyber DevSecOps Bootcamp, I figured it would be straightforward.

It wasn't. And I mean that in the best way possible.

What the Assignment Was About

The lab had two scenarios. The first was a password state investigation — find users on a system with no passwords set, understand where Linux stores that information, and remediate it. The second was a full onboarding simulation: create users, assign them to department groups, configure a CI/CD service account, manage sudo access, and safely offboard a user.

On paper, it sounds like basic sysadmin work. In practice, it forced me to think like a security engineer — and that changed everything.

The Moment That Reframed Everything

In Scenario 1, the task said: "You are not told where Linux stores password state. Finding it is part of the task."

I knew about /etc/passwd. Everyone who has touched Linux knows /etc/passwd. But when I ran cat /etc/passwd, the password field just showed x. A placeholder. I had seen that a hundred times and never thought twice about it.

That x means the actual password data lives somewhere else — /etc/shadow. And when I inspected it, I saw something that stopped me:

audit_test:!:...

That ! in the second field. One character. That single character is the difference between a secured account and a vulnerability sitting open on your system. I had been using Linux without ever knowing that file existed, let alone what it meant.

Then I tested whether a normal user could read /etc/shadow:

cat /etc/shadow
# Permission denied

And that's when it clicked. The fact that /etc/passwd is world-readable but /etc/shadow is root-only isn't an accident — it's a deliberate security design. Two files, one visible to everyone, one locked down. I had been looking at half the picture this whole time.

Scenario 2: Access Control Is a People Problem Too

The second scenario was about onboarding eight new staff members across four departments — dev, security, QA, and ops. Each team gets its own group. Each group gets access to what it needs and nothing more.

What struck me here wasn't the commands. It was the reasoning behind them.

When I created the ci_runner service account with a non-login shell:

sudo useradd -r -s /usr/sbin/nologin ci_runner

The trainer's question wasn't "did you run the command" — it was "do you know why this matters?" A service account with an interactive shell is an open door. Automated pipelines don't need to log in. Humans shouldn't be logging in as them either. That shell setting is a security decision, not a configuration detail.

Same with removing a user at the end. I used:

sudo userdel yaa

Not userdel -r. The -r flag would have deleted the home directory too. But in a real environment, that directory might contain evidence — scripts, logs, files that matter in an investigation. Deleting it immediately could mean destroying forensic data. That's not a Linux lesson. That's a security operations lesson.

What I'm Taking Away

I came into this thinking DevSecOps was Linux plus some security tools on top. What I'm leaving with is a different understanding — security isn't a layer you add. It's a lens you apply to every decision, including the ones that look purely technical.

The commands I ran in this lab weren't new. The questions behind them were.

Why does this file have these permissions? Why does this account need this shell? What happens to this data when this user is gone? Those questions are what separate someone who uses Linux from someone who secures it.

This is assignment one. I'm already thinking differently. Looking forward to what's next.