[cap-talk] Capabilities and LDAP (was Reducing Ambient user authority in a Type Safe /Memory Safe OS.)

[Monty Zukowski]

On Fri, Dec 18, 2009 at 7:18 PM, David-Sarah Hopwood
<david-sarah at jacaranda.org> wrote:
> Monty Zukowski wrote:
>>>> 3) Central Management- This also includes LDAP/AD/NDS tree integration.
>>>> I still think you must provide this to get company acceptance. Getting
>>>> people to move to Capabilities is a big enough task with adding social
>>>> structure changes.
>>>>
>>> The problem is that people have conflated authorization decisions and access decisions.  Once people
>>> understand the difference, they'll see that they can still use LDAP to make authorization decisions and use
>>> capabilities as the embodiment of those decisions.  For example, users might worry about delegating to
>>> someone who should not have the right.  You can build a system that uses LDAP to help.
>>
>> I'm curious to understand what you mean there, how LDAP can be used to help.
>>
>> For the system we're building, the basic idea is that user info is
>> stored in LDAP.   We have sets of capabilities called capsets (think
>> of a folder of bookmarks), and use those in place of groups.  Group
>> membership just means the user has been given the handle to a specific
>> capset.
>>
>> Inside our system, we take the union of the capsets a user has as the
>> real capset they have to work with.
>
> If that means what I think it does (the system allows a request whenever
> a subject has some capability that would satisfy it), then you've lost many
> of the advantages of capability systems. To prevent confused deputy attacks,
> it's critical that a subject is required to explicitly present the
> capabilities that it wants to use with each request.

I don't understand the distinction you're trying to make.

> I'm also concerned when you say that *users* have capabilities.
> Much smaller-grained subjects (e.g. processes or objects) should be able
> to hold capabilities independently of whether they are acting directly
> as agents of a user.

Users can create scripts and endow them with the capabilities they
need to do their work.  The capabilities are bound to the script when
the executable is created, from that point on it is independent of the
user.  The script itself is a capability which can be handed to other
users either as an opaque execute-only facet or as a full facet with
the ability to inspect and edit the source.

The reason I was focusing only on users is because that's where the
bridge to/from LDAP comes into play.  From LDAP we authenticate users
and find out which capsets they initially have access to.

Monty