[cap-talk] gauntlet - one way IPC considered useless, practical MLS?

[Jed at Webstart]

At 12:22 PM 1/22/2006, Rob J Meijer wrote:
>The simple fact is that

>1. fully persistent two way communication is
>incompatible with untrusted (that is un-audited, not unknown) handling any
>secret. A second fact is that

>2.  promoting code to a 'trusted' level is
>exceptionaly expensive for anything but the most trivial re-usable
>components.

>These two facts combined make that any practical system
>that works with clasifications of data will need to use one-way
>communication channels at some points in their design.

>3.  In my experience the added complexity with one-way channels is an
>acceptable payment for avoiding or minimizing code audits, that I believe
>are much more expensive given the complexity involved with proofing fully
>connected and interconnected subsystems to enforce the required policies
>by subjecting
>the system design and the resulting code to a full scale certifying auditing
>process.

I'd like to focus for this message on the above which seems to me to
fairly succinctly summarize the argument for one-way communication
in an MLS environment.

I think it would help me quite a bit to hear about some examples of
some real needed one-way communication instances from your
experience Rob.  I have the impression (from my own experience,
some shared below) that such things are rather rare and unusual.

Here's an example that I'm familiar with.  For a time I worked in
the "Engineering Records Center" at LLNL.  That is in the engineering
part of the lab.  In particular it is the organization that stores all
the engineering drawings.  Many of these drawings are classified.
Of course the classified drawings are only stored in a database that
is only accessible from the classified network.

One of the requirements that we had was to make available needed
unclassified drawings for the people doing classified engineering.  The
way this was done was to collect a list of needed drawings (e.g. during
the day), then write them to a tape (put the write ring in, write the
drawings), take the write ring out and move that tape to the classified
side, read the drawings and put them into the database - labeled as
unclassified but made available on the classified network.  This was
the scenario even into the late 1990s.

I find it a bit interesting considering a facility for the Internet that might
play a similar role.  Assume for the moment that everything that might
be needed on the classified side could be accessed through a Web
URL.  One could set up a facility on the unclassified network where
URLs could be accessed for the purpose of making them available
on the classified side.  Access a URL and it and it's content get queued
for the one-way channel to the classified side.  After they are received
on the classified network they could be put into a database that could
be "browsed" on the classified side so that the needed content could be
made available to users and applications on the classified network.

With such a facility there is really no need for two way communication
between the levels.  While one might be concerned that even the URLs
fetched by people with access to classified data might themselves
contain classified data - I think that is a risk you just have to take.
Beyond that there is no communication from red to black.

I mention this because it illustrates what to me seems to be the
nature of these sorts of one-way communication between levels
in an MLS system.  While such one-way communication can
well be important, I certainly don't see it as part of a dynamic
IPC system.  Consequently at this point I still stand by the
subject of this thread: "one way IPC considered useless,
practical MLS?"

I'd like to hear from Rob or others working with MLS systems
the sorts of practical one-way IPC that they have used in
their experience.  Perhaps then I and others can place
this kind of facility into context, particularly with regards
to comparing what it provides with the kinds of protections
one gets with POLA and capability (need to know) sorts of
systems.

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