[rurban]

fine grained.

there's no god-mode who can do everything. there's no universal kernel level. micro means only minimal things happen in the kernel or at root level, like routing messages.

even windows understood that those times, when they did split Administrator from System. linux followed then with system users for certain services. but capabilities only allow certain calls at certain times. there's no setuid 0, only cap this and cap that for this admin user for a certain time range.

BTW, SElinux is the default on a proper linux like Redhat. I use it daily. I also have to adjust the ssh caps, not just the firewall settings. Everybody wants that, just not the debian nobs.

[vacuity]

There is omitted detail here. Capabilities are a great way to determine access control (IMO, they are essential in general as a user-facing model too). However, that still leaves the question of who gets what capabilities. For the network service to be able to hand out network capabilities, it itself must have at least as much authority, and it had to get that authority from some other source of capabilities. There must be some privileged component that forges all capabilities, and actually distributes enough authority to make the system usable. For example, as soon as a human user becomes relevant, the system's user-avatar must be able to command authority, in a way that may seem sweeping. This could mean directly or indirectly changing which program is the network service, which means the ability to influence all networking activities, which is no small authority.

An agent logically has all the capabilities necessary to do what the agent should be able to do. The sum of capabilities of an agent indicates "the worst that can happen" if the agent is malicious. It makes sense that if a network service is malicious, all networking activities can be subverted. Still, the storage activities shouldn't be subverted, and of course the network service wouldn't have the storage service capability. However, if a user is malicious, anything could go wrong that the user is normally trusted to not make go wrong. Correspondingly, the user must have an expansive sum of capabilities.

Capabilities are themselves simple, but that is the mechanism perspective. Access control policy is an entirely different beast, and any mechanism at best minimizes the risks.

[theamk]

This all sounds very reasonable as long as servers/services are involved. Linux has capabilities for this purpose, and systemd goes a long way towards the vision you describe - daemons which do not need root and instead get all capabilities from the supervisore process.

However, were were talking about "sudo" and this is purely interactive tool (I am sure some people run sudo non-interactively, but we can all agree it's a bad security practice). So, how does this nice capabilities vision mesh with the idea of "administrator user"?

From what I see, it's not much different. Instead of "sudo" which verifies user identity+permissions and then gives out "root" or some other user, we have some other hypothetical tool ("become-admin"?) which verifies user identity+permission and gives out powerful system-changing capabilities. Frankly, I don't see much difference - it's the same security model either way.

(A related argument I've seen is "you should not need sudo for common tasks like update software or configure network" - but on modern Linuxes, you don't need sudo for that already, this is done via dbus + polkit calls. No "proper microkernels" required, that is already deployed everywhere.)

[vacuity]

I was also the one who wrote a sibling comment saying that capabilities aren't magical, but I do think they are excellent as far as any mechanism goes. Linux doesn't nearly go far enough in capability-based security, and merely adapting practices fails to make full use of capabilities. It's a bug if I have to verify my identity often for a routine task, whether it's through sudo or polkit. User friction is bad for security in many ways. Instead, configure the service once to have the capabilities you would give it each time anyways. Take it out of the user's hands and set it down on the desk (still in their control, just not taking up space). polkit is not quite there, whereas capabilities easily confine all programs (don't have to support polkit), are trivially flexible in behavior while being both secure and invisible by default, and provide control to the proper agents (users and involved programs). Capabilities turn access control from a hard problem plus various pitfalls to just a hard problem. Rather than an incrementally better solution, changing paradigms here is a good idea. Although Unix already most has capabilities through file descriptors, so in some sense its "everything is a file" philosophy can't go far enough.