The Golden Rule: Least Privilege, Even for Yourself

Remote Support Tools & Techniques

Chapter 6 · The Golden Rule: Least Privilege, Even for Yourself

Chapters 1 and 5 both previewed this: use the minimum access that accomplishes the current task, nothing more, even when broader access is technically sitting right there and available to you. "Even for yourself" is the important part — this applies to your own habits as a support engineer, not just what gets granted to other people.

Why Broad Access Is a Risk Even If You'd Never Misuse It

Least privilege isn't (only) about not trusting yourself. A broadly-privileged account is a bigger target and a bigger blast radius the moment something goes wrong with your access specifically — a stolen credential, a phished session, a compromised laptop — entirely independent of your own intentions. The real question isn't "would I misuse this," it's "what's the maximum damage if something goes wrong with my access, regardless of why."

Read-Only Where Read-Only Suffices

Many diagnostic tasks genuinely only need read access — checking logs, checking metrics, running a SELECT. Using a dedicated read-only account or role for these, rather than a full admin account that happens to also be capable of it, is a real, practical default. Web & Application Troubleshooting's own worked examples already modeled this directly — its readonly_user connecting for a diagnostic query, not the application's own full database credentials.

Time-Limited Credentials Over Standing Access

Where the infrastructure supports it, short-lived credentials — a bastion host issuing a certificate valid for a few hours rather than a permanent keypair, a cloud provider's own temporary session tokens — are genuinely stronger than permanent standing access. If a short-lived credential leaks, the exposure window is naturally bounded; a permanent one keeps working until someone notices and explicitly revokes it. Not every organization has this kind of infrastructure built out yet, and standing access used with good discipline is still far better than no discipline at all — this describes a genuinely stronger option where it's available, not a judgment on anyone whose organization hasn't built it.

Elevation on Demand, Not Standing Root

$ systemctl status app-service
# read-only, no elevation needed

$ sudo systemctl restart app-service
# elevated for exactly this one command, then back to the normal account

Using sudo for the specific command that genuinely needs elevated privilege, rather than logging in as root directly or holding a permanent root shell, is the same "escalate only for the moment you need it" principle applied to everyday Linux access.

The Temptation to Over-Provision "Just in Case"

A genuinely understandable, common failure mode: reaching for broader access than a specific task actually needs because asking again later feels like friction, or "I might need it soon anyway." This undermines the whole principle through a thousand individually-reasonable-feeling small decisions, not one dramatic one. If a genuine, recurring need for broader access exists, that's worth requesting as real, properly-scoped standing access through the normal process — not quietly worked around by defaulting to an overpowered account out of convenience.

Excess privilege during a routine task is pure, unnecessary risk

Using a full admin account for a routine, read-only diagnostic task means that if your session is compromised at that exact moment — a phishing attack succeeding on your own machine while that admin session happens to be open — the attacker inherits full admin access, not just the read access the task actually needed. The entire gap between what was used and what was actually necessary becomes pure downside, with zero corresponding benefit to the work being done.

Working Example: Diagnosing a Slow Service

Bad practice	Good practice
SSH in as root; run every check as root, including ones that never needed write access at all	SSH in with a standard, key-based account
Same root session used for database checks	A dedicated read-only database role for the diagnostic queries
Standing root shell held for the entire investigation	`sudo` reached for only the one specific command that genuinely needed it — restarting the service, if that turns out to actually be necessary — nothing more

Same diagnostic work, same actual outcome — a dramatically smaller blast radius the entire time it was happening.

Hands-On Exercises

Exercise 1

Explain why this chapter says least privilege matters even for someone who would genuinely never misuse their own access.

📄 View solution

Exercise 2

Explain why time-limited credentials are described as genuinely stronger than standing access, and why this chapter is careful not to treat organizations without them as doing something wrong.

📄 View solution

Exercise 3

Using this chapter's own bad/good comparison table, explain what changes about the actual risk if the support engineer's session were compromised during the investigation, under each approach.

📄 View solution

Chapter 6 Quick Reference

Least privilege, even for yourself — use the minimum access a task needs, not the broadest you happen to have
The real risk isn't misuse — it's the blast radius if your own access is compromised, regardless of intent
Use a read-only role where read-only genuinely suffices, rather than a full admin account out of convenience
Time-limited credentials bound the exposure window if they leak — genuinely stronger where available, not a requirement everywhere
sudo for the one specific command that needs it, not a standing elevated shell
Watch for "just in case" over-provisioning — a real recurring need should become properly-scoped standing access, not a workaround
Next chapter: Working Safely on a System You Don't Own