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

[Jed at Webstart]

At 11:17 PM 7/24/2006, Rob wrote:
>...
>
>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

Fun metaphor.  Using that metaphor I think the way the KeyKOS
monitor was designed (Bill will have to correct me if I'm wrong) is:

The TSEC monitor accepts capabilities (object references) from
requests on any level and delivers them to any other requested
level AFTER having appropriately reduced their access.  Capabilities
to segments (files) delivered up have their write access removed and
capabilities delivered down have their read access removed.
Seems pretty simple to me.

>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.

The above now sounds much more complex.  Can you motivate
it a bit for me (others)?  What additional facility (e.g. for what
practical application) to you hope to achieve?

>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.

Does its appeal derive from your expectation that one will be able to
run existing application in such an encapsulation or do you imagine
applications needing to be written specifically for this environment?

> > 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,

though with the KeyKOS TCSEC architecture (boy, I'm sure taking
on some KeyKOS design here...) it does have the ability to pass
segment access between levels.  It just explicitly enforces the
simple security and the star properties during such cross level
communications of capabilities.

>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.

I assume "MA" above is Mandatory Access control?

To me capability architectures are more directly focused on the
discretionary side of things.  Namely POLA - sharing just the needed
permissions to get a job done.

However, given that you have capabilities for POLA and confinement,
something like the KeyKOS TCSEC comes nearly for free.  That's why
it has more appeal for me than your tainting model which I'm afraid I
still don't fully understand at this point.

> > Whenever a request is made to share access through the TCSEC
> > monitor...
>
>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.

By "use a capability design between the lower levels" do I take you
to mean that you somehow want to be able to allow direct communication
between processes at different levels with a capability mechanism
somehow enforcing a workable (by what policy standards?) MLS mechanism?

>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.

Sorry Rob, but try as I might I don't see it.  I guess this is one of those
cases where I think we would really have to stand up at a white board
and scratch out a more detailed design before I'd get it.  Perhaps others
can chime in here if any are following and might be able to contribute.

--Jed http://www.webstart.com/jed/