sudo and least privilege¶

Exercise sudo-and-least-privilege-annex.pdf · PDF

Pau, the intern at Tramuntana Apps, needs to refresh the package lists on a server once a week. Should he get the root password? Should he go into the group sudo, which can do everything?

Neither. The answer to that question is one line of text, and it is fifty years old. In Users and groups on Linux you used sudo as a magic word. Today you open it and see how to give someone exactly one command — and nothing more.

Why sudo asks for your password¶

When you type sudo whoami, sudo asks for your password, not root's. Three good reasons:

• Nobody has to share root's password. When a colleague leaves the company, nothing changes for everybody else.
• The log says who did it, not just "root".
• It proves the person at the keyboard is still you, not someone who found your session open.

A little history¶

sudo is older than you might think. It was written around 1980 by Bob Coggeshall and Cliff Spencer at the State University of New York at Buffalo, because handing the root password to every student helper was a bad idea.

Five years earlier, in 1975, Jerome Saltzer and Michael Schroeder at MIT had written down the rule that sudo puts into practice:

"Every program and every user of the system should operate using the least set of privileges necessary to complete the job."

That is the principle of least privilege. It is still the first rule of security.

One key for one door¶

Back in the kitchen. The kitchen manager (the operating system) keeps a key cabinet. The intern who takes out the rubbish gets the key of the back door, not the master key. If the intern loses it — or goes mad — the damage stops at the back door.

Accounts work the same way. The question is never "do I trust Pau?". It is "what does Pau's job need?"

Reading the sudoers file¶

/etc/sudoers is the file where sudo reads who may run what, as whom.

Print it without comments and empty lines:

sudo grep -vE "^#|^$" /etc/sudoers

Among the output, three lines matter:

root    ALL=(ALL:ALL) ALL
%sudo   ALL=(ALL:ALL) ALL
@includedir /etc/sudoers.d

Cut the second line into four pieces:

So the "magic" group sudo is just one line of text. The last line, @includedir, tells sudo to also read every file in the folder /etc/sudoers.d/. That is where your own rules go.

A narrow rule is written the same way, with a full path instead of the last ALL:

pau   ALL=(root) /usr/bin/apt update

"Pau, on any machine, as root, may run /usr/bin/apt update." Nothing else.

flowchart LR
    CMD["<b>pau types</b><br>sudo apt install cowsay"] --> PW["<b>sudo asks</b><br>pau's own password"]
    PW --> RULES["<b>sudo reads the rules</b><br>/etc/sudoers + sudoers.d"]
    RULES -->|"a rule matches"| RUN["<b>Runs as root</b><br>and writes it in the log"]
    RULES -->|"no rule matches"| NO["<b>Sorry, user pau is not allowed</b><br>and writes that in the log too"]

What may I do? sudo -l¶

sudo -l

The last line for student in deb-lab is:

    (ALL : ALL) ALL

That is the %sudo rule at work. An administrator can also ask about another user without becoming them, with -U:

sudo -l -U joan

User joan is not allowed to run sudo on deb-lab.

Writing rules safely with visudo¶

Never open /etc/sudoers with a normal editor. Use visudo: it opens the file in an editor and checks the grammar before saving. Why does this matter so much? With a broken sudoers file, sudo refuses to work for everybody — and sudo is exactly what you would need to repair it.

Create a separate file for the company's rules:

sudo visudo -f /etc/sudoers.d/tramuntana

Type the rules (visudo usually opens nano: save with Ctrl+O, Enter, leave with Ctrl+X):

# Tramuntana Apps - least privilege
pau   ALL=(root) /usr/bin/apt update
%dev  ALL=(root) /usr/bin/systemctl restart cron

Then check every file:

sudo visudo -c

It must print parsed OK for /etc/sudoers and for /etc/sudoers.d/tramuntana.

Test as the intern¶

Become Pau and look at the prompt: it must say pau@deb-lab.

su - pau
sudo -l

Pau sees two commands: (root) /usr/bin/apt update from his own line, and (root) /usr/bin/systemctl restart cron because he is in the group dev. Now try:

sudo apt update
sudo apt install cowsay

The first one works. The second one answers:

Sorry, user pau is not allowed to execute '/usr/bin/apt install cowsay' as root on deb-lab.

sudo whoami gets the same refusal. One key, one door. Notice that sudo asked for Pau's password: he is the one asking.

Who did what?¶

Every use of sudo, allowed or refused, is written to the system log:

sudo journalctl -t sudo -n 10

Each line shows the user, the folder and COMMAND=.... Pau's refused attempts say command not allowed.

Think before you grant¶

The boss asks: "Aina should be able to create accounts for new employees." Someone proposes:

aina  ALL=(root) /usr/sbin/adduser

Looks harmless. But with it, Aina can run sudo adduser aina sudo, log in again, and she is in the group sudo: full control. One "small" permission was the master key in disguise.

The same goes for any program that can change users, edit any file or start a shell: adduser, nano, find... Before granting a command, ask: "what is the worst thing this program can do as root?"

Least privilege is not about trusting people less. It is about making every mistake — yours, theirs, the program's — as small as possible.

Key takeaways¶

• The principle of least privilege (Saltzer and Schroeder, 1975): give each account only what its job needs.
• sudo asks for your password, so root's is never shared and the log records who did what.
• A sudoers rule answers four questions: who (% = group), on which machine, as whom, which commands (full paths).
• Write your rules in /etc/sudoers.d/ with visudo, which checks the grammar; sudo -l (and sudo -l -U user) shows what is allowed.
• A rule for one "small" program can be a master key in disguise if that program can change users, edit files or open a shell.

Quick check¶

You now control who may borrow root, and for what. Next, from files and accounts to what is running: Processes.