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