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.
Top comments (0)