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
