stop reaching for sudo su

the habit that quietly wrecks your audit trail

you're on a server, you need to do one privileged thing, and your fingers just type sudo su out of muscle memory. it works, you get root, you move on. but that little habit is doing more damage than you think, and it has nothing to do with whether the command "works." it's about what you lose the moment you're sitting in a root shell instead of running one privileged command and getting out.

what sudo su actually does

let's break it down piece by piece.

sudo su

sudo asks the system to run the next thing as another user, usually root, and it logs that request. su means "switch user," and with no username given it defaults to root. so when you chain them together, you're using sudo's permission to launch su, which then drops you into a full interactive root shell. from that point forward, every single thing you type is running as root, and none of it is tied back to sudo's logging. sudo logged the moment you opened the door. it did not log what you did once you walked through it.

why this matters for defenders

if you manage systems, or even just your own homelab, your logs are your memory. when something breaks or something looks off, you want to be able to answer "who did what, and when." sudo su collapses that trail into one vague line: user X opened a root shell at time Y. everything after that is invisible to sudo's audit log. if you're the only one touching the box, that might feel harmless. but it also means if your account gets compromised, or you fat-finger something at 2am, there's no record of the actual damage, just the fact that a root shell existed for a while.

compare that to running commands individually with sudo. each action gets its own logged entry: the command, the user, the timestamp. that's the difference between a security camera that's always rolling versus one that only catches you opening the door.

what to reach for instead

if you need to run a single privileged command, just run it with sudo directly:

sudo systemctl restart nginx

no shell, no lingering root session, and a clean log entry for exactly what happened.

if you genuinely need a series of privileged actions and a root shell makes sense, use:

sudo -i

this is closer to a proper root login shell with root's own environment, and it's still logged as a sudo invocation. it's not a magic fix for the audit trail problem, but it's more intentional than su, and it avoids some of the environment-mixing weirdness that plain su can cause, like inheriting your regular user's PATH or shell config in a root context.

tighten it further with sudoers

if you're managing a system others touch too, or you just want better hygiene on your own box, look at limiting what sudo can even do. edit the sudoers file safely with:

sudo visudo

from there you can restrict specific users to specific commands instead of blanket root access. something like letting a user restart a service without ever touching a full shell:

deploy ALL=(root) /usr/bin/systemctl restart nginx

this way, even if that account gets compromised, the blast radius is one command, not the entire system.

the takeaway

this isn't about sudo su being "dangerous" in some dramatic hacking-movie sense. it's about visibility. every time you drop into a full root shell instead of running the one command you actually need, you're trading away the ability to answer "what happened here" later. on your own systems, that's the difference between a quick log check and hours of guessing. next time your fingers reach for sudo su, ask if you actually need a shell, or if you just need one command run as root. your future self, staring at logs trying to figure out what broke, will thank you.