[cap-talk] Confinement CC problem ??

[Jed at Webstart]

At 07:54 AM 8/8/2006, David Hopwood wrote:
>Rob wrote:
> >>>>In my proposed design the capabilities are being locked down
> >>>>to a clearance level instead, allowing processes with capabilities on
> >>>>multiple clearance levels to somewhat move between the levels during
> >>>>their lifetime. [...]
> >>
> >>http://www.xs4all.nl/~rmeijer/tsproxy/
>[...]
> > The discussion seems to have died out...
>
>I think that defining confinement in terms of clearances is fundamentally
>the wrong approach, whether or not it is possible.
>
>To the extent that any governmental, military or law enforcement organisations
>consider clearance levels and/or variants of the *-problem to be the right
>way to model their information security requirements, I believe they are
>mistaken. Developing complex extensions of capability systems to attempt to
>handle security policy in those terms would be a misdirection of resources.

While I generally agree with DavidH's statements above, I am also
sympathetic with the situation Rob is in - having the requirement for
clearances come from on high.  This is not too different from the situation
Bill Frantz and the KeyKOS group were in when they designed:

At 06:27 PM 7/20/2006, Bill Frantz wrote:
>The KeyKOS approach to MLS was to build a MLS monitor with capabilities
>as the glue.  See:
><http://www.agorics.com/Library/KeyKos/keysafe/Keysafe.html>. See also:
>Rajunas, S. A., et al., "Security in KeyKOS", Proceedings of the 1986
>IEEE Symposium on Security and Privacy, IEEE.

I consider the above approach quite a simple and effective way to achieve
the base (in more than one sense) MLS requirements.  I recommended it
(and do so again) to Rob.

Before getting into anything more complex (e.g. as:

http://www.xs4all.nl/~rmeijer/tsproxy/

certainly is), I would like to better understand the 
justification.  While it might
seem that I (others?) have infinite time to read and write on this list, any
such impression would be an illusion.  I have family responsibilities, work
responsibilities, and personal interests (one of which happens to be network
"capabilities") that take precedence over delving deeply into complex designs
of others (essentially unpaid consulting) that I don't understand the 
justifications
for.  I expect others may be in a similar situation, and so the 
discussion (that
started as an offshoot of the conspiring communicators discussion) died out.

One thing I will say about MLS (ss and *-properties) is that they seem to have
a lasting sort of appeal.  I thought (hoped?) that by now they would 
be altogether
gone.  The fact that they still persist, and in computer systems in 
organizations
like Rob's, suggests to me that there must be something of value that 
they still
yield.  I believe that value is in simplifying human systems and is 
inappropriately
applied to computer systems with the idea that all programs run as proxies
for users - essentially making "ambient authority" a necessary part 
of the equation.
Even for people I believe the MLS properties are a broken methodology (e.g. the
John Walker case I noted and many experiences with this system at Lawrence
Livermore Laboratory over some 20 years there).  However, for computer systems
it seems particularly broken to me.

Part of this brokenness comes from my belief in the "misconception" that Rob
refers to in:

http://www.xs4all.nl/~rmeijer/tsproxy/

"One widely spread misconception is that confinement mandates that 
any single active
object needs to be locked down to a single level in order to adhere 
to the ss-property."

While I concede that some minimal one-way communication can happen in 
strict MLS
systems, I ask Rob how any sort of client/server communication (a 
request and a reply)
can happen across levels in an MLS system?  I argue that a message 
sent must be viewed
as a write by the sender to the receiver and as a read by the 
receiver of the sender.  In that
case it seems to me that one can only have one-way communication 
between levels,
either requests or replies, but not both.  How useful a situation is that?

The approach that Bill Frantz described (URL above) is one where the 
MLS monitor
explicitly resides outside the MLS scheme itself.  It can send and 
receive messages
between processes at different levels.  Also the base level system 
services (e.g.
the file server) fall outside the scheme - indeed they aren't even 
aware of it.  The
monitor provides the only communication between the levels - for objects - and
it simply restricts access to one way in the correct direction for the objects
communicated.  I can see how an approach like that makes some sense.  It
doesn't, however, provide any means for general process to process 
communication
between the levels.  No extended service or any general service can act as a
server for multiple levels lest it be a possible conduit for 
violations of the ss and *
properties.  (Please correct me if I go astray Bill F.)

NLTSS used a different approach where some processes (servers explicitly
authorized) were allowed to declassify information by labeling it.  As with
the KeyKOS MLS monitor design, most servers on NLTSS spanned levels.
They enforced the MLS policies internally by knowing the levels of all the
communication involved.

I believe that in any MLS system you have to come to grips with the basic
problem that general client/server communication across levels violates
the ss and * properties - in one direction or the other.  Rob argues that his
scheme where one "taints" an active object up as necessary to comply
with the * property (by allowing an otherwise low active object to receive
a high message, by changing the level of the active object to high on the
fly) and then somehow throws away it's state memory (effectively reinitializing
it) if it needs to be at a lower level (e.g. to do what would 
otherwise be a send
down - not allowed by the * property).  Of course throwing away state is
not something that many processes take kindly to.  Consider a simple
set of exchanges like this:

high active object --- request ---> server (taint the server high)
server (tainted high) --- reply ---> high active object
   <so far so good>
low active object --- request --->  server (still tainted high)
   <still, OK, but now you see the problem:>

server (tainted high) --- reply ---> low active object

We can't allow that last operation.  So, what to do?  At that point
do you reinitialize the server?  That would destroy all the state needed
for it's reply.  If not that, do you reinitialize such servers after each
request?  That amounts to having separate servers for each level.

I believe such schemes to be unworkable.  Of course in so saying I've
allowed myself to be drawn back into the discussion.  I'll go back to
resisting being drawn in to protect my time.

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