[cap-talk] Capabilities vs. Classifications - MLS systems?

Jed at Webstart donnelley1 at webstart.com
Wed Jan 4 20:53:08 EST 2006


All,

While I made a couple of early comments on this "Capabilities vs. 
Classifications" thread,
generally I've found it very depressing.  I've been following the 
thread but not commenting
since those first couple of messages.  In this message I'm going to 
try to stand back
from the details somewhat and see if I can describe what bothers me 
so much about
this thread.

I think the discomfort I feel goes well beyond what Rob Meijer noted 
when he said:

At 10:41 PM 12/21/2005, Rob J Meijer wrote:
>It is sad that the subject of this thread is capabilities 'vs'
>clasifications, as I believe strongly that capabilities could
>with a little effort be used in an environment that implicitly
>adheres to the confinement properties, by puting a little effort
>in things like the IPC I proposed, and possibly these
>sub-process data flow measures proposed in this thread.

In fact some of what distresses me about the thread shows up in the
above.  Namely when Rob says "capabilities could with a little effort be
used in an environment that implicitly adheres to the confinement
properties".

he seems to be implicitly arguing that capability mechanisms don't
support confinement, or at least don't adhere to "the" confinement
properties (presumably the * and ss properties).

In my view capabilities explicitly enforce all the confinement that is
possible.  Namely, capabilities only allow only communication to servers
for permissions that are explicitly granted by the capabilities.  How
can there be any more confinement?  Why should there be any less?

So what about:

At 08:51 AM 12/21/2005, Anthony Hannan wrote:
>...With classifications you do not have to trust the subjects 
>(functions) you give your objects to.

Huh?  Isn't that exactly the idea?  Namely you give exactly the POLA 
permissions to your subjects
(function?  active objects, processes, applications, ...) that you 
need them to have to carry out the
work that you need them to perform.  When you give a subject access 
to an object it's because
you are explicitly trusting it with access to the object.  You seem 
to be describing a situation in
which you try to grant a permission to a subject, but somehow you are 
blocked from doing so
by a wider policy enforcement.

So what about this?:

>You can give your classified objects out without worrying,
>knowing that only authorized subjects will be able to invoke them 
>(assuming you trust the kernel/middleware).

First let me note that I see the above as one of the fundamental 
failings of MLS.  The idea of
"without worrying".  Of course you have to worry.  That's what 'need 
to know'/POLA means.  It's the
"without worrying" that in my opinion has given rise to so many of 
the most serious security
failures such as the John Walker case: http://www.fas.org/irp/eprint/heath.pdf
('KGB officer Vitaly Yurchenko was more blunt: "Walker was the 
greatest case in KGB history.
We deciphered millions of your messages. If there had been a war, we 
would have won it.").

Still, one could argue that even if you do "worry" about need to know 
and classification
of data and subjects (MLS), it's still a good idea to have some sort 
of system check helping.
Perhaps one could even consider this an aspect of the multiple layers 
of defense strategy.

It's here that I really start getting some heart burn.  The problem I 
have shows up in any
effort to apply MLS ala the Bell-LaPadula model to a system with 
inter process communication
where processes are considered subjects and data is considered to 
have a classification.
I ask: How can there be any inter process communication between processes with
different clearances?  For example, how can a secret process 
communicate with an
unclassified process?  My concern is that if bits can flow, then why 
can't they be secret
bits in violation of the * property or ss properties?

I believe the question is directly applicable to the situation under 
discussion, "don't have
to trust the subjects you give your objects to", in that:

1.  Unless there can be such communication the question of 'giving' 
objects to a process
at the wrong level for any object can't arise.  The levels are 
effectively partitioned (the
trivial case).

2.  If there can be such communication, then what's to stop a secret 
(clearance) process
from sending secret (classification) data to an unclassified 
(clearance) process?

I know how we dealt with this situation in the MLS system that we 
implemented.  We
labeled all processes and IPC.  We allowed explicit 
declassification.  That is, a secret
process could send unclassified data with an explicit label and 
thereby communicate
with an unclassified process - in violation of the * property, though 
explicit.  Doing so
puts such restrictions into the category of "discretionary" and seems 
to contradict the
desires of the MLS folks who've been active on this list recently 
(Anthony Hannan,
Rob Meijer, Toby Murray, others?).

I'd like to ask anybody interested in MLS systems to describe what 
sort of systems
they now have.  I forget now who said this before me, but I believe 
that such MLS schemes
have pretty much been abandoned by the defense community (SELinux 
notwithstanding).
Doing so has been wise in my opinion as I believe doing so improves 
real security.
The first thing I do when I get an SELinux system is to turn off the 
SELinux restrictions.
I believe that in doing so I am improving the real security/integrity 
of the system.

When David Wagner says:

"Bell-LaPadula style MAC has been a failure, in my view.  It was
designed to prevent malicious code from leaking secrets, but it has
utterly failed at that "

I agree completely.  However when he qualifies the above with:

"-- covert channels are a fact of life, and no
one has any clue how to eliminate them without significantly curtailing
the usefulness of the system."

seeming to suggest that their only real problem is the existence of
covert channels, I argue that is much too mild a failure description.
I don't know of any actual MLS systems that have "failed" due to
exploits of covert channels.

MLS systems fail in my opinion because:

1.  They erect barriers to legitimate work at many levels/points, making them
impractical for most work, and

2.  They don't significantly help to solve the problem of protecting 
classified data,
partly as a consequence of #1.

I believe the MLS system we implemented in NLTSS was moderately successful,
but only because its mechanisms were in fact discretionary and the 
intent was to
catch inadvertent violations of the * and ss properties.  The only 
way it was able
to work was by labeling the data communicated between processes.  Attempts to
make the enforcement of such principles "mandatory" (by that I mean 
not allowing a
subject with a permission to grant effective access to that 
permission to another
process with which it can communicate) in a system with inter process
communication I believe is impossible, but misguided efforts in that direction
make real systems effectively unusable.

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



More information about the cap-talk mailing list