On Wed, Jul 29, 2009 at 6:30 AM, Sam Mason
<address@hidden> wrote:
On Wed, Jul 29, 2009 at 12:57:28PM +0300, Bahadir Balban wrote:
> Capabilities are an elegant way to achieve security. I am questioning,
> does it have to be object-based[1]? My worry is that things can get too
> complicated especially on a design such as a microkernel.
>
> [1] By object-based I mean programmatically created objects being
> referred by remote clients.
Conceptually, no. The ocap model just models the evolution of a graph
where the nodes are objects and the edges are capabilities. The power
of the model is in its simplicity, the less distractions in the theory
(hopefully) means less problems in reality.
What Sam is saying here -- but didn't actually state -- is that your definition of "object based" doesn't agree with the rest of the field. There is nothing wrong with the concept you are describing, but you should find a more appropriate name for it.
> But getting back to capabilities, in my understanding a capability is
> just a structure that describes a resource as well as the security
> permissions on it and its owner.
No, a capability is *only* an unforgeable reference to an object.
A capability is a *protected* structure that designates (names) a resource and specifies a signature of operations (methods) on that resource that may be invoked through that capability. It is common for the storage of that method signature to be implemented by permission bits, and in the early literature capabilities were characterized as "designation plus permissions". The definition I'm giving is more consistent with modern semantic theory.
But the protected part is important. In order to be a capability it must be non-forgeable. In order to achieve some of the behavioral properties that we often associate with capability systems, it must not merely be encrypted bits. The reason is that we want to be able to constrain the propagation of capabilities, and if they are just bits then we really can't do that.
shap