[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Codezero v0.2 Capabilities

From: Bahadir Balban
Subject: Re: Codezero v0.2 Capabilities
Date: Tue, 08 Dec 2009 14:08:18 +0200
User-agent: Thunderbird (X11/20090817)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]