User rights and security policies¶

Exercise user-rights-and-security-policies-annex.pdf · PDF

Pau, the intern at Tramuntana Apps, cannot open the folder admin. Good. But can Pau switch the server off? Change its clock? Sit at Aina's PC and log in? No folder has those answers written on it. So where are they kept?

Until now, every question you asked about the office server was "who may open this?". Today the question changes: "who may do this?". Shut the machine down. Log in at all. Restart a service. Those are not permissions. They are rights, and an administrator must be able to read them, change them and prove what they are.

The key and the staff pass¶

Think of the Tramuntana office as a building.

• A permission is a key to one room. It belongs to the room: the lock decides who enters.
• A user right is what your staff pass allows in the whole building: come in at night, use the car park, switch off the alarm. It belongs to you (or your group), not to any room.

A permission says who may read, write or run one object. A user right says who may do an action on the whole computer.

Try it: "Marta may read budget.ods" is a permission (on a file). "Pau may not log in through Remote Desktop" is a right. "The group design may print on the plotter" is a permission again: the printer is an object.

Security policy¶

A security policy is the set of rules a system applies to everybody: password rules, who gets which rights, what is written to the audit log, what the sign-in screen shows.

On Windows those rules are collected in one console, the Local Security Policy. Microsoft splits user rights into two kinds:

Each right has a readable name and a constant name. Shut down the system is SeShutdownPrivilege.

Windows: the Local Security Policy¶

Your own rights¶

Open a normal terminal and type:

whoami /priv

You see a short list of privileges, among them SeShutdownPrivilege. Now open a terminal as administrator and run it again: the list is much longer. Same user, two lists. That is UAC seen from the rights side: Windows gives you a small staff pass by default and the big one only when you ask for it.

Read the policy¶

Start, type secpol.msc, Enter. Then open Security Settings → Local Policies → User Rights Assignment. Look for these four:

That second row explains why, in Remote desktop, a user had to be added to the group Remote Desktop Users: membership of that group is what gives the logon right.

Change a right and test it¶

Create a test user in an administrator terminal:

net user pau Benvinguda-2027 /add

In secpol.msc, open Deny log on locally → Add User or Group → pau → OK. Sign out and try to sign in as pau: Windows refuses. Sign in as administrator again, remove pau from the policy, and now pau gets in.

Two rules from Microsoft's documentation:

• A change of user rights takes effect the next time that account logs on. No restart needed.
• Deny wins. pau is also in Users, which is allowed to log on locally. When an account is in both lists, Deny log on locally wins over Allow log on locally.

A security option: the sign-in notice¶

Rights are only part of the policy. Under Local Policies → Security Options you find settings such as:

• Interactive logon: Message title for users attempting to log on → Tramuntana Apps
• Interactive logon: Message text for users attempting to log on → Authorised staff only. Activity on this computer is logged.

Sign out: the notice appears before the sign-in screen. Many companies are required to show one.

The policy as a text file¶

secedit /export /cfg C:\policy.inf /areas USER_RIGHTS
notepad C:\policy.inf

secedit /export writes the user rights to a text file. Inside you find lines like SeShutdownPrivilege = ... and SeDenyInteractiveLogonRight = .... The accounts appear as SIDs (security identifiers): *S-1-5-32-544 is the group Administrators. A policy that is a text file can be copied to another PC. Keep that thought: it is the problem the next page solves.

Linux: rights live in text files¶

Linux has no "Local Security Policy" window. The same decisions are spread over a few text files:

Reading a sudoers line¶

sudoers is the file that says who may run which commands as another user, usually root, with sudo.

%dev    ALL=(root)   /usr/bin/systemctl restart smbd
who     where=(as whom)   what, exactly

• %dev is the group dev. Without % it would be a user.
• ALL means on any host.
• (root) means the command runs as root.
• Then the full path of the command, with its arguments. Nothing else is allowed. That is least privilege, written down.

Always edit it with visudo, which checks the syntax before saving. A broken sudoers file means nobody can use sudo at all.

