Overview
All the permission mechanisms in this module serve one guiding principle: least privilege — grant only the access strictly necessary, nothing more. This capstone lesson ties permissions, ownership, and special bits together around that principle.
Learning objectives
- Define the principle of least privilege.
- Apply it to files, accounts, and services.
- Explain why it limits the impact of compromise.
Core concept
Least privilege means every user, process, and file should have the minimum rights required to function — and no more. Applied across Linux:
- Files — set the tightest permissions that still allow legitimate use (avoid world-writable, restrict secrets).
- Accounts — operate as a regular user, elevate with
sudoonly when needed, and avoid unnecessary powerful group memberships. - Services — run each under a dedicated, unprivileged service account, not root.
- Special bits — grant setuid/setgid only to trusted programs that genuinely require them.
How it works
Least privilege works by shrinking the blast radius of any mistake or compromise. If a process running as a confined user is exploited, the attacker inherits only that limited access — not the whole system. If a file is readable only by its owner, a compromise of another account cannot expose it. Every access you don't grant is an avenue an attacker can't use. The principle turns Linux's permission tools into a coherent defensive strategy rather than isolated settings.
Practical example
Consider a web application: the files are owned by and writable only to the www-data service account (not root, not world-writable); the service runs as www-data; secrets like keys are 600 and owned by the account that needs them; and administrators use sudo for maintenance rather than a shared root login. If the web app is exploited, the attacker starts confined to www-data's limited access — a far better position for defenders than if everything ran as root and files were world-writable.
Cybersecurity relevance
Least privilege is one of the most important principles in all of security, and Linux permissions are how it is enforced at the OS level. Its violations — overly broad permissions, services as root, excessive sudo/group rights, needless setuid binaries — are among the most common and impactful findings in assessments. Designing systems around least privilege both prevents many attacks and contains those that succeed, making it foundational to hardening and to the offensive mindset of hunting for excess privilege.
Common mistakes
- Granting broad access "to make it work" (e.g.
777, running as root) instead of the minimum needed. - Leaving unused privileges in place (stale group memberships, unnecessary setuid bits).
- Treating least privilege as optional rather than the default design principle.
Key takeaways
- Least privilege means granting only the minimum access necessary to files, accounts, and services.
- It is enforced through tight permissions, regular-user operation with scoped
sudo, confined service accounts, and minimal special bits. - The principle shrinks the blast radius of compromise; its violation (over-permissive files, root services, excess privileges) is among the most common and serious security findings.
Check your understanding
- In one sentence, what does the principle of least privilege require?
- How does applying least privilege limit the damage when a single process or account is compromised?