🔄 Topic

Managing file permissions and authorization in Linux, documented as a portfolio artifact for the Google Cybersecurity Certificate.

🎯 Goal

Practice reading and changing Linux permissions with chmod, and turn the lab into a clean portfolio document.

🛠 What I Did

I worked through the “Manage authorization” activity from the Linux and SQL course of the Google Cybersecurity Certificate. The scenario: a projects directory where file permissions did not match the organization’s authorization policy. I read permission strings, identified files where users, group members, or others had more access than they should, removed unauthorized write access, restricted a hidden file, and tightened directory permissions. Then I wrote it up as a portfolio document with the commands and reasoning.

Main areas covered:

reading rwx permission strings for user, group, and other
ls -la to reveal hidden files
chmod with symbolic notation
removing write access from other
restricting hidden file permissions
directory permissions vs file permissions

🔗 Key Cybersecurity Connections

Authorization is the enforcement half of access control. Excessive permissions are one of the most common real-world findings: a file writable by everyone is an integrity incident waiting to happen.

🔍 Investigation Questions

Which files grant more access than the policy allows?
Who actually needs write access to each file?
Are there hidden files with inappropriate permissions?
Do directory permissions undermine the file permissions inside?
Can I justify each chmod change in one sentence?

🚨 Detection Opportunities

Potential monitoring ideas:

permission changes on sensitive directories
files created world-writable
unexpected chmod activity outside change windows
hidden files appearing in project directories
drift between permission state and policy

Example:

project=linux-authorization-lab
change_type=permission_modification
risk_area=excessive_file_access
triage=compare_permissions_against_policy

🧭 MITRE ATT&CK Techniques

Possible mappings depending on confirmed behavior:

T1222 — File and Directory Permissions Modification
T1083 — File and Directory Discovery
T1078 — Valid Accounts

🗺 Visual Investigation Diagram

Policy
    ↓ Current permissions
    ↓ Gap identified
    ↓ chmod changes
    ↓ Verified least privilege

⚠ Challenges

The challenge was slowing down enough to justify each change instead of just typing chmod until the output looked right. The portfolio format forces the reasoning to be explicit.

📚 What I Learned

I learned that permission strings become fast to read with practice, and that the valuable skill is not the chmod syntax — it is mapping permissions back to an authorization policy.

➡ Next Steps

Continue the Linux and SQL course
Add the finished document to portfolio material
Practice the same review on my own machines
Connect this to the detection rules ideas in my detections repo

🧠 Reflection

This was useful because certificate labs can feel artificial, but writing the reasoning as a portfolio piece turned it into evidence I can show and explain in an interview.

🧩 Lessons Learned

What worked

Justifying every permission change against the stated policy.

What broke

My first pass missed the hidden file.

Why it broke

Default listings do not show dotfiles, and I did not start with ls -la.

Fix / takeaway

Always list hidden files first when reviewing permissions.

📈 Skill Progression Context

This supports my cybersecurity progression because least privilege is a foundation concept, and Linux permission review appears in almost every security role from SOC analysis to hardening work.

😄 TL;DR

chmod is easy; explaining why is the skill.