The audit: who is root here?¶

On a fresh Ubuntu, /etc/sudoers ships the line %admin ALL=(ALL) ALL. Tramuntana's administration department is a group called admin, so Aina, who does the invoices, became root by accident. That hole was closed weeks ago. Is it still closed? An administrator checks instead of assuming:

sudo grep -n admin /etc/sudoers
getent group sudo
for u in marta pau joan aina; do sudo -l -U $u; done

What a healthy server answers:

• The line appears with a # in front: # %admin ALL=(ALL) ALL.
• The group sudo contains only your own account.
• Each of the four users answers User ... is not allowed to run sudo on ubu-srv.

If Aina answers (ALL) ALL, run sudo visudo and put a # in front of the %admin line.

One task per department¶

Now give each department exactly what its job needs. sudo visudo -f /etc/sudoers.d/tramuntana:

# Tramuntana Apps: rights by department
%dev     ALL=(root) /usr/bin/systemctl restart smbd, /usr/bin/journalctl -u smbd
%design  ALL=(root) /usr/bin/systemctl restart cups

Check it with sudo -l -U marta (two commands for dev) and sudo -l -U joan (one for design). Then become marta and try something else:

sudo -i -u marta
sudo cat /etc/shadow
sudo journalctl -u smbd -n 5
exit

Both are refused: sudo: I'm sorry marta. I'm afraid I can't do that. The second one surprises people. The rule allows journalctl -u smbd with exactly those arguments; adding -n 5 makes it a different command.

PAM: the checkpoints of every login¶

PAM (Pluggable Authentication Modules) is the row of checkpoints every login passes through.

Each program that lets users in (sshd, login, sudo) has a file in /etc/pam.d/ that lists the modules to ask. One of them, pam_access, is a doorman with a list: /etc/security/access.conf, read top to bottom, first match wins.

flowchart LR
    U["<b>joan</b><br>types ssh"] --> SSHD["<b>sshd</b><br>checks the key"]
    SSHD --> PAM["<b>PAM</b><br>/etc/pam.d/sshd"]
    PAM --> ACC{"<b>pam_access</b><br>access.conf:<br>first match wins"}
    ACC -->|"+ allowed"| SHELL["shell on ubu-srv"]
    ACC -->|"- denied"| CLOSED["Connection closed"]

At Tramuntana only dev, admin and the server's administrators need a shell; design only uses shares and printers. Add at the end of /etc/security/access.conf:

+:root:ALL
+:(sudo):ALL
+:(dev) (admin):ALL
-:ALL:ALL

Each line is + or - : who (groups in brackets) : from where. The last line denies everybody who did not match before. Then, in /etc/pam.d/sshd, remove the # from the line # account required pam_access.so. No restart is needed.

From the host, ssh marta@192.168.122.10 works and ssh joan@192.168.122.10 ends with Connection closed by 192.168.122.10 port 22. And you still get in, because your account is in sudo: that is what the second line is for.

A limit per group¶

PAM also sets limits. With the line @dev hard nproc 200 in /etc/security/limits.conf, ssh marta@192.168.122.10 'ulimit -u' prints 200: a runaway script of one developer can no longer start enough processes to take the whole server down.

Key takeaways¶

• A permission is a key to one object; a user right is a staff pass for an action on the whole system.
• Windows keeps its rights in the Local Security Policy (secpol.msc): logon rights and privileges. Changes apply at the next logon, and deny wins over allow.
• secedit /export turns the policy into a text file, with accounts written as SIDs.
• On Linux, sudoers says who may run exactly which command as root. Edit it with visudo, audit it with sudo -l -U.
• PAM is the row of checkpoints of every login; pam_access decides who may log in, first match wins.
• Every rule you set on one machine stays on that one machine.

Quick check¶

You have just set rules on one Windows PC and one Linux server, by hand. Tramuntana Apps has twelve PCs. Next: one place that knows every user and every rule — Domains and directory services.