[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