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

[Micah Brodsky]

(Please forgive my tardy follow-up. I've fallen behind on this highly active
bundle of threads!)

> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org 
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Jed 
> at Webstart
> Sent: Thursday, July 20, 2006 5:38 PM
> 
<...snip...>
> >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!
<...snip...>
> 
> 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/ 
> 

We built an experimental system on Asbestos this spring that used automated
declassifiers. 

We found only four sources of information on which a declassification
decision could be reliably based:
- The taint (classification level) of the data to be declassified
- Who the data was going to (in particular, what classification level was
the data to be emitted at)
- How much information was to be declassified (# of bits)
- Any prior history of declassification

Notably, the actual contents of the data being declassified proved useless.
I believe this to be very generally true. If ever any untrusted code could
have run at the input classification level and influenced the data to be
declassified, arbitrary secrets could be steganographically encoded within.
(The data itself is likely to be usable only if the declassifier is willing
to accept all code that could've influenced the data as part of the TCB --
which is possible, albeit not so useful.)

Surprisingly, these limited sources of declassification advice were enough
to build a system with interesting features. We constructed a mock-up job
application site, where employers and candidates could search for good
matches while carefully restricting access to their private information.
Each individual employer or candidate kept the sensitive parts of their
profile protected by a private taint category but could selectively reveal
their information with a personalized declassifier.
(Note that Asbestos does not use a static hierarchy of MLS levels but rather
allows categories to be constructed dynamically, forming a highly branched
lattice.)

As an example, suppose employer E has a job offering which it did not wish
to reveal to its competitors. Meanwhile, candidate A is seeking a new job
but does not wish to reveal this fact to its current employer. E and A can
further these privacy goals by minimizing the amount of information they
reveal and the number of principals they reveal it to.

E can query the database of job seekers and analyze their resumes to find a
set of interesting candidates. However, the individual candidate profiles,
and even the fact that E found them interersting, remain classified until E
obtains permission from the candidates' individual declassifiers to export
the profiles. Simultaneously, the candidates' declassifiers cannot reveal
anything about the job offer, even the fact that they were queried, because
they're run under E's taint. 

The candidates' declassifiers can profitably decide whether or not to reveal
the profile based upon the identity of the employer (Is it on a blacklist
including my current employer and its close affiliates? Does the employer
have offices in cities I'm willing to work? Or any other fact that can be
independently verified about the employer.) and the taint of the input data
(Do they just want my general profile, or also private identification and
SSN, or some other private category of data?).

(As for the other two possible sources of advice, we never found quantity of
information particularly useful. Also, because we ran the declassifiers
under the 'if I told you, I'd have to shoot you' model, the only history
available would be for that particular <candidate, employer> pair. This is a
little unfortunate, because candidates might like to rate limit their
disclosures; that would be possible if employers were willing to reveal to
the candidates the fact that they queried them.)

Of course, you could have constructed such a system entirely at user level
with heaps of trusted, custom code. But, by having the OS enforce much of
security policy, we were able to cut down the size of the TCB and even allow
substantial chunks to be composed of untrusted, user-uploadable code --
which is kind of cool.

--Micah