[cap-talk] "Ambient capability"
Matej Kosik
kosik at fiit.stuba.sk
Fri Jul 10 17:06:29 EDT 2009
Rob Meijer wrote:
> On Fri, July 10, 2009 18:59, Mark Miller wrote:
>> POSIX "capabilities" are not capabilities. They are not
>> capabilities-as-rows. They are not capabilities-as-keys. And they are
>> not object-capabilities. As explained in Capability Myths Demolished
>> (see the large table), they actually have more similarities to ACLs
>> than they do to any capability model.
>>
>
> Correct, I was mistaking.
>
> AppArmor might be the real example, being a system that is documented by
> its creators to be an ambient capability system:
>
> [quote]
> Consider Lampson's classic access control matrix, where you have all
> your subjects (processes doing the operations) across one edge, and all
> your objects (files and processes being operated on) along the other
> edge, and the matrix cells contain permitted operations. Lampson's
> matrix is the maximally expressive form of access control, but it is so
> large as to be unmanageable. All access control schemes are abstractions
> on this space to simplify it to make it manageable.
>
> AppArmor is a particular abstraction on this space, where we profile
> each row (process) by what application it runs, and then list the
> columns (files) it can access, and in what mode. This is the exact dual
> of ACLs, which put access lists on a file of who can access them. This
> makes AppArmor a kind of capability system (in the security
> theory−head
> way, nothing to do with POSIX.1e "capabilities"). However, because
> confined entities cannot pass around AppArmor permissions as
> first−class
> objects, it is called an "ambient capability" system.
> [/quote]
AFAIK what he had in mind:
http://wiki.erights.org/wiki/Ambient_capability
is not what you have in mind.
More information about the cap-talk
mailing list