[cap-talk] "Ambient capability"
Rob Meijer
capibara at xs4all.nl
Fri Jul 10 16:29:27 EDT 2009
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]
More information about the cap-talk
mailing list