Re: Codezero v0.2 Capabilities

[Bahadir Balban]

Sam Mason wrote:
> On Mon, Dec 07, 2009 at 09:09:50PM +0100, Tom Bachmann wrote:
> > Bahadir Balban wrote:
> > > When it comes to making the ipc call though, you don't pass the 
> > > capability id to the call. You pass the thread id you want to ipc to. 
> > > The system call signature is the same as if capabilities were not there 
> > > at all. But it surely gets checked, the relevant capability is found, 
> > > it's resource id is matched with the passed thread id, and resolved.
> > Moreover, this breaks (at the kernel boundary!) one important design 
> > principle (which I value): explicit designation of authority. How can 
> > your system avoid the confused deputy problem?
>
> Yup, this looks very much like you've just turned what could be a nice
> capability system into one that implicitly relies completely on ambient
> authority---namely the "capids" that a thread holds.  This is finer
> grain than the userid of a conventional process, but still feels like
> ambient authority to me.

The natural signature for operations are retained at the API level, but 
designation and permissions are kept together internally. If you want to 
do operation X, that operation X is very well described by a single 
capability in your capability list. The owner of capability for X can do 
the operation X, with so and so micro-permission allowances, and 
targeting or using so and so resources. Everything that an operation can 
do, and who can do it, is defined and kept in the capability structure.

It's only that the system expects you to know that you have that 
capability in advance, such that, you don't pass the capability to the 
kernel, you ask for the operation, and the kernel checks whether you 
have a capability that precisely describes that operation implicitly. 
The capability structure is maintained by the kernel.

I don't see a confused deputy problem here.


To your ambient authority argument, wikipedia reads:

"
Ambient authority is a term used in the study of access control systems.

A subject, such as a computer program, is said to be using ambient 
authority, if making a request that only specifies the names of the 
object(s) involved and the operation to be performed on them, is enough 
for a permitted action to succeed.

In this definition,

    * a "name" is any way of referring to an object that does not 
itself include authorising information, and could potentially be used by 
any subject;
    * an action is "permitted" for a subject if there exists any 
request that that subject could make that would cause the action to be 
carried out.

The authority is "ambient" in the sense that it exists in a broadly 
visible environment (often, but not necessarily a global environment) 
where any subject can request it by name.
"

This is not true for this case, since designation, authorization and 
ownership information is all bundled in the capability structure and 
gets checked on each operation.

--
Bahadir Balban