[cap-talk] Re: Capabilities vs. Classifications

[Jed at Webstart]

At 03:37 PM 12/22/2005, Anthony Hannan wrote:
>...
>>I wonder if perhaps you intended to bring up this necessarily 
>>controversial thread on the e-lang list?
>
>Most of my experience with capabilities is through the E language, 
>but I posted my question here because of the broader audience.

Well, then I guess your getting what you were looking for.

>I apologize if my communication was poor sometimes. I appreciate 
>everyone responses.

Good.

Let me respond to:

At 12:42 PM 12/22/2005, David Wagner wrote:
>...
>Note that the TCB (e.g., the trusted OS and windowing system) are in
>some sense exempt from the rules.  They are still supposed to abide
>by the spirit of the rules, and prevent anyone else from violating the
>rules -- but there may be no separate security mechanism that enforces
>this on them.
>
>Ok, that's the optimistic view.  In practice, things get even hairier.
>
>For instance, how do we implement IPC?  Suppose unclassified process U
>wants to send a message to classified process C.  The message itself
>isn't a problem -- it doesn't violate the rules -- but ACKs are very
>problematic, because they would flow from high to low.  If we allowed
>ACKs, that would open up a covert channel C could use to leak data to U.
>So we can't allow ACKs.  How do we do reliable communications?  There are
>various solutions.  Some involve having a message queue...

partially because I believe that Rob Meijer is directly facing a much more
serious problem lurking just below the above.

The problem above goes much beyond ACKs.  Whenever there is any
sort of meaningful IPC there needs to be a request/reply model.
Even if one can construct an out of band ACK mechanism (like it
seems to me Rob M is doing), in general real content needs to be
replied.  It isn't enough to just know that you got my message, I
need to know, for example, was there an error in my request?,
did the function work and if not what sort of error was there?, etc.

OK, you might struggle to work past the above, but consider the general
case of an object server, e.g. consider the case of a file server, in a
multilevel security environment.  This file server is managing disks on
behalf of users and their actors (processes) at multiple clearances.
One might argue that you need distinct file servers for each level.
In that case you have the trivially partitioned system with all it's costs.
If you have a single file server, how does it work?  If some of the files
it supports are at a high level (e.g. top secret) and some of the user
process requests that it supports are at a low level (e.g. unclassified),
it finds itself right in the middle of a communication path where it needs
to be able to handle communication at a number of levels and thus
needs the ability to violate the ss and * properties.

It's often recognized that for MLS systems the kernel/TCB of the
system needs to be able to violate the ss and * properties.  The
trouble is that in a modular communication system (e.g. where
much of the value of capability systems comes from) any process/
actor/active object in the system can be considered part of a
TCB relative to some other parts.  Any of them may be called upon
to violate the "mandatory" ss or * properties in order to provide a
needed service for other components in the system.

I know (from experience) that one can construct a system that
supports multi-level security, but I don't believe it can be done in
such a way as to allow modular construction with POLA access
controls and with mandatory enforcement in all parts of the system
for the ss and * properties (more on this below when I describe our
NLTSS system):

At 10:41 PM 12/21/2005, Rob J Meijer wrote:
>...
>In many cases some key levels of clasification/clearance
>correspond to a change in the abstraction level to what
>confinement between the levels is implemented (physical
>separated (no networking),seperated hosts (firewalls),
>seperated processes (sandboxes), separated sub-processes ).

I think I'd like to try to get a better understanding of what people
mean by the term "confinement".

I believe I have a pretty good understanding of the concept
and types of so-called "covert" channels for communication,
like those I listed in my last message.  I believe that in general
such channels of communication are:

1.  Difficult to eliminate or constrain,
2.  Relatively low bandwidth, and
3.  Moderately easy to detect if used significantly.

I don't know of much progress in dealing with them over
the years.

Given #1 above, I generally assume that such channels are
available and I focus my efforts on explicit or "overt" channels
of communication.

With regard to overt channels of communication I believe
capabilities provide a very natural model.  Namely in capability
systems one assumes that the only communication allowed
is through the capabilities that a subject/process has.  The
possession of a capability explicitly represents permission to
use a channel to communicate to the server of the capability.
No communication that isn't so explicitly allowed is
denied - as typical with capability systems by not even
being expressible.

>Unfortunately capability/POLA based design mostly only
>seems to exist within one single sublevel from a confinement
>modeling point of view, and I strongly feel this is a
>fundamental flaw in the way capability design is curently
>used,

I disagree with the above, at least in the sense that I believe
it depends on the capability system.  You can as easily have
a capability system that also provides for MLS security (as
indeed we did) - within the limits imposed by that model.

>as I am convinced that with some effort a simple form
>of IPC could be constructed that would allow free exchange
>of data and capabilities between objects at the same (sub)
>level, but would implicitly enforce ss-property and *-property
>for comunucation between processes at diferent sub-levels,
>than capability/POLA design would become quite a bit more
>powerfull and more importantly, could with confidence be
>used by the type of organisations mostly concerned with
>the level of security that POLA aims to acomplish.

I think I am understanding the above and I agree with it.
I even have an existence proof.  The system we developed
in the early 1980s, NLTSS, successfully used the model
above if I am understanding it.  Namely:

A.  All subjects (processes and people in that system)
had clearance labels, and

B.  All communicated data had a classification level.

Of course we had the advantage of being able to design our
whole system from scratch, including the networking protocols.
Our protocol suite (LINCS - the Livermore Integrated Network
Communication System) included a full ISO stack.  Classification
levels showed up at the network layer where packets had
classification levels and at the interface to the transport layer
where classification levels where specified for sending and returned
when receiving.

The above system worked fine.  I don't see any problem with
any such system except getting it implemented.  Of course
how to move TCP/IP to include such a notion is a formidable
challenge, but in principle it's simple.

I see the above sort of labeled data communication with
labeled subjects as orthogonal to capability mechanisms.
That is, if you don't have such a communication system
dealing explicitly with labeled data, then nothing you can
do with a capability mechanism will help.  If you do have
such a communication system, then the objects that are
manipulated with your capability system can make use
of the data labels (e.g. our file, directory, and process servers
knew about and used the data labels for their object support),
but these are really pretty minor additions on the base level
POLA (need to know) capability model.

>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 enviroment that implicitly
>adheres to the confinement properties, by putting a little effort
>in things like the IPC I proposed, and possibly these
>sub-process data flow measures proposed in this thread.

Sadly I think you're talking about a lot of effort, and likely
to no good end as I also agree with:

At 02:05 PM 12/22/2005, Stiegler, Marc D wrote:

>In fact, these systems are so difficult to use that even the military
>has essentially abandoned them...

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