nullplan wrote:
Unless I severely misunderstood what a capability is, that is not it. A capability is an entitlement a privileged entity grants to a non-privileged entity, typically a kernel to a process. So the process asks the kernel for a capability, and the kernel grants or denies the request. If the capability is granted, then it can be used in further API calls to the privileged entity to do things. Consider file handles again: A normal process cannot write on disk. It lacks the access needed to perform raw I/O on the disk itself, and typically, an application doesn't want that, either (imagine having to add partition tables and file systems to Chromium). But file handles are a way for the kernel to allow a process to perform disk I/O in a way that is safe for the users of the system.
You should not mix up those capabilities with the Linux mechanism for partial root privilege. Those are also called capabilities, but are not capabilities in the sense of this discussion.
What a capability actually is in the kernel API is up to you. But they must somehow refer to kernelspace objects, clearly identifying what is being allowed and what isn't. That way, not only do you reduce the usable surface area for an attacker, you also make it possible to inherit capabilities to subprocess, which I contend is absolutely crucial.
Thanks for your reply.
Are file handles capabilitys or not? To my knowledge they only grant access to a single ressource, cant be forges, can have different privilages and can be copied (locally). Conceptually the only way they seem different to me, is that they cant be shared with other processes.
And can a process pass a capability, for one of its local ressources, to another process? Or is that not required?