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

[Karp, Alan H]

Jed wrote:
> 
> In one sense, however, NLTSS may not qualify as "pure" capability by
> his description.  That is, in NLTSS it's data that carries a 
> classification.
> It carries such a classification in any message exchange.  If
> a process with clearance secret tries to send a secret message to
> a process with clearance unclassified (e.g. across the network),
> the message data will be labeled as secret and when it hits the
> unclassified process it won't be delivered (classification error).
> 
That's what Boebert would classify as a modified capability system.
> 
> This I believe is where push comes to shove with regard to 
> MLS.  Namely,
> do you allow ANY communication between levels in such a system?
> As soon as you allow a simple request/reply exchange between processes
> with difference clearance levels, then you admit 
> discretionary transfer of
> information from HIGH to LOW - regardless of what 
> capabilities are involved.
> Either the request or the reply must go from HIGH to LOW and therefore
> can constitute a declassification.  Put a Trojan Horse into 
> that situation
> and you can violate the principle on which the simple 
> security and the star
> properties are based - whether or not there are suitable 
> objects involved.
> 
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.
> 
> For the case of the concern with MLS (dealing with data at various
> classification levels) the situation is even more stark.  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.  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.  Hence, High cannot
proxy for Low in a way that violates policy.  In the other direction,
High cannot send Low a request that violates policy because the
declassifier will refuse to forward it.  Hence, Low cannot proxy for
High.  The hard part is deciding what the classifier should do with each
such request.
> >
> >'In order for a program to exercise access to a storage object, the
> >program must possess a capability granting the desired access.
> >"Possess" in this sense means that the program has access to the
storage
> >object which contains the capability.'
> >That assumption means the capability is data in "an unmodified
> >capability machine", one lacking special hardware to distinguish
> >capabilities from data.
> 
> I don't believe it does.  All it means is that it can fetch the 
> capability through
> some capability that it has.  I know certainly in the RATS systems
> (that was based quite closely on DVH) the low_object could easily
> have been an unclassified directory (there were no classifications in
> DVH or RATS, but I think you have to imagine how they might work
> for such a discussion) and the RW_low_object and R_high_object
> both files to unclassified and secret data respectively.
> 
Boebert's attack is based on the ability of Low to write data that High
can read and use as a capability.  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. 
> 
> 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.

_________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories 
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Karp, Alan H.vcf
Type: text/x-vcard
Size: 423 bytes
Desc: Karp, Alan H.vcf
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20060720/32ce6153/attachment.vcf