4.3 Objects And Protections
First of all, every kaneton object is identified by a unique identifier and manipulated over the microkernel with a capability.
As said before, many kaneton objects are built by linking objects together.
The figure below illustrates this hierarchy of the kaneton objects and the kaneton microkernel itself.
Recall that the kaneton microkernel was designed to fit distributed operating systems requirements.
This means that, contrary to classical operating systems, reserved objects must be secured to avoid security issues.
For example, on a classical operating system, when a user process asks the kernel for opening a file, the kernel just returns a file descriptor. In this context, there is no need to secure the file descriptor since this descriptor is private to the process which asked for it.
In a distributed operating system, the returned file descriptor may be transfered over the network to the caller. Then, in this context, an attacker could intercept the file descriptor and use it to access the file.
A distributed system needs to protect the objects over the network. So, the kaneton designers decided to use capabilites to handle this security issue.
A capability provides an easy way to allow a task of the system to access a privileged object via a very simple cryptographic technique.
Although this concept was introduced for the distributed operating systems needs, the kaneton designers decided to exploit the capabilities' properties.
Indeed, the capabilities also permit a task to restrict the permissions of an owned capability and then to distribute this restricted capability to other tasks. Then, these tasks get the right to access the privileged object but this right is limited by the capability's permissions the capability's owner previously set.
This concept is very interesting, even in classical operating systems, because it allows tasks to handle the security on the objects they own.
To illustrate this concept, consider a program which allocates a segment of physical memory. Then it decides to allow another process to only read this segment. It will so generate a less privileged capability and give it to the other process. Therefore, the second process will be able to read the segment but not to write it.
A common capability format includes the object identifier, the permissions of the capability on the object listing the allowed operations, a check field ensuring security and other specific fields like for example the location of the service, a lifetime etc..
The figure below illustrate the capability generic format used in the Amoeba distributed operating sytem, this capability format being used by every server of the system.