[cap-talk] Rob Meijer: Communicating conspirators...

[Rob]

>>
>>I fully agree that a capability to any entity such as that file will
>>always have the same clearance level assigned to it.
>
> Hmmm.  Don't people use the term "classification" for the information
> and "clearance" for subject access?  I realize they come from the
> same space (well ordered set), but your use of "clearance" in the
> above sentence throws me a bit.  Were you being careful and trying
> to make a distinction or was the above "clearance" use a bit loose?

I absolutely am trying to make a distinction:

1) Clasifications for data
2) Clearances for capabilities/communication channels helt by
   processes/objects.
   This means a process can posses 'a set' of clearances not just a single
   clearance. Tainting and encapsulating is used to make sure ss and *
   properties are never violated.
3) Tainting for the statefull clasification of process/object memory.

I hope this clarifies my use of the terms and makes some kind of sense to
you?

>>Let me try to make
>>things clear with a short example based on the problem we are discussing.
>>
>>Lets say Allice holds a capability to a file with data classified HIGH.
>
> Now it seems we're back on track with the classification vs. clearance
> terminology.

Yes, the data in the file has a clasification, but in my view a capability
to that same file has/implies a clearance (that hapens to be on the same
level as that of the data clasification.

>>Lets also say that Bob holds a capability to a second file classified
>>as LOW.
>>Now lets say that both Allice and Mallet hold capabilities to Bob.
>
>>Allice can choose to share the HIGH capability with Bob and Bob could
>> than
>>choose to proxy or delegate that capability to Mallet.
>
> You haven't yet said anything about the clearances of Alice, Bob, or
> Mallet.
> I guess that's because from you're perspective they don't have fixed
> clearances, but instead a sort of floating clearance that gets defined
> as they get "tainted".   Is that right?

No, they "have" a set of fixed clearances defined by their initial set of
capabilities, effectively "only conectivity begets conectivity" but now on
a "per clearance level" basis, what is I think the thing that makes assiging
clearances to capability feel as the right thing to do.
The tainting is in fact the (dynamic/statefull) clasification of the
process/memory that determines what capabilities can be used by the
process
at a particular time/state.

>>What I am sugesting is that we give Allice a HIGH capability to Bob
>>and give Mallet a LOW capability to Bob. Bob being connected to the
>> outside
>>world with capabilities on different levels would as a result of this
>>multi layer connectivity require to be wrapped (unless it is assigned
>>an explicit declasification role) by the proposed proxy (lets call it a
>>tainting-*-proxy for now) This means that both Allice and Mallet would
>>have (proxied) capabilities to the same object (Bob) that would each have
>>a different clasification level.
>
> Of course I can read the words, but in the case of the above I'm afraid
> I don't know what they mean.  Let's just take the beginning.  You say
> that Alice has a HIGH capability to Bob and Mallet has a LOW capability
> to Bob.   What's the difference?  How do these two capabilities differ?

The difference is in the clearance they imply. When Allice uses the
capability to invoke functionality of Bob, Bob will guaranteed be tainted
HIGH at the moment the invocation is serviced.While if Mallet invokes
functionality of Bob, Bob will guaranteed be tainted LOW when the invocation
is serviced.

> Until you bring clearances into the discussion (where you can start
> applying the simple security and the star properties - no read up
> and no write down) I don't see how you can apply any policy.

I hope my clarifications abouve have brought clearances back where I
thought they were all the time ;-)

>>This would mean that if Allice hands the HIGH capability to Bob that
>>Bob should be able to use it when and only when Bob is tained HIGH.
>
> OK, I think the above clarified your model for me.  If I understand you
> are assuming that subjects have a dynamic clearance level that you
> refer to as their "tainting".  Seemingly this clearance level starts out
> LOW (as low as possible, though I think perhaps in some sense
> undefined) and can only increase during the normal course of any
> subject's communication.  Sending a message doesn't effect a subject's
> clearance, but whenever it receives a message it's clearance level raises
> to the level of the message (it becomes "tainted" to the level of the
> message).  Clearance levels only increase for subjects except in
> the case where they are "respawned" (loose all their memory), when
> their clearance gets reset to low.
>
> Is that your model?  (apparently not - read "versions" below).

It is very close, but the subtle difference is essential. It always
possesses a static set of clearances determined by the capabilities it had
at time of conception. The tainting is a dynamic clasification of process
memory that determines what capabilities (and thus what clearances) it can
use at a particular time.

>>Bob would in no way be able to proxy or delegate the HIGH capability to
>>Mallet as there is no HIGH connectivity between Bob and Mallet.
>>Bob would however remain capable of servecing Mallet with information
>> from
>>the LOW file once Bob is restored to LOW tainting.
>
> If I'm understanding your setup properly (check me above) then I can see
> where the problem lies.  Remember that in the communicating conspirators
> situation it is assumed that the conspirators (Bob and Mallet in this
> case)
> are actually able to communicate.  As I understand the way you have set
> things up, once Bob receives (or perhaps accesses - I'm not quite clear
> on just when the "tainting" happens)

I'm not sure about that one either. Opinions seem to differ wheter
capability transfer caries data. If it does (as I conservatively asume)
it would be at the moment of receiving the capability, if it does not it
can be untill the moment Bob uses the capability.

> the HIGH capability from Alice
> Bob becomes tainted to a level that Bob can no longer communicate
> with Mallet - violating the assumption of the communicating conspirators
> situation.  At that point you've changed it into a confinement problem.

Bob does not lose its ability to comunicate with Mallet, only the high
tainted part of its state does. I agree that I've moved the solution into
the confinement area, but I do think it still is a solution for the
(subset of) CC problem.

> I read the rest of what you wrote, but I think I'll stop commenting at a
> detailed level at this point since I think understanding the issues above
> are required for any further discussion.  My remaining comments are at
> a higher level.
>
> One issue I would like clarification on is this:
>
>>...
>>
>>It is I think this last issue that may be difficult at times, but if
>>Bob is designed with care it should be able to prevent much of the
>>data version controll issues. The point of this version controll is that
>>if a variable is updated at a higher level, is restored at a lower level
>>and is then updated at that lower level, once Bob again gets elevated
>>to the higher level there are two equally valid versions of the variable.
>>It is than up to Bob to decide what version to use or on how to merge
>>the two versions.
>
> For me in the above you've introduced a new and seemingly much
> more complex twist to your model that goes much beyond what I
> thought I was understanding.
>
> Am I to understand that subjects in your model can keep (hold, have,
> access - I'm not sure what term to use here) multiple versions of
> variables (data) at multiple classification levels (different "versions")?

The basic would be to create a simple model by abstracting away complexity
into the tainting-*-proxy class or mechanism in such a way that:

* To single clearance level objects communicating with Bob, Bobs
  tainting-*-proxy would be Bob and they would exist without any notion
  of other clearance levels.
* To a process with multiple clearance levels moving between tainting levels
  would retain all state that could possibly be retained without much
  inconvience.

For the retaining of state the tainting-*-proxy offers a scratchpad for
Bob to store al its variables on. The tainting-*-proxy could mostly
abstract away that it has multiple versions of this scratchpad internaly,
but there is one situation where the tainting-*-proxy can not abstract
this away.

* Bob in H does X="foo"
* Bob drops to L and does X="bar"
* Bob is restored to H and will need to indicate
  if it wants to:
     * restore X to "foo".
     * keep the newer X value "bar".
     * create a new version of X combining the two.

It would be great if this to could be abstracted away,
but I dont believe it can. Proper design of Bob however could
make sure this would hardly ever be needed.

>>Apart from this complexity for the tainting-*-proxy
>>wrapped objects, I believe further complexity could be confined to the
>>one time implementation of a tainting-*-proxy class or mechanism.
>
> Hmmm.  If there really is anything like the above going on in your model
> then I'm afraid I have to suggest that you may be getting lost in the
> complexity
> of an unusable model.

That is what I am trying to avoid by putting most of the complexity into
the tainting-*-proxy class or mechanism. The resulting model would than
permit a very intuitive multi level capability design. I especialy like
the multi level version of "only conectivity 'on a specific clearance
level' begets conectivity 'on that clearance level'" that I think a
successfull implementation of a tainting-*-proxy could offer. I believe
that it is actualy the simplicity of this that would make the resulting
model very usable from both an MLS and a capability view of things.

>> >>* In order to adress usability, a process should be able to "forget"
>> any
>> >>   information potentialy gathered by using a "top secret". After
>> >>   forgetting (being respawned and restoring any data/capabilities
>> >>   gathered at preceding relevant levels) the security property would
>> >>   be sufficiently met.
>> >
>> > Any such "forgetting" or respawning seems to me to effectively happen
>> > outside the scope of the process itself.  If it was done within the
>> scope
>> > of the process then of course the process could choose not to forget
>> > and that would allow it violate the mandatory sense of the MLS
>> controls.
>>
>>Yes, if it is not possible to wrap Bob in a way where the
>> tainting-*-proxy
>>would have the power to respawn it, it would not work.
>
> We seem to agree on that much.
>
>> >> >>When you define this proxy to be both bag and membrane, the proxy
>> can
>> >> >>keep track of the 'tainting' of the object.
>> >> >
>> >> > I'm still not sure what you are referring to when you refer to
>> >> "this proxy".
>> >> > Do you mean Alice or Bob (or Mallet) or some construction serviced
>> by
>> >> > one of them (e.g. Alice?).
>> >>
>> >>I think I would mean 3 separate proxies, one encapsulating Bob, one
>> >>encapsulating Mallet and potentialy one encapsulating Allice.

I seem to have been mistaking implementation and design here. In fact only
an object with capabilities at multiple clearance levels would require
such a proxy. Sorry for the confusion.


>> > Do you have a working system Rob?  If so (or even if not) how do you
>> > deal with the issue of classification of data for client/server
>> > communication?
>>
>>No I don't, only some POC code of parts of the functionality that
>>have not been glued together into a full POC.
>
> Sorry, what does "POC" stand for?  Who is supporting/funding your work?
>

POC = Proof Of Concept, a simple demonstrator to show the concept could
work. A POC can be used to try and convince management to aprove a real
project proposal and thus invest some more substantial resources.

Rob