[cap-talk] Confinement subset of the CC problem ?? (Rob Meijer: Communicating conspirators)

[Rob]

> At 07:18 AM 7/22/2006, Rob wrote:
>>...
>>I will try to put my assumption in a statement:
>>
>>"If you can define a confining proxy that abstracts away confinement and
>>would allow a single active object to effectively and naturally exist at
>>multiple levels at different levels at different times with the maximum
>>allowed (ss and * property enforcement) retention of state, than this
>>object can be defined as Bob in a subset of the CC problem. Doing so
>>will effectivly move the CC problem into that of the partialy solved
>>confinement problem."
>>
>>If we can agree on this statement we may be able to again start
>> discussing
>>the tainting-*-proxy that I proposed to fill the requirement in this
>>statement.
>
> Rob,
>
> I believe you might benefit from spending some time considering the
> KeyKOS model of MLS that Bill Frantz pointed out, e.g.:
>
> http://www.eros-os.org/pipermail/cap-talk/2006-July/005453.html
>
> (sorry, I don't know why, but I wasn't able to find Bill's original
> message in the archive, only my reply to Bill and his reply to me?).
>
> I think there's an important distinction that you (Rob) should
> consider between what you are referring to as a proxy (which I think
> I understand, but you may mean more) and the TCSEC monitor
> that they describe for KeyKOS.
>
> The important distinction I think is that the idea of a proxy is that
> once an object is proxied, the proxied capability can be sent anywhere
> and the proxy server gets no information about where the proxy is
> being referenced from.  It's certainly true that any given process
> (active object) may be confined and not able to further share
> (delegate) a proxied capability, but some other processes may
> receive such a proxied capability and have a broader opportunity
> to delegate/communicate.  Any confinement is separate from
> the proxying mechanism.

Hmm, aparently I have not been at all clear about delegation.
Maybe the folowing compartmenting picture would make things
finaly clear.

Picture each clasification level as a horizontal
compartment like floors in a building. Now picture a tainting-*-proxy
and its content (active object) as a an elivator between the levels
with two people in it, one 'untrusted' (the encapsulated active object)
that may interact with with anyone on the active level there exist
capabilities from and to.
The second 'trusted' one being there to first kill and resurect (with
maximum retention of state allowed by the MLS properties)
the first one and to send the elevetor to other levels if entities
on that level need to comunicate with the first one in the elevator.

If this is done right the first person in the elevator will hardly
notice he is in the elevator at all, or that he is comunicating with
people on different levels, and it is that fact that makes this model so
appealing to me.

> The idea of the TCSEC monitor, as I understand it, is that
> processes (active objects) are isolated (confined) to their
> levels except for specific sharing that they can do through
> the TCSEC monitor.  Every capability that a process has
> to the TCSEC is labeled with the clearance level of the access
> (perhaps more?).

Yes I understand, it is a formal requirement at the higher levels
to have levels and borders between leveles each running in their own
distinct resource pools, and I assumed that given earlier discussions
about unidirectional IPC that MLS usage of capability design should
thus be limited to those levels that don't explicitly require that
high level of isolation. That is I considered capability design to be
a good and simple lightweigt alternative for the MA part of the MLS
spectrum.

> Whenever a request is made to share access through the TCSEC
> monitor, the monitor can tell what level the object is being shared
> from and to and can reduce access accordingly.  For example,
> access to segments (to use the term from the "On Access Checking
> in Capability-Based Systems" paper) that are being shared
> down can be have their read access removed.  Similarly access
> to segments being shared up can have their write access removed.
>
> I think it would at least be helpful (to me if to no others) to get some
> sort of mapping between the terminology used in a description like
> the KeyKOS description with the terminology you are using.  I would
> like to understand how your proposed mechanism compares to that
> of the (also only proposed) KeyKOS TCSEC monitor - which I seem
> to find easier to understand than I do your proposal - e.g. your
> statement above, which I don't otherwise know how to react to.

I believe the main difference is in what is being locked down to a level.
In what you describe the 'processes' are being locked down to a clearance
level. I know that this is required in the higher MLS levels, but I
would be glad if I could use capability design between the lower
levels. In my proposed design the capabilities are being locked down
to a clearance level instead, allowing processes with capabilities on
multiple clearance levels to somewhat move between the levels during
their lifetime. The later results in a more natural way of programming and
thus in shorter development times imho. An added bonus is as I stated that
I believe it would allow the definition of a confinement subset of the CC
problem.


Rob