(See Prohibiting Delegation for context)
Bob and Mallet are properly in communication, and Bob and Mallet both wish Mallet to have the power. They are Communicating Conspirators. Can Alice arrange to prevent Bob from giving Mallet the Power? The answer is simply no. Bob can circumvent any such attempt by creating a message laundry:
The reason the message laundry cannot be prevented is that it does not even admit of definition. The definition of what you're trying to prohibit is indistinguishable from the statement of the situation that is being allowed -- except for a change in terminology used to describe it. The allowed situation?
The prohibited situation?
Although Bob and Mallet may share interests, and although they may be in communication, Bob should be prohibited from enabling Mallet to make use this power which has been granted to Bob.
I understand why lawyers would think this is a defenceable difference -- they get paid to litigate meaningless distinctions. But I'm boggled that more than a generation of computer science and engineering could have gone off the rails, and stayed off the rails, thinking this prohibition was desireable.
This unenforceable prohibition is the only case that ACLs can express but capabilities cannot. However, neither ACLs nor any force in the universe can prevent what is here prohibited, so this extra expressiveness only gives the users a false sense of security -- misleading them about what inabilities of the other players they may count on.
Other Statements of the Same Impossibility
The above observation was first made in 1981 by Jed Donnelley's "Managing Domains" paper:
There have been in depth discussions on the cap-talk list regarding the communicating conspirators problem.
Rob Meijer's "Tainting Proxy Pattern" may solve a related problem, and bears examination.
Even though the SPKI standard adopted a do-not-delegate bit, section 4.1.1 of the SPKI rfc correctly explains why this bit is unenforceable:
The argument in favor of no control [of delegation] is that if a keyholder is given permission to do something but not the permission to delegate it, then it is possible for that keyholder to [...] set up a proxy service, signing challenges or requests for the intended delegate. [...]
(This explains the relationship of SPKI to capabilities.)
Likewise, Stefan Brands' deservedly famous thesis states:
In communications or transactions that are not face-to-face, remote lending cannot be prevented, regardless of whether privacy-protecting certificates or fully traceable identity certificates are used. Indeed, the ``lender'' might as well perform the entire showing protocol execution and simply relay the provided service or goods to the ``borrower.''
In the crit-mail thread "Communicating Conspirators", rooted in here, Ralph Hartley establishes that other security architectures, including some possible ACL systems, can enforce a subtle prohibition, having to do with delegation in the Communicating Conspirators scenario, that capabilities can neither express nor enforce: for Alice to prohibit Bob from delegating the power to Mallet in such a way that Bob does not have the ability to revoke that delegation. To put it another way, while one cannot construct a security architecture in which Alice can prevent Bob from delegating to his communicating conspirator Mallet, under certain conditions, one can construct a security architecture in which Alice can prevent Bob from preventing Bob from preventing Mallet from continuing to use this power, even though Alice can't achieve this only with pure capabilities. The conditions?
Let's outline three hardware scenarios. In all scenarios, computers are assumed trustworthy as of the moment they are picked up, or delivered from, the store. (There's no justification for this assumption, except that no one could make any progress without this assumption. I hope you are as terrified as I of the implications of this.)
As an engineer I'm willing to give up on some theoretical possibilities if I feel their cost exceeds their value. Despite Ralph's demonstration of this subtle expressiveness gap of pure capabilities under certain conditions, E remains a pure capability architecture.
Unless stated otherwise, all text on this page which is either unattributed or by Mark S. Miller is hereby placed in the public domain.