[cap-talk] What does the [defense?] security community really fear from capabilities? (was: Support of MLS policies (was Re: NLTSS))
capability at webstart.com
Fri Jul 13 04:54:07 EDT 2007
At 05:54 PM 7/12/2007, Pierre THIERRY wrote:
>Scribit Jed Donnelley dies 12/07/2007 hora 11:18:
> > I really think the most fundamental issue is that of communicating
> > conspirators. That community really hasn't come to grips with the
> > fact that the only way to block (control) communication of a
> > permission (an access right) is to block communication. That access
> > control and confinement are intimately entwined. That if there is two
> > way communication between A and B then A and B can share access
> > rights.
>I think this is dangerously overs-simplifying the issue. This is
>probably true in a capability-as-data system, but not in an object
I disagree - softly and gently, but firmly. This issue has come
up again and again on this list, but I recognize that it is still,
sadly, contentious. I believe this again amounts to arguing that
the communicating conspirators problem can be solved.
I am merely saying that if through no other means, A and B can
proxy access to any object references that one but not the other
holds and they wish to share. They become communicating
If any effort is made or mechanism imposed, as you suggest:
>In such a system, A and B may have a two-way communication channel where
>a filter object is interposed, that either only let data through or let
>capabilities go through based on some criteria.
then there will be a justification for developing library support
to easily proxy object access so as to communicate needed (POLA)
object access across such two way channels - despite any
efforts/mechanisms to "only let data through or let capabilities
go through based on some criteria."
I do believe this issue is fundamental. If we can't come to agreement
on this issue within this community then I fear we have no hope but
to accept the arguments that I regard as ill founded in support of
ACLs and 'user' based (ambient authority) computing environments.
To be sure, we can utilize mechanisms that provide support for what
Alan Karp refers to as "Voluntary Oblivious Compliance". That is,
situations where monitoring is put into place in support of policies
to avoid inadvertent violations. However, we have to be very careful
in such actions both to remember that it is only voluntary compliance
that can be assisted (efforts at involuntary blocking can be surmounted
by proxying) and that any efforts that seem to get in the way of
legitimate collaboration (any communication of access from one
active object to another through an available communication
channel) will be counter productive.
It may be illustrative to consider the Horton mechanism in
this context. In the example in the submitted version of
the only means for A to communicate to B is through the capability
P1. This path does not provide for direct communication of the object
reference P2, but it does provide for data flow (assume two way).
If A wished it could communicate proxy access to P2 to B. In this
way A could allow B to reference the object "c" with the responsibility
falling to Alice, e.g. rather than having the responsibility fall to
Bob as it does if A communicates the P2 reference through P1 so as to
be translated into P3 when it arrives at B.
I admit that I somewhat despair of getting this topic widely
enough understood so that it can be used to effectively defend
the object/capability paradigm. Perhaps there is hope that
even if not fully understood the value of POLA will win out
over any imagined advantage from user/ACL access control
mechanisms over object/capability access control mechanisms
regarding thwarting communicating conspirators.
I stand ready to again be pounded by objections at this point.
For those who do object, I hope I can refer you to MarkM's
technically excellent though oratorically somewhat awkward
presentation on this point in his Google talk, where he
discusses his taxonomy for delegating a permission:
and then he discusses specifically the communicating
conspirators case at:
and if helpful you can view his summary of the cases right after at:
and fortunately MarkM was asked specifically about the
communicating conspirators problem, so he discussed why
it isn't possible to "solve" this problem here:
I do think this discussion is a bit rough (having listened to it now
several times - hoping MarkM agrees), but I hope if you still feel
that somehow the communicating conspirators problem can be 'solved'
either with user/ACL based access control or with object/capability
based access control, you will carefully listen to the discussion
there - and then if not satisfied object away again on this list.
Here is where MarkM argues most directly that this problem can't be
Again pretty rough I'm afraid, but there you go for a second opinion.
More information about the cap-talk