Access Control Lists

Many people like to think that capabilities and ACLs are in opposition – but
this is not entirely so. ACLs can be used to decide whether to grant capabilities
or not. In practice, this would mean that either the system would give all
capabilities a user has to each program running on their behalf, or it would be
prepared to hand them out on demand as the program requested them (the former
technique would look more like a traditional capability-based programming
model and the latter more like an ACBR one).
Note that this technique gives no advantage, of itself, over standard ACBR,
unless the “unit of mistrust”, so to speak, is smaller than the program itself.
For example, if the program uses a capability-secure language, then it could
segregate the use of capabilities internally – so even though the program as a whole has access to all of the capabilities, each module only has those it needs to
do its job. This may help when an attacker figures out how to make the program
behave in unintended ways – in a pure ACBR system, the subverted module
would have access to all of the permissions the whole program had access to.
In a well-designed capability version of the program, the module would only
have access to a small subset of those permissions (in the form of capabilities,
of course).
It is also important to remember that ACLs are applied at the time the
right is exercised, whereas once a capability is handed out it does not generally
change, so the simplest implementation of an ACL controlled capability system
is not equivalent the direct use of ACLs – if the ACLs change, the capability
system may not reflect those changes.