Practice Lab · 05 · Ubuntu / Mint
Linux Users, Sudo & Permissions
Review local users, privileged groups, sudo policy, file ownership, mode bits, ACLs, and installed packages while preserving the robotics tools the fictional team depends on.
The lab emphasizes least privilege without broad cleanup. Linux permissions can look simple until groups, ACLs, sudoers rules, and application ownership are considered together.
Lab Snapshot
Mission briefing
Preserve the robotics workstation while reducing unnecessary access
This fictional Ubuntu/Mint workstation belongs to a school robotics team and must remain usable for normal development and collaboration.
Approved users are alex, priya, and the system root account.
alex is the primary student user and should not have unrestricted sudo access.
priya is the team mentor and may use sudo for approved administrative tasks.
SSH is not required on this workstation unless the scenario explicitly says otherwise.
The browser, development tools, and approved robotics software must continue to work.
Do not remove packages, change ownership, or alter permissions until you understand what the file, directory, or service is for.
Preserve account, sudo, permission, and package evidence before making changes.
Permission rule
Access is the combination of identity, group, sudo, mode bits, and ACLs
Never judge a Linux permission problem from one command alone. Ownership, groups, sudoers rules, and ACLs can all change the actual access a user receives.
Identity review
Understand users before changing them
Review local users
Identify interactive user accounts and distinguish them from service or system accounts.
cut -d: -f1 /etc/passwd
getent passwd
awk -F: '$3 >= 1000 {print $1, $3, $7}' /etc/passwdReview groups
Understand group membership, effective IDs, and whether users belong to privileged groups.
getent group
groups alex
groups priya
id alex
id priya
Review login shells
Find accounts with interactive shells without assuming every interactive account is unauthorized.
grep -vE '/(nologin|false)$' /etc/passwd
Review current identity
Understand the current session and any other logged-in users before making changes.
whoami
id
who
w
Sudo review
Measure real privilege, not just group membership
Members of sudo group
Identify users who may receive administrative capability through a privileged group.
getent group sudo
getent group wheel 2>/dev/null
Effective sudo privileges
Review what commands each user is actually allowed to run.
sudo -l
sudo -l -U alex
sudo -l -U priya
Main sudoers configuration
Inspect the primary sudo policy and included drop-in files.
sudo cat /etc/sudoers
sudo ls -la /etc/sudoers.d
Search sudo rules
Locate active sudo rules that may grant broad or passwordless access.
sudo grep -R "^[^#].*ALL" /etc/sudoers /etc/sudoers.d 2>/dev/null
Permission review
Inspect ownership, mode bits, and ACLs
Inspect ownership and mode bits
Review ownership, group, and permission bits before changing access.
ls -l /home
ls -ld /home/alex /home/priya
stat /home/alex
Check sensitive files
Verify that critical identity and privilege files are not broadly writable or exposed.
ls -l /etc/passwd /etc/shadow /etc/group /etc/sudoers
stat /etc/passwd /etc/shadow /etc/sudoers
Search world-writable files
Find potentially risky files while limiting the search to relevant local paths.
find /etc /usr/local /opt -xdev -type f -perm -0002 2>/dev/null
Review ACLs
Check whether access control lists grant permissions that are not obvious from standard mode bits.
getfacl /home/alex 2>/dev/null
getfacl /opt/robotics 2>/dev/null
Package review
Understand software before removing it
Installed package inventory
Review installed software before removing anything.
dpkg -l | less
apt list --installed 2>/dev/null
Package ownership
Identify which package provided a file or executable.
dpkg -S /usr/bin/python3
dpkg -S /usr/bin/ssh 2>/dev/null
Package metadata
Review installed and candidate package versions and confirm whether a package is present.
apt-cache policy openssh-server
apt-cache policy sudo
Recent package activity
Correlate recent package changes with the investigation timeline.
grep -E " install | upgrade | remove " /var/log/dpkg.log | tail -n 40
Fictional evidence set
Classify the access problems
alex, priya, backupuser, root, and several service accounts are present. backupuser has /bin/bash as its shell.
Investigation prompt
Which account is not named in the mission briefing, and what should you check before disabling it?
priya and alex are both members of the sudo group.
Investigation prompt
Which membership conflicts with the mission, and what evidence should confirm the safest change?
A file named 90-robotics contains: alex ALL=(ALL) NOPASSWD: ALL
Investigation prompt
Why is this stronger evidence than sudo-group membership alone?
/home/alex is owned by alex:alex and has mode 755.
Investigation prompt
Is this automatically wrong, or does the expected privacy model need to be considered?
/etc/shadow is owned by root:shadow and has mode 640.
Investigation prompt
Does this look broadly exposed? What would be a clearly risky alternative?
/opt/robotics/config.ini is writable by everyone.
Investigation prompt
What should you learn about this file before changing its permissions?
/opt/robotics has an ACL entry granting backupuser rwx.
Investigation prompt
Why could an ACL matter even if the normal ls -l output looks reasonable?
openssh-server was installed three days ago, but SSH is not required by the mission.
Investigation prompt
What service, listener, and usage evidence should you check before deciding whether to remove or disable anything?
Decision model
Connect the permission layers
Account
Is the account approved, interactive, recently used, or referenced by a service or scheduled task?
Privilege
Does the user have sudo-group membership, explicit sudoers rules, or NOPASSWD access?
Ownership
Who owns the file or directory, and is that consistent with the application or system role?
Permissions
Are mode bits or ACLs broader than the mission requires?
Package
Is the package required, recently installed, or tied to a running service?
Verification
After remediation, can approved users still work while unjustified access is removed?
Preserve first
Permission changes can break applications or erase evidence
Record /etc/passwd and relevant user details before disabling an account.
Record group membership before removing a user from sudo or another privileged group.
Copy or document relevant sudoers and sudoers.d entries before editing them.
Record file owner, group, mode bits, and ACLs before changing permissions.
Record the exact package name and version before removal.
Check whether an account owns files, runs services, or appears in cron jobs before disabling it.
Check whether a package provides a required service before removing it.
Record the exact command used for remediation and the post-change result.
Authorized remediation examples
Make the smallest justified Linux change
These examples are for an authorized practice VM after the mission and evidence clearly support the action.
Remove unjustified sudo-group membership
Use only after confirming alex should remain a standard user and no approved workflow depends on sudo-group membership.
sudo deluser alex sudo
Disable an unapproved local account
Lock the account rather than deleting it when preserving files and rollback options is useful.
sudo usermod -L backupuser
Tighten a world-writable configuration file
Use only after confirming the correct owner/group and that the robotics application can still read the file.
sudo chmod 640 /opt/robotics/config.ini
Remove a specific ACL entry
Use only when the ACL grant is not required by the scenario.
sudo setfacl -x u:backupuser /opt/robotics
Verification
Confirm least privilege without breaking the robotics tools
Users
Approved users remain present and account state matches the mission.
getent passwd
id alex
id priya
Sudo
Only the approved mentor retains the intended administrative capability.
getent group sudo
sudo -l -U alex
sudo -l -U priya
Permissions
Ownership, mode bits, and ACLs reflect the intended access model.
stat /opt/robotics/config.ini
getfacl /opt/robotics 2>/dev/null
Critical files
Sensitive system files remain protected and unchanged unless a justified repair was required.
ls -l /etc/passwd /etc/shadow /etc/sudoers
Packages
Any package or service change matches the mission and does not remove required functionality.
apt-cache policy openssh-server
systemctl status ssh --no-pager 2>/dev/null
Core usability
The primary user can still access approved robotics resources after remediation.
id alex
test -r /opt/robotics/config.ini && echo readable
Reflection
Debrief the permission decisions
Why is membership in sudo different from an explicit NOPASSWD sudoers rule?
Why should an unfamiliar interactive account not be deleted immediately?
Why can ACLs change the real access model even when standard permission bits look acceptable?
What is the risk of changing a file from world-writable to a restrictive mode without checking the owning application?
Why should package history be correlated with service and network evidence?
Why is locking an account sometimes safer than deleting it during an investigation?
What is the difference between file ownership and file permissions?
Which finding in this lab required the most context before a safe decision could be made?
Completion checklist
Finish only when approved work still functions
I reviewed local interactive users and group membership.
I checked sudo-group membership and effective sudo rules.
I inspected sudoers and sudoers.d before changing privilege.
I recorded ownership, mode bits, and ACLs before changing file access.
I reviewed sensitive system-file permissions.
I checked package ownership and recent package history.
I correlated openssh-server with actual service and listener state before deciding on remediation.
I made only narrow, mission-supported changes.
I verified approved users and robotics software still functioned after remediation.
I can explain the difference between direct observation and inference for every major finding.