[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