[cap-talk] Communicating conspirators, MLS, and the Boebert attack

[Jed at Webstart]

At 10:50 AM 7/20/2006, Karp, Alan H wrote:
>...
>That's exactly the point.  Declassification must be tightly controlled.
>If the Trojan Horse can declassify, it can clearly write anything it
>wants to Low.  The whole point of MLS systems is that declassification
>is an external, carefully audited process.  Hence, the controls are
>mandatory because neither the process running High nor the process
>running Low makes the declassification decision.

But then how does communication happen between the levels?
Can you point to a system where that works?  It didn't in NLTSS
(wasn't mandatory) because we allowed some processes (servers
in any case) to explicitly declassify data.  Trojan one of those servers
and the MLS constraints are broken.  If it does in some other system
or systems I'd very much like to see how the communication between
levels works in such systems.

> >...Put any subject (process, active object) in the position of being able to
> > communicate data between other processes at distinct levels
> > and you create the possibility of violating the MLS criteria.
> > This situation has nothing to do with the communication of
> > capabilities per se, it related to the opportunity to communicate
> > data.
> >
>Not if what can be communicated is controlled by a third party.

Then in that third party is where I put my Trojan, confused deputy, etc.

>In MLS,
>we have one-way channels between High and Low.  Low can write to high
>requesting classified data.  High cannot write that data to Low.  High
>can only ask the declassifier to make it available to Low.  If the data
>should indeed be High, the request will be denied.

Simple, right?  Sure I understand how such MLS systems can
work with such restricted communication.  In the systems I'm
familiar with it always had to be a human being in the declassification
channel.  Do you know of system with automated declassification
mechanisms?  If not then you have a partitioned system.  If so
then I'd like to know what that algorithm looks like!
> > ...
> > I don't believe it does.  All it means is that it can fetch the
> > capability through some capability that it has....
>
>Boebert's attack is based on the ability of Low to write data that High
>can read and use as a capability.

I don't agree.  Please see my more detailed discussion of the
Boebert attack on DVH in the more recent:

http://www.eros-os.org/pipermail/cap-talk/2006-July/005437.html
(Boebert attack on DVH)

>In a c-list system, such as DVH, what
>can Low write to High that High can use as a capability?  Certainly not
>the c-list index.  That refers to a different capability in each
>process.

I argue certainly yes, a c-list.  One can obtain a capability to
a c-list (a directory) at least in any DVH-like system (e.g. RATS)
that I am familiar with.  Such a system would be pretty useless
if there wasn't a means to store capabilities somewhere.

I'm not sure I understand what you mean when you say the
c-list refers to a different "capability" in each process.  Certainly
every process has a c-list.  However, there's no reason why two
processes can't share capabilities to the c-list of a third, e.g.
to store and retrieve capabilities.  I think the question you have
to ask for Beobert is how the MLS rules work for storing and
retrieving capabilities.  It seems reasonable to me (and I think
to Boebert) to assume that capabilities are treated like data
in that regard.  That is, no write down and no read up.

> > Unclassified process <->  Trojan Horse secret process <->
> > Secret process
> >
>That's not the right picture.
>
>Read:  Low <- High Trojan Horse <-> High process
>Write: Low -> High Trojan Horse <-> High process
>        Low <- Declassifier <- High Trojan Horse <-> High process
>
>The Trojan Horse can write whatever it wants to the declassifier, but
>Low only sees what passes that filter.
> >
> > I think the NLTSS system can be seen as something of a compromise
> > in this space.  It allowed communication between processes with
> > different clearances, but only by processes authorized to act as
> > declassifiers (communication level lower than clearance).  Servers
> > (acting across levels) necessarily had this property.  Most processes
> > did not.  User processes were not allowed to communicate between
> > levels, and so weren't subject to the sort of threat Boebert considers
> > with his Trojan Horse.
>
>An excellent model, which is why Boebert excluded it from his analysis.

Perhaps, but it was certainly a capabilities as data model.

Also I'll note that there were no automated declassifiers in NLTSS.
No algorithm was trusted with such a task.

We did have servers that could in principle declassify data.  The
file server is a good and simple example.  The file server has access
to the disk system.  It can read and write data anywhere.  In fact it
used metadata to divide the disk into logical files.  Each file has a
classification level.  When a request comes in to read data
from a file, the request itself comes in with a classification level (nominally
the clearance level of the process making the request) and the request
specifies a level at which the data should be sent out.  If the level of the
file exceeds the level the message should be sent out at, the requested
read fails (simple security).  If the request is a write and the level of the
incoming data exceeds that of the file, then the write fails (star property).

Note that it is the level of the communication of the data - nothing to do
with the capabilities (though it could) - that determines the success 
or failure
of the request.  The file server never looks at the data.  No such looking
and filtering would be trusted.

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