Alpine Linux maintainer Ariadne Conill has published a very interesting blog post about the shortcomings of both sudo and doas, and offers a potential different way of achieving the same goals as those tools.
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
doasorsudo, 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.
↫ Ariadne Conill
To bring this approach to life, they created a tool called capsudo. Instead of temporarily changing your identity, capsudo can grant far more fine-grained capabilities that match the exact task you’re trying to accomplish. As an example, Conill details mounting and unmounting – with capsudo, you can not only grant the ability for a user to mount and unmount whatever device, but also allow the user to only mount or unmount just one specific device. Another example given is how capsudo can be used to give a service account user to only those resources the account needs to perform its tasks.
Of course, Conill explains all of this way better than I ever could, with actual example commands and more details. Conill happens to be the same person who created Wayback, illustrating that they have a tendency to look at problems in a unique and interesting way. I’m not smart enough to determine if this approach makes sense compared to sudo or doas, but the way it’s described it does feel like a superior, more secure solution.
While this is a nice thought experiment, I don’t think its premise is entirely correct.
The document assumes “everything sudo does runs as root, there is no privilege separation”, we cannot have user mounted drives, or have fine grained control.
Though… sudoers config literally specific which user or group every entry runs with (root is of course an option), we had user mounts … basically forever. And SELinux + cgroups provided very fine grained control over things for a long time. Add in Polkit + DBUS + systemd… we have a “solved problem”. Or in other words… a solution seeking a problem.
Now, I admit configuring these are not easy, but perfectly possible. But I don’t think a complete new replacement would be easier on the long run either.
(Every new project starts from “clean state”, until they are hit with reality. What was the saying? “every boxer has a plan until they are punched in the face”)
This will most likely result in scenarios where “it usually results in “The new tool is broken, just give me a root shell so I can fix the server.”
Anyway, I admire the effort, but please do not work on fracturing Linux even more. We barely got over with the systemd’s trauma.
The problem exists. I agree that it’s not a simple “sudo” solution.
For example, mobile applications have some restrictions on the permissions they can have, such as location, network access, parts of user data like contacts or photos.
On macOS with Little Snitch installed (an application firewall) and permissions for some folders and APIs, you can restrict applications a bit further in the interests of the end user. However, this is not enough.
We should be able to completely separate and virtualise all applications and their access to APIs, network hosts and other resources on desktops and mobile devices. It shouldn’t be a burden for users. Every application should have a clear set of permissions it needs to operate, and users should be able to adjust those permissions in simple terms.
a_very_dumb_nickname,
The problem is… this amount of detail is just too much to handle properly. And it usually ends in back to square one (or worse).
Hence the
Android tried this and gave up. And they replaced their fine grained permissions list with a much smaller, streamlined one.
Apps used to show lists of 10, 20, or even 30 permission requests, and people were conditioned to just click “Yes”
If we really want to do something. using individual app containers, and conscious prompts, like “Steam wants to access USB SSD, shall we add (a) temporary or (b) permanent access?” could be better.
Android clearly sides with service developers (I think it’s wrong to call them application developers in this case).
If you’re a bank or a streaming service, you probably refuse to launch your app without certain permissions. The OS should prohibit this behavior and allow users to deceive an application that behave too intrusively by setting fake data or just empty data. GrapheneOS is sometimes a good example.
BTW, number two in the Top 10 paid apps for iOS is a VPN with advanced rules for filtering and routing – Shadowrocket https://apps.apple.com/us/iphone/room/6756333301
People can use such apps with enough motivation.
a_very_dumb_nickname,
I get your sentiment. But the permissions switch was done before “Do No Evil” switch. It was a good move, and only let “Internet access” pass through. (I mean Google would not block online ads in mobile games by default, don’t expect that much)
Android is a good case for a “capability” centric design, However even though it is Linux underneath, it does not apply to all Linux designs.
1 – They control the API and all restrictions. They can retroactively block apps based on more security
2 – These are only affecting user facing apps. The underlying services still depend on SELinux, Linux permissions and ACLs for basic security
3 – Most importantly, Android comes with a NEXT style “services” message system. “Here I have a document, can anything print this?” or “I have this GPS position, and I would like to start navigating to that location”
The last part is crucial, because it allows strictly subtractive permissions systems with occasional escalation with prompts (like “Can the App access Location”? prompts)
They don’t need to run other programs directly, which is the “UNIX WAY™”.