OSDev.org

Hello,

I read about microkernels, and capabilitys were mentioned. I couldnt find out how they work/are implemented. I read that they kinda are like unix file handlers, but when i looked how seL4 does it, it seemed different.

I dont know much about OS development. I know C, Virtual Memory and Security Rings and Kernel-mode. Please keep that in mind.

TIA

I read that they kinda are like unix file handlers

You mean file handles, I think. And yes, they are - in the sense that file handles are capabilities; they represent the capability to perform certain operations on a file. In a true capability-based system however you probably don't obtain most capabilities by something as simple as a call to open(...); the point is that capabilities are granted (from other processes for example).

I couldnt find out how they work/are implemented.

There's no one way to do it.

when i looked how seL4 does it, it seemed different.

Well then, you've seen one way to do it. So your question seems a bit vague. What exactly are you asking?

davmac314 wrote:

I read that they kinda are like unix file handlers

You mean file handles, I think. And yes, they are - in the sense that file handles are capabilities; they represent the capability to perform certain operations on a file. In a true capability-based system however you probably don't obtain most capabilities by something as simple as a call to open(...); the point is that capabilities are granted (from other processes for example).

I couldnt find out how they work/are implemented.

There's no one way to do it.

when i looked how seL4 does it, it seemed different.

Well then, you've seen one way to do it. So your question seems a bit vague. What exactly are you asking?

Thanks for your reply. The problem with the way seL4 does it, is that i dont understand it. The only way, i could think of, to implement capabilitys, is that every process has an array of capabilitys. And each process identifies its capabilitys internally, by using a index to the capability. Is this a way capabilitys are implemented or is it bad?

And what must an capability be able to represent? I could think of a Pointer to local memory or a reference to an other capability, and that seems enough to me.

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.

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?

bmj wrote: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).

Mostly, yes. But: technically in unix there are "file descriptors" and "file descriptions" and "file handle" is not a correct term. A file descriptor is a just a token (an integer) which identifies a file description. You can look at file descriptors being capabilities which provide access to a file description and to operations on the file it refers to.

But, compared with "traditional" capabilities, file descriptors/descriptions are not fine grained.

bmj wrote:Conceptually the only way they seem different to me, is that they cant be shared with other processes.

File descriptions can be shared with other processes. Every time a process forks the child inherits its file descriptors and the file descriptions they refer to (this can be suppressed but it is the default). File descriptions can also be transferred to other processes via unix sockets.

And can a process pass a capability, for one of its local ressources, to another process? Or is that not required?

It's not part of the definition of capability, but it's a fundamental piece of how capability systems work.

Also, since you were asking about implementation, wikipedia has this to say:

A capability is typically implemented as a privileged data structure that consists of a section that specifies access rights, and a section that uniquely identifies the object to be accessed. The user does not access the data structure or object directly, but instead via a handle. In practice, it is used much like a file descriptor in a traditional operating system (a traditional handle), but to access every object on the system. Capabilities are typically stored by the operating system in a list, with some mechanism in place to prevent the program from directly modifying the contents of the capability (so as to forge access rights or change the object it points to). Some systems have also been based on capability-based addressing (hardware support for capabilities), such as Plessey System 250.