[cap-talk] Communicating conspirators (Re: Second ABAC Google talk is now up)

[Mark S. Miller]

Eric Jacobs wrote:
> This was the only part of the presentation that I felt pretty
> dissatisfied with, and perhaps it has more to do with the treatment of
> the topic in the capability community in general than anything else, but
> I feel the arguments that were given were not convincing and did not
> resolve the question that was originally asked.
> 
> The original comment at 29:15 - (something like this, the audio is
> fuzzy)
> 
> "So, I just want to say here as well: I don't want Bob to have a
> reference to Carol except in the scope of the Foo operation. I
> don't want Bob to be able to save that (access?)..."

Yes. As other's have pointed out, the correct response to this question was 
actually the Caretaker pattern, which, by fortunate coincidence, happened to 
be presented next. At the moment the question was asked, I too-quickly 
categorized it as a general discomfort with "capabilities allow uncontrolled 
delegation" and jumped to CC.


> We are told that this is an example of Communicating Conspirators
> and that will be addressed later in the presentation. This main
> points made are:
> 
>    - that CC cannot be solved with permissions;
>    - that CC cannot be solved with capabilities;
>    - that the capability security model cannot solve CC because
>      in its formal system, CC is not distinguishable from other
>      situations that are not security problems
>    - and therefore, CC is an impossible problem to solve (!)

My explanation was awkward. (Later, it didn't even sound that coherent to me, 
and I know what I was trying to say.) The key point I was trying to make was 
that the problem statement's initial conditions are:

* Bob is stateful. Bob and Mallet are in communication, and Bob may alter his 
state in response to messages received from Mallet. Whatever power has been 
granted to Bob, Bob may make use of it in any way he'd like, and how he 
decides to use it may depend on his state. Bob's interests are assumed to 
coincide with Mallet's interests.

The problem statement is:

* Enable Alice to ensure that Mallet does not have authority to use the power 
as he'd like.

AFAICT, the initial conditions already contradict the problem statement. The 
situation Alice has already been presumed to allow already includes the 
situation we'd like Alice to be able to prevent.

I don't believe the argument I make above is specific to capabilities, ACLs, 
or any other access control system. I think it applies to any possible access 
control system.


> I am not fond of the idea that because (1) we do not know how to
> abstract something,

Yes, I don't know how to make a *formal* argument that would apply to any 
possible access control system. I could imagine, perhaps using SCOLL, trying 
to make an argument that would be applicable to any access control system that 
could be described in HRU/SCOLL terms - in terms of update rules to the access 
graph. I leave it to people more skilled with formalism than I to try to 
determine whether or not such an argument could be made formally within this 
framework.


> or (2) we do not currently have the technology to
> implement those abstractions, that it is not possible that someone
> really wants it. In this case I believe both of those conditions are
> true.

I don't understand your #2.


> In fact, I regard the original question as a very legitimate request,
> and something that is going to become more important as our computing
> systems become more interconnected and the simple answer of "cutting 
> Mallet's line" becomes less of an option. Disconnnecting a process
> from the internet will soon become a sacrifice of usability for
> security, if it is not already.

Regarding the question that was actually asked, the Caretaker does cut exactly 
the line that needs to be cut, without any unnecessary loss of functionality 
elsewhere.


> Overall though -- I have really enjoyed the presentations so far.
> Thanks!

Thanks for the kind words! And thanks again to you and everyone for the 
feedback. The talk will be much better next time as a result.

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM