[cap-talk] Capabilities vs. Classifications - MLS systems?
Jed at Webstart
donnelley1 at webstart.com
Wed Jan 4 20:53:08 EST 2006
While I made a couple of early comments on this "Capabilities vs.
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
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
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
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
2. If there can be such communication, then what's to stop a secret
from sending secret (classification) data to an unclassified
I know how we dealt with this situation in the MLS system that we
labeled all processes and IPC. We allowed explicit
declassification. That is, a secret
process could send unclassified data with an explicit label and
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
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
Doing so has been wise in my opinion as I believe doing so improves
The first thing I do when I get an SELinux system is to turn off the
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
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.
More information about the cap-talk