Part 10 — Users, permissions, and basic hardening

Every command in Parts 7–9 ran as some user with some set of permissions, mostly unexamined. This part makes that explicit: who's allowed to do what, how sudo actually works underneath the prompt, and the baseline hardening steps that follow directly once permissions are set up correctly.

Chapter 35 — Users, groups, and `sudo`

In one sentence

Every process runs AS a specific user (Chapter 4's permission field), Linux groups let you grant the same access to many users at once, and sudo is the standard, AUDITABLE way to run something as a different user (almost always root) without actually logging in as them.

Why this matters

sudo is one of the most-run commands on any real Linux system, and it's also — because it's a gateway to root — a genuinely high-stakes piece of software, as a real, severe vulnerability made clear.

How it actually works

   whoami                    # who am I, right now
   id                         # my user ID, group ID, and all groups
                             # I belong to
   sudo command                # run ONE command as root (by default),
                             # after authenticating (usually your OWN
                             # password, not root's)
   sudo -u alice command        # run as a SPECIFIC other user, not
                             # necessarily root
   su - alice                   # actually SWITCH USER, starting a new
                             # login shell as alice (needs alice's
                             # password, unless you're already root)

   sudo -l                       # list what YOU are allowed to run with
                             # sudo -- often surprisingly restrictive,
                             # by design, on a well-configured system

   /etc/passwd                   # every user account, with basic info
   /etc/group                     # every group, and its members
   /etc/sudoers                    # who can sudo, and to run WHAT
                             # (edit with `visudo`, never directly --
                             # it validates syntax before saving,
                             # preventing you from locking yourself out
                             # with a typo)

Why sudo is preferred over logging in as root directly, as a real, deliberate security design:

   - EVERY sudo invocation is LOGGED (who, what command, when) --
     accountability that a shared root login simply doesn't give you.
   - Access can be SCOPED: a user can be granted sudo rights to run only
     SPECIFIC commands, not unrestricted root access.
   - It requires the USER'S OWN credentials (by default), not a shared
     root password everyone has to know and rotate together.

Real-world example

   In January 2021, the security firm Qualys publicly disclosed
   CVE-2021-3156, nicknamed "Baron Samedit" -- a HEAP-BASED BUFFER
   OVERFLOW vulnerability in `sudo` itself, present in the codebase for
   roughly a DECADE before it was found, affecting nearly every major
   Linux distribution's default `sudo` installation. The bug allowed
   ANY local, unprivileged user (no sudo permissions needed at all) to
   exploit a flaw in how `sudo` parsed command-line arguments (related
   to escaping backslash characters when invoked in a specific mode)
   to gain FULL ROOT ACCESS, with no password required.
   Because `sudo` is installed by default on the vast majority of
   real-world Linux systems -- servers, desktops, containers built on
   common base images -- this was an exceptionally widespread, severe
   vulnerability, and it triggered urgent, coordinated patching across
   the entire industry within days of disclosure. It's a genuinely
   sobering, well-documented real illustration of two things this
   Part keeps returning to: first, that the tools we trust MOST
   completely (a program whose entire purpose is granting root access)
   are exactly the ones where a bug is most consequential; and second,
   that "this code has existed and been widely used for ten years" is
   NOT the same as "this code has been proven safe" -- it can simply
   mean the specific bug hadn't been found yet.

Try it yourself

# Explore your own user/group setup
id
groups
cat /etc/passwd | head -5
cat /etc/group | grep $(whoami)

# See what YOU'RE allowed to sudo (varies by system configuration)
sudo -l 2>/dev/null | head -20

# Check your sudo version against the CVE-2021-3156 fix (informational)
sudo --version | head -1
# (any reasonably current, patched Linux distro will already be safe --
#  this is just to see the version-checking habit, not to alarm you)

Common mistakes

Sharing a root login/password among a team instead of using sudo. Loses individual accountability entirely — nobody can tell WHO did what.
Editing /etc/sudoers directly with a text editor. A syntax error can lock EVERYONE, including you, out of sudo — always use visudo, which validates before saving.
Assuming widely-used, long-standing software is inherently safe from serious bugs. The Baron Samedit vulnerability sat undiscovered in sudo for roughly ten years — keep systems patched, always, regardless of how "trusted" a tool is.

Check yourself

Why is sudo generally preferred over sharing a root login?
What was CVE-2021-3156, and why was it so significant?
Why should you always use visudo instead of editing /etc/sudoers directly?