[cap-talk] (Was: Iguana) Do not grant to what or whom?, more MLS stuff

[Jed Donnelley]

(Norm Hardy, please take a look below for the "k" level definition)

At 02:15 AM 1/5/2006, John C. McCabe-Dansted wrote:
>On Thursday 05 January 2006 05:37, Karp, Alan H wrote:
> > John C. McCabe-Dansted wrote:
> > > However it seems that was just an disagreement over an
> > > implementation detail?
> >
> > I would say so, but I bet Jed believes the disagreement is a deeper
> > philosophical issue.
>
>Perhaps it is the terminology that is disagreeable - perhaps a better term
>would be "do not amplify" or "do not merge" etc. rather than "do not copy"?

The underlying question is:

1.  If I am a subject (process, active object), and

2.  I have a permission as a capability, and

3.  I am able to communicate to some other subject (process, active 
object) - e.g. through some other capability -

Can I send/grant the permission/capability that I have through that 
communication channel?

I see the above as a fundamental baseline for capability 
communication.  Only with the above are programs able to modularize 
in a POLA manner by granting selected permissions to other programs 
to perform tasks.

Others (the MLS folks at least) see the above facility (the ability 
to "copy"/grant a capability/permission through a communication 
channel to another subject) as a potential for "leakage".  That is, 
as an opportunity for abused trust.  They wish to make controls over 
capability communication (and perhaps other communication, but lets 
focus on capabilities for this discussion) "mandatory".  This use of 
the term "mandatory" means that even if a capability has been 
entrusted to a process/active object, it isn't fully trusted.  That 
is, it still isn't trusted to communicate that permission/capability 
to another subject/process/active object if doing so would violate 
some overarching policy (e.g. MLS).

In an MLS example, a process cleared to the secret level has access 
to a secret capability and a channel to an unclassified process 
(don't ask me how, that's something I haven't been able to get 
clarified in any MLS IPC model).  If the secret process tries 
(maliciously or inadvertently) to communicate the secret capability 
to the unclassified process, something is supposed to stop that from 
happening.  In the words of Anthony Hannan, "You can give your 
classified objects out without worrying, knowing that only authorized 
subjects will be able to invoke them."

This example might interest some folks - particularly the MLS 
folks.  The NLTSS system that ran production at the nuclear weapons 
design laboratory, Lawrence Livermore National
Laboratory between about 1984 and 1995, had an MLS system.  Processes 
had clearances and all communicated data was labeled with a 
classification level.  Objects such as files also had a 
classification level on the data they contained.  So here is how the 
above would play out:

A secret process, Alice, with a capability to a secret file could 
indeed send a message to an unclassified process.  In that system the 
secret process Alice could label the message as unclassified to 
effect such communication.  It could even include the capability 
(capabilities as data, think password capabilities, though I don't 
think this distinction important, they could as easily be partitioned 
capabilities) in such a message.  The unclassified process, Bob, 
could try to access (e.g. read) the classified file.  Bob would send 
a message to the file server (Alice) asking for data from the 
file.  The file server would see the request coming in, but the data 
of the request could only be unclassified.  The 'mandatory' aspect of 
the system meant that processes couldn't send or receive data at a 
higher level than their clearance.

The file server would notice the unclassified message trying to 
access a secret file and deny the request.

It might be worthwhile to also describe how a somewhat more complex 
example played out in that system to distinguish between data and 
capabilities for MLS policy.  Consider the case of a third party 
transfer.   Let's say that Alice is a process with a secret clearance 
and a secret file capability as above. Alice can request a read of 
some data from the file and can request that the file server send the 
result across some other channel to some other process (subject, 
active object), Bob.  In trying to service this request the file 
server (Carol?) will send the data out labeled as secret.  If the 
process that was the intended recipient is only cleared to the 
unclassified level, it won't be able to receive the message.  The 
file server will get an error trying to send it and report the error 
back to Alice.

In the above two examples, we have cases from a system that I 
(largely) designed and lead the implementation of (I wrote the 
message passing kernel for the main production systems which 
implemented these MLS policies) which does support MLS policy 
enforcement, at least in some sense.  Perhaps in considering the 
above we can see how I end up arguing against even such a relatively 
milder MLS system that I implemented:

Suppose Alice needs to have some service performed on her file, but 
the only process that can perform the service is an unclassified (but 
still trustworthy) process.  I admit this is stretching things a bit, 
but bear with me.  Alice tries to send her file capability to the 
service process (Bob), but gets an error that Bob is unable to access 
the data from the file for the needed processing.  Alice grumbles a 
bit about that darned MLS policy that gets in the way of her 
legitimate work and decides that she has to proxy the file.  She 
makes her request of Bob again and instead gives Bob a "file" 
capability that Alice proxies.  Now when Bob makes a read request on 
the file capability the request will go to Alice.  Alice will in turn 
make the request of the file server (Carol?).   Alice will send the 
request labeled secret and get back the data labeled secret into her 
memory.  Alice will then take the data and send it back to Bob 
labeled unclassified.  You could argue that this situation at least 
makes Alice be more clear that she is explicitly declassifying the data.

But then consider, what was it about Bob that made him (that process) 
only have an unclassified clearance?  It's a bit difficult to 
determine.  In our system even the ability to write to an 
unclassified file isn't enough to require the reduction of a 
clearance as file servers would do that all the time but still must 
run at the highest clearance level.  It is this basic issue that 
makes processes in such systems essentially always run at "system 
high".  Bob will have to run at system high to be able to provide a 
useful service to the system.  In that case the situation with Alice 
being forced to proxy a capability to get it serviced by Bob doesn't arise.

In practice at Livermore we had a classification level called PARD, 
"Protect As Restricted Data", that effectively amounted to "system 
high".  To avoid running into barriers of the sort noted above (and 
many, many more) people learned to clear all processes and label all 
objects as "PARD".  I don't believe there was ever an unclassified 
process run in earnest (except for our testing) on the system.  There 
may have been secret processes run, but if so there were probably 
fewer such runs than there were years of the systems 
existence.  That's an interesting question actually.  I think I'll 
ask some of the designers to see if any of them remember running 
processes at any level above PARD.  I warn people, especially those 
spousing MLS policy enforcement, from thinking of this as just lazy 
people working around legitimate restrictions to make life easier in 
order to thwart legitimate MLS policies that would provide real 
protection if not for the lazy users.  Real work (in that case 
nuclear weapons design) needed to get done.  If the cost gets so high 
(even at "Why use lead when gold will do?" weapons laboratories) that 
the work can't otherwise get done then people need to find a work 
around.  I urge those considering such situations to read about the 
John Walker spy case (e.g as I shared 
in: 
http://eros.cs.jhu.edu/pipermail/cap-talk/2005-November/004366.html 
where I highlight the most relevant discussion) where it was exactly 
such onerous restrictions that essentially forced all the classified 
data from the Vietnam war into John Walker's lap and thence to the 
Soviet Union.

The one situation I know of where processes at Livermore ran above 
PARD was system processes.  Because of the problems running below 
"system high" noted above, all system process had to run at a 
clearance level really high.  For that purpose we had a level called 
"k" level (don't ask me where that name comes from.  Perhaps Norm 
Hardy knows as he was there at Livermore before me when such levels 
were defined?).  "k" level was the highest level available.  All 
system processes would run at "k" level and could thus process 
requests from processes at the same or any lower clearance (in 
practice almost always PARD).

When Unix systems became readily available and started to dominate 
the high performance computing world (when Cray ported Unix to 
"Unicos" and made it available on their hardware), the first 
proprietary systems tried to support similar MLS mechanisms for 
defence applications (a major market for them).  In fact they were so 
cumbersome that they were essentially never used and they gradually 
disappeared from later systems.  As far as I know support for MLS 
policy in the system disappeared completely from the systems run at 
the US defense laboratories.  They now use ad hoc Unix groups for 
doing any sort of limited separation of protection that they 
need.  Even with the availability of SELinux, which was introduced by 
the US NSA nominally for support of such MLS policies (and more, e.g. 
so-called "role based access control"), the defense laboratories (at 
least LLNL) are still not using any such "mandatory" access control mechanisms.

What a mess this is.  Perhaps now others can see why I was so sad 
hearing the discussion evolve on this thread.  I really feel sorry 
for those people who find themselves working on trying to build MLS 
systems.  Mostly because I fear they may find themselves working very 
hard (spending a lot of taxpayers money - who else would pay for such 
work?) trying to enforce these nonsensical policies and end up 
hurting the very security they are trying to help.

I really believe the answer, even from the military/defense 
perspective, is "need to know" (as they call it) or as we like to 
refer to it on this list, POLA.  I see the effort to enforce an MLS 
policy (so one can give out access "without worry") in some ways as 
trying to get something for nothing.  It's doomed to failure in my 
opinion.  You really do have to worry, at least once when interfaces 
are set up.  Do the worry, limit access to POLA, and you've done the 
best you can do for security and integrity.

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