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

[Rob]

>>With clasic MLS a process/object has something called a (static)
>> clearance
>>level. With capabilities however, it is not the process or object that
>> has
>>clearance but the capability.
>
> What makes you think so?  I don't believe such an interpretation makes
> any sense.

I believe that in order to fit clearance in any way into a capability model,
the most clean way is by having the clearances bound to the capabilities,
thus when a capability is delegated the full authority this capability
carries is delegated, including the clearance. This however raises some
problems with respect to the object receiving the capability, I'll get to
that later on.

> In "classic" MLS systems both the subject (analogous to a
> person), generally referred to as the subject's "clearance", and the
> object
> (holding information - think file), generally referred to as the objects
> "classification", have levels chosen from the same well ordered set of
> labels.  The traditional problem is to assure that information can't be
> read up (simple security property) or written down (so-called * property,
> a thoroughly meaningless name as far as I'm concerned.  Why don't
> they just call it "read up" and "write down"?), e.g. as described in:
>
> http://www.erights.org/elib/capability/duals/boebert.html
>
>>By using an MLS style clearance like lable
>>for each capability, making the lable an intrincic part of the
>> capability,
>>a proxy can be created around each objects in order to help the object
>>to become able to handle capabilities with different values for this
>> label.
>
> It sounds like you are associating the label with the object (through the
> capability), though I'm not sure if you intend to allow multiple
> capabilities
> with multiple levels to point to (reference) the same object.

Yes I do believe multiple capabilities to the same object could have
differing clearance levels depending on how they are designed to work
together with other capabilities. The key issue is that capabilities that
should be used together by a particular object "at a particular event"
should for that object be capabilities with the same clearance level.
The key point to the proposed patern is that an active object during its
life can traverse to a higher tainting by receiving (or restoring)
capabilities with a particular clearance and/or data with a particular
clasification, and can traverse to a lower tainting by having its state
dropped to this lower level (respawn and restore). At each tainting level
the object can use only capabilities at the same level as its active
tainting, and can at that point in time only be accessed with capabilities
with that same clearance level.

> To my
> understanding
> doing so wouldn't make sense as it's the data in the object that's
> traditionally
> associated with the label - the "classification" of the
> information.  Let's just
> think file for now.  Suppose I have a secret file.  That is I consider the
> information in the file to be "secret" (labeled secret).  I really think
> it
> meaningless to consider MLS without also having such labels ("clearances")
> for the active entities (e.g. processes).  The simple security property
> says that a secret process should not be able to read a top secret file
> or write to an unclassified file.

I believe you could bring this back to:

* A process should not be able to use its capability to write an
  unclasified file after it has been tainted to "top secret" by
  using any capability marked as "top secret".
* 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.

> If we have the same view on that much of the model, then perhaps
> we can further this discussion.  If we don't agree on that much then
> perhaps you can explain where you feel we differ.
>
>>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 seperate proxies, one encapsulating Bob, one
encapsulating Mallet and potentialy one encapsulating Allice.

>>If the object
>
> Which object (process - as you seem to be referring to an active object)?
>
>>fetches a
>>capability from the proxy (bag) or receives one in a method call, the
>>object will get "tainted" to the highest value of a capability it holds.
>>If after receiving a high labled capability the object tries to use a low
>>labled capability, the proxy would interpret this as an aparent flaw in
>>the object, and the object could be killed and be restored in its state
>>to a previous level. Its a bit more complicated than this, but this
>>is about the rough picture.
>>
>>This means the MLS properties get effectively deminished to:
>>
>>'An object may not combine capabilities with different labels'
>>
>>The proxy patern for this is a bit complicated, but the resulting
>>property is quite usefull for solving the described problem.
>
> I would like to understand the mechanism you are getting at.
> However, I'm afraid I do need some additional details.  Can you help?
>
> I really don't understand how you can talk about MLS if your active
> entities (processes, active objects) don't themselves have labels.
> Isn't that the essence of what MLS is trying to achieve (can't read
> up, can't write down)?

They would have a tainting level at any given point in time, and with
respect to this tainting level the two would due to the bidirectional
nature of the ipc for Bob translate to:

* Dont process events resulting from capabilities to Bob unless/untill Bob
  arives at a tainting level equal to that of the clearance level
  assosiated to the capability used.
* Dont use capabilities to for example Mallet if these have an assosiated
  clearance lower than that of the active tainting level.
* Using of a capability with a higher clearance level assosiated than the
  active tainting level, this implicitly increases the tainting of
  Bob to that of its capability to Allice.
* Receiving data that is marked with a clasification higher than the current
  tainting level implicitly increases tainting for Bob to the clasification
  level of the data.
* When the tainting of Bob grows to restrictive, Bob can choose to drop
  state to a lower tainting level (by requesting the BobProxy to be
  respawned)
* When Bob has nothing more to do at its current tainting level and the
  BobProxy has blocking calls pending, the BobProxy may choose to have Bob
  drop its state (by respawning Bob)

It would be the BobProxy job to enforce all of the abouve.

> While I can understand associating a
> classification
> with a capability to an object (as we did in our NLTSS system), any
> such association seems in some sense to be a simple convenience or
> expedience as the real label must be on the information stored in the
> object - it's "classification" level.  Having distinct levels for two
> different
> capabilities (references) to the same object makes no sense to me.
> Does it to you?  If so, can you explain?

To me it makes more sense than any other incorporation of MLS principles
into a capability model. I hope the abouve description is sufficient to
at least make you understand what the proxy patern would aim to do with this
strategy.

> Perhaps this is a topic that could best be communicated interactively
> (e.g. by telephone?)?  Feel free to give me a call.  You can find my
> telephone number in:

If it is still unclear please let me know, I can be on the IRC (ircnet)
between 20:00 and 23:00 CET . Phone is not a good option, my verbal
english
is increadably poor.

Rob J Meijer