- \n
- fine-grained<\/strong> Instead of having unlimited power: Break down root privileges into smaller, more granular privileges.<\/li>\n
- File Capabilities<\/strong> Instead of Set-UID: Bind the required permissions directly to the binary files.<\/li>\n
- Capability Sets<\/strong> Configure the following in a targeted manner: Permitted, Effective, Inheritable, Bounding.<\/li>\n
- Privilege Separation<\/strong>: Keep services, tools, and tasks strictly separate.<\/li>\n
- Defense-in-Depth<\/strong>: Supplement capabilities with sudo, roles, and logs.<\/li>\n<\/ul>\n\n\n
\n![\"\"](\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-serververwaltung-8291.png\")
\n<\/figure>\n\n\nWhy separate root privileges?<\/h2>\n\n
A root account grants Full access<\/strong> on the file and process levels, but that\u2019s exactly what invites serious errors. One wrong command or exploit is enough to bring down an entire installation. I therefore limit far-reaching actions to what is absolutely necessary, thereby reducing the extent of damage and recovery time. The principle of least privilege keeps services small and manageable. I disable direct root login, rely on roles, and maintain comprehensive logs.<\/p>\n\n
Linux Capabilities Explained in a Nutshell<\/h2>\n\n
Linux capabilities break down traditional root privileges into clearly defined Privileges<\/strong>. Each process receives only the building blocks it actually needs to perform its task, such as binding to ports below 1024 or sending special signals. This allows me to avoid the previous all-or-nothing approach. The kernel manages these building blocks on a per-process basis and enforces them strictly. This ensures that control remains granular and traceable.<\/p>\n\n
From a technical standpoint, I link skills to either Processes<\/strong> (based on their capability sets) or to Files<\/strong> (as extended attributes
security.capability<\/code> ELF binaries). Whenexecve()<\/code>-When the kernel starts, it merges the file capabilities with the process sets: Put simply, permitted capabilities from the file attribute, combined with the inheritable permissions of the calling process, are combined into the new Permitted set and\u2014if marked as such\u2014simultaneously activated in the Effective set. This avoids Set-UID workarounds and keeps privileges visible and verifiable.<\/p>\n\n\n\n![\"\"](\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux_rechte_besprechung_3820.png\")
\n<\/figure>\n\n\nUnderstanding Capability Sets in a Process Context<\/h2>\n\n
Every process has several sets of permissions, which I can specifically control<\/strong>. The Permitted Set defines what a process is generally allowed to have. The Effective Set specifies what is currently active. The Inheritable Set determines which privileges can be passed on to child processes. The Bounding Set sets a strict upper limit and prevents processes from exceeding it.<\/p>\n\n
Ambient Capabilities and Securebits<\/h2>\n\n
In addition to the well-known sets, there is the Ambient Set<\/strong>, which at the
execve()<\/code> does not expire automatically. I use it when an unprivileged process specifically needs minimal permissions across multipleexec<\/code>-across levels (such as when calling external utilities). Ambient permissions are only included in the effective permissions if the called file itself does not set any file capabilities\u2014this is how I prevent unintended escalation.<\/p>\n\nWith the Securebits<\/strong> I control the details of the transitions, such as whether a process is allowed to retain its previously set capabilities after its UID changes (
keepcaps<\/code>) or whether he is generally prohibited from obtaining new privileges (no_new_privs<\/code>). In practice, I configure Securebits strictly and sacrifice convenience in order to break exploit chains.<\/p>\n\nFile Capabilities Instead of Set-UID<\/h2>\n\n
I'm replacing set-UID binaries with file capabilities to reduce the risk of lower<\/strong>. Instead of granting root privileges to a program, I just set the necessary permissions. A typical change looks like this:
setcap 'cap_net_bind_service=+ep' \/usr\/bin\/meinserver<\/code>. Withgetcap -r \/<\/code> I check which files contain capabilities. This significantly reduces the number of potential escalation paths.<\/p>\n\nIt is important that file capabilities are applied only to ELF Binaries<\/strong> work. Interpreter scripts (e.g., Python, Bash) do not reliably inherit them. In such cases, I encapsulate the privileged action in a small, statically checked helper program or use socket activation so that my service doesn\u2019t have to bind itself in the first place. I also keep a close eye on file permissions: Capabilities grant special privileges with respect to the kernel, but do not replace none<\/strong> standard ACLs or POSIX permissions.<\/p>\n\n
Skills are quickly lost when copying or packing:
cp<\/code> without XATTR support, incorrectly setumask<\/code> or remove a build artifact from a file system without extended attributessecurity.capability<\/code> Implicitly. That's why I work in a reproducible manner and use:cp --preserve=xattr ...<\/code>,tar --xattrs<\/code>,rsync -X<\/code>. In package builds, I explicitly set file capabilities in the install script, test the installation in a clean VM, and verifygetcap<\/code> in the CI.<\/p>\n\nPrivilege Separation with Realistic Scenarios<\/h2>\n\n
A web server needs access to ports 80 and 443, but not to kernel modules or system reboots, so I set CAP_NET_BIND_SERVICE<\/strong> and nothing else. A backup agent is allowed to read and write files, but cannot change the network configuration. A monitoring tool is granted read access to metrics but has no rights to make changes. These restrictions confine attacks to a local scope rather than allowing them to affect the entire system. It is precisely this separation that keeps services manageable and misconfigurations in check.<\/p>\n\n\n
\n![\"\"](\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/balancing-linux-capabilities-5618.png\")
\n<\/figure>\n\n\nCombining sudo with Roles<\/h2>\n\n
Capabilities are no substitute for a clean Role Structure<\/strong>, they complement them. I grant sudo privileges sparingly, use full command paths, and steer clear of blanket rules like \u201eALL=(ALL) ALL.\u201c I log every permission grant. Groups consolidate responsibilities, while capabilities set technical limits on processes. This creates clear lines of responsibility without excessive privileges.<\/p>\n\n
Common Pitfalls and Best Practices<\/h2>\n\n
- \n
- Do not use CAP_SYS_ADMIN as an abbreviation:<\/strong> This law is a catch-all. I'm replacing it with more specific alternatives (e.g.,.
CAP_SYS_CHROOT<\/code>,CAP_SYS_TIME<\/code>,CAP_SYS_NICE<\/code>) or skip it altogether.<\/li>\n- File permissions remain strictly enforced:<\/strong> Capabilities do not generally override DAC. Without
CAP_DAC_OVERRIDE<\/code> The kernel continues to respect owner and mode bits. So I continue to grant only minimal read permissions.<\/li>\n- Path hardening:<\/strong> If I assign file capabilities to a binary, I prevent PATH spoofing (absolute paths in
sudoers<\/code>, write permissions disabled on directories in the search path).<\/li>\n- Drop early, drop often:<\/strong> Processes may start with more permissions than necessary. I remove unnecessary permissions immediately after the critical step (
prctl()<\/code>\/libcap) and setno_new_privs<\/code>, where possible.<\/li>\n- Limiting inheritance:<\/strong> I keep the Inheritable and Ambient sets small. Child processes must not open any new doors.<\/li>\n
- Check the build and deployment pipeline:<\/strong> I confirm that
security.capability<\/code> is preserved, and no staging steps (container layers, NFS, artifact scanners) remove XATTRs.<\/li>\n<\/ul>\n\nOverview of Key Capabilities and Risks<\/h2>\n\n
Before assigning privileges, I clearly define the privileges required and assess their risk. The following table shows typical examples along with their effects and classifications. I always consider alternatives to avoid granting excessive privileges. In particular, CAP_SYS_ADMIN<\/strong> I grant them very sparingly. Whenever possible, I replace broad privileges with targeted, narrow ones.<\/p>\n\n
- File permissions remain strictly enforced:<\/strong> Capabilities do not generally override DAC. Without
- File Capabilities<\/strong> Instead of Set-UID: Bind the required permissions directly to the binary files.<\/li>\n
![\"\"](\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux_capabilities_tech-office_4738.png\")
\n<\/figure>\n\n\n![\"\"](\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/entwickler_schreibtisch2345.png\")
\n<\/figure>\n\n\n![\"\"](\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-capabilities-8123.png\")
\n<\/figure>\n\n\n