[cap-talk] Boebert's quote, Beobert attack on DVH, conspiring communicators

[Jed at Webstart]

At 03:26 PM 7/20/2006, Karp, Alan H wrote:
>Jed wrote:
> >
> > In terms of DVH, consider:
> >
> > "low_object" is a c-list (later called a directory I believe, but 
> no matter.
> > It's an object that can store capabilities.  It has insert or 
> write and fetch
> > operations).  A RW_low_object capability allows both insert/write and fetch
> > operations to the c-list.  In Dennis and VanHorn as in any capability as
> > descriptor system (e.g. KeyKos, EROS, RATS, E, etc.) one can 
> store capabilities
> > in some such c-list or directory object.
>
>My understanding of c-list systems is somewhat different.  At least the
>one I built worked differently.  As I understand it, the c-list is a
>data structure held by the kernel on behalf of a process.  Capabilities
>can't be forged because the process has no way of saying to the kernel
>"Here is a capability.  Insert it into my c-list."  If the c-list lived
>in the process address space, other means would be needed to prevent
>forging of capabilities.

You're model was correct.  I believe it still admits the mechanism I
described above.  A process can only access capabilities through it's
c-list.  However, a process can at some point have two capabilities in
its c-list:

1.  c-list A (to some other c-list)
2.  file B

The process can invoke the c-list capability and pass it the file B
capability as a parameter with the request to store the file B
capability into the c-list.

Some other process can have a c-list:

1.  c-list A

It can then do an invocation where it asks to fetch a
capability (e.g. by name or number) from it's #1 c-list A
resulting in a state like the above process:

1.  c-list A (to some other c-list)
2.  file B

My point is that in any capability system, including 'pure'
descriptor capability sorts of systems of the DVH type,
a means is provided for storing capabilities in some sort
of object.  One then must consider how classification and
clearance levels apply to such stored objects.

>A message carrying a capability sent to another process results in the
>capability from the c-list of the sending process being inserted into
>the c-list of the receiving process.  The sending process designates
>what capability to send by specifying an index into its c-list.  The
>recipient is told what index in its c-list contains the received
>capability.  At no time does any process outside the kernel have access
>to the capability.

All true.

>The Bell-LaPadula model is supported by not
>transferring write capabilities from Low to High or read capabilities
>from High to Low.  (We did this somewhat differently in Client Utility,
>but the effect was the same.)

And the problem is that in a 'pure' capability system the process
receiving a request (e.g. the server of the RW_low_file capability in
my example:
_____________________
Let's consider the case where we have:

low_c-list,
low_file, and
high_file

In our initial conditions we have:

1.  A capability RW_low_file stored in low_c-list, and

2.  Our Trojan Horse with capabilities to R_low_c-list and R_high_file.
(allowed by the MLS "oracle" - presumably any MLS policy)

The Trojan Horse then simply:

A.  Fetches RW_low_file from it's R_low_c-list,

B.  Reads data from R_high_file, and

C.  Writes data to RW_low_file

thereby violating the so-called star property (write down).
________________________

) has no way to determine whether the request came from High or Low.  All
it has is the capability which says RW_low_file - so it honors the request.

I argue that even if you try something like Rob Meijer is trying (though I
admit that I still don't understand it fully) or like they did in the 
Capability
Myths Demolished paper (Figure 10) you either end up blocking
communication between the levels or violating the MLS properties.

>Perhaps Boebert would call this a modified capability system.  However,
>I don't believe that's what he's describing.  He's quite explicit that
>Low writes some data that High reads and can use as a capability.  The
>key sentence is "The program places RW_low_object in low_object."

There is nothing in that sentence to suggest that such placement was
as data.  In fact I expect that wasn't Boebert's intent.  I'm not sure he
was even aware of capability as data systems.  His explicit reference
was to DVH which of course is a capabilities as descriptor system.
It might be interesting to ask him - though it doesn't really matter
what he was thinking, just that the attack applies as well to capability
as descriptor systems.

Placing "RW_low_object in low_object." can be done just as well
in a descriptor system (e.g. as I described above) as in a capabilities
as data system.

>In a
>c-list system, the Low process only gets an index into its c-list for
>RW_low_object.  Hence, all it can put into low_object is that index.
>That index is useless to High.

We disagree on that point.  In a c-list system (e.g. like RATS, the
system that Charlie Landau programmed and was derived from DVH)
a process can store a capability from one of it's c-list indices into
a directory (e.g. a capability to another c-list) at another of it's
c-list indices.  Another process with the same c-list capability can
then fetch (read) the stored capability.  This ability to store capabilities
is absolutely fundamental to any capability system, so I'm a bit puzzled
that this much is in question.

You could certainly argue that MLS policies could be placed on and
enforced for any such storage and fetching.  Any such policies would
constitute a new proposal.  I think what Boebert did was to suggest
what to him seemed reasonable policies (analogous to those for data)
for such storing and fetching of capabilities (no store down, no fetch up).

I believe he also suggested that no such policies are possible that
would both meet the MLS criteria and still allow for communication
between the levels.  When he says,

"the right to exercise access carries with it the right to
propagate that access"

I take him to mean "propagate that access" in the broadest possible
sense.  I think he only considers it as far as sending a capability in a
message (which is why he is criticizing capability systems), but I
consider it in the broader context of the conspiring communicators.
In that broader context it doesn't matter whether capabilities are used
to convey a permission or not, it can still be proxied if communication
is possible.  If communication is possible then the MLS criteria can
be violated - whether with capabilities or not.

>...Boebert's argument.  He is clearly
>talking about copying data from a c-list to some data structure that can
>be read from another process and later inserted into that process's
>c-list.

About that we disagree.  There is no "other data structure" required.
He is using object in a generic sense.  The object can be a c-list
or any other means to store capabilities.

However, what difference does it make?  Suppose I rewrite the
Boebert article and I use a c-list to store the RW_low_object.
The attack works just as he wrote it.  Why get hung up on
semantics?  The argument is still valid as he wrote it I believe.

I believe the argument set up in Capability Myths paper sets
up a scheme in which, as they say, "Since no capability-carrying
capabilities cross between levels, no capabilities can cross between
levels."  That's fine in so far as it goes, but to insure the MLS
separation you can't allow communication between the levels,
lest you be subject to cooperating conspirators.  This is as true
with capabilities as data as it is with capabilities as descriptors.

--Jed http://www.webstart.com/jed/ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20060720/a4379a69/attachment-0001.html