Tech News
← Back to articles

Capsudo: Rethinking Sudo with Object Capabilities

read original related products more articles

I hate sudo with a passion. It represents everything I find offensive about the modern Unix security model:

like su , it must be a SUID binary to work

, it must be a SUID binary to work it is monolithic: everything sudo does runs as root , there is no privilege separation

does runs as , there is no privilege separation it uses a non-declarative and non-hierarchical configuration format leading to forests of complex access-control policies and user errors due to lack of concision

it supports plugins to extend the policy engine which run directly in the privileged SUID process

I could go on, but hopefully you get the point. Alpine moved to doas as the default privilege escalation tool several years ago, in Alpine 3.15, because of the large attack surface that sudo brings due to its design.

Systems built around identity-based access control tend to rely on ambient authority: policy is centralized and errors in the policy configuration or bugs in the policy engine can allow attackers to make full use of that ambient authority. In the case of a SUID binary like doas or sudo , that means an attacker can obtain root access in the event of a bug or misconfiguration.

What if there was a better way? Instead of thinking about privilege escalation as becoming root for a moment, what if it meant being handed a narrowly scoped capability, one with just enough authority to perform a specific action and nothing more? Enter the object-capability model.

In an object-capability system, there is no global decision point that asks who you are and what you might be allowed to do. Authority is explicit and local: a program can only perform an action if it has been given the capability to do so. This makes privilege boundaries visible, composable, and far easier to reason about, shifting privilege escalation from a question of identity to a question of possession.

Inspired by the object-capability model, I’ve been working on a project named capsudo. Instead of treating privilege escalation as a temporary change of identity, capsudo reframes it as a mediated interaction with a service called capsudod that holds specific authority, which may range from full root privileges to a narrowly scoped set of capabilities depending on how it is deployed.

... continue reading