Least privilege

What it looks like on a VPS

Only root has UID 0. Each service runs as its own user with a nologin shell. Administrators use sudo with narrow rules rather than unrestricted access, and nobody logs in as root directly. Group memberships such as docker are treated as root-equivalent and kept short.

How to apply it

Start with an audit of who and what holds root today, then tighten sudo rules and service accounts. The steps are in our guide to users, sudo and least privilege.

Find what runs as root right now

The NIST glossary describes least privilege as restricting access privileges to those needed for assigned tasks. On a server, the quickest way to measure how far you are from that is to list what runs as root and what listens on the network:

ps -eo user,pid,comm | awk '$1 == "root"'
sudo ss -tlnp
systemctl show -p User myapp.service

The first command lists every process owned by root. Expect a long list, including kernel threads shown in square brackets, so look for application names rather than counting lines. The second lists listening TCP sockets with the owning process (-t TCP, -l listening, -n numeric, -p process). A database, an application server or a queue worker running as root and listening on a network port is the pattern to fix first. Some daemons legitimately start as root only to bind a port and then hand work to an unprivileged user, so the question for each one is whether it ever drops privileges. The third command shows which user a systemd service is configured to run as: an empty value means the unit has no User= setting and so normally runs as root (a unit using DynamicUser= is an exception). Keep the output as a baseline, and compare it after every deployment.

Measure and tighten a service unit

Once you know which service is too powerful, systemd can both score it and restrict it. According to the systemd-analyze manual, the security command estimates how exposed a unit is and gives an overall level from 0.0 to 10.0, where a higher value means less sandboxing. It counts only protections systemd itself provides, and a high score does not prove the service is vulnerable. It is a to-do list, not a verdict.

systemd-analyze security myapp.service
sudo systemctl edit myapp.service

The edit command creates a drop-in override, so the vendor's unit file stays untouched. Add a few conservative settings:

[Service]
User=myapp
NoNewPrivileges=yes
PrivateTmp=yes
ProtectHome=yes

Per the systemd documentation, NoNewPrivileges stops the service and its children from gaining privileges through setuid bits or file capabilities, PrivateTmp gives it its own /tmp and /var/tmp, and ProtectHome makes /home, /root and /run/user inaccessible. Restart the service, test it, and run the score again. Raise restrictions one at a time so you know which one breaks something. The users, sudo and least privilege guide covers the account and sudo side of the same work.

Related terms: UID 0, Root login, authorized_keys, Docker socket, sudoers, /etc/passwd, sudo.