[cap-talk] Communicating conspirators, MLS, and the Boebert attack

[Jed at Webstart]

At 08:45 AM 7/19/2006, Karp, Alan H wrote:
>Jed wrote:
> >
> > So far I believe the architecture described above (without
> > yet discussing
> > capabilities or even generally how access control is accomplished) is
> > exactly like the architecture described by Boebert:
> >
> > http://www.erights.org/elib/capability/duals/boebert.html
> >
>which led me to re-read the paper.

That's a lovely thing about the Boebert paper in my opinion, the
simplicity of it's discussion.  He really did the community a service
with that simple paper.  I find it sad that we really haven't come to
terms with it's implications yet.

I think it might be illustrative to describe how the Boebert attack
would play out in the NLTSS system.  NLTSS has all the attributes
Boebert requires.  It's a capability system (network capability
system, simple capabilities as data - password capabilities) and
it supports multi level security in the sense of the Bell and LaPadula
model.  Subjects (processes) have clearances, and objects
(think files) have classifications.  Of course it was a real system
with no "oracle".  Policies were enforced by code in the system.

In one sense, however, NLTSS may not qualify as "pure" capability by
his description.  That is, in NLTSS it's data that carries a classification.
It carries such a classification in any message exchange.  If
a process with clearance secret tries to send a secret message to
a process with clearance unclassified (e.g. across the network),
the message data will be labeled as secret and when it hits the
unclassified process it won't be delivered (classification error).

Please bear with me as I think this analysis may shed some light
on the Boebert attack... dealing as it does with the issue of
authorized (or not) declassification.

Now consider Boebert's Trojan Horse, as he says:

"The Trojan Horse program then uses R_low_object to fetch RW_low_object
from low_object.  A malicious program now simultaneously possesses R_high_
object and RW_low_object, and is therefore able to transfer information in
violation of the *_Property."

In NLTSS such a Trojan Horse could indeed use such an R_low_object
(e.g. an unclassified directory containing a RW capability to an
unclassified file) to fetch the RW_low_object (the RW file).  This Trojan
horse has clearance high, so it can also read from the R_high_object
(e.g. a file classified secret).  However, when the Trojan horse tries
to use the RW_low_object to write data (any data, but in particular
the secret data read from R_high_object), it will be blocked as it is
trying to write secret data to an unclassified file.  The file server (in
NLTSS) will recognize this because the message coming from the
Trojan horse will be labeled as secret and the file is labeled as
unclassified.  The write request is blocked.

What's going on here?  I believe the business of the object references
(and in some sense their capabilities) amount to a red herring.  Let's
just suppose we have the following setup:

Unclassified process <->  Trojan Horse secret process <-> Secret process

where by <-> I mean bidirectional communication exists.  In this scenario
it seems clear that declassification of information can happen.  If the Trojan
horse is trusted to do such declassification and it does so improperly
(John Walker), then that inappropriate declassification will happen.
There don't need to be any "objects" like files involved.

Perhaps one could argue that still there are capabilities needed (unlike
in NLTSS - where perhaps the pureness of it's capability mechanism could
be questioned - as I have in other messages) to allow the above sorts of
communication.  The Trojan Horse needs capabilities to communicate
with both the Secret and with the Unclassified processes.

This I believe is where push comes to shove with regard to MLS.  Namely,
do you allow ANY communication between levels in such a system?
As soon as you allow a simple request/reply exchange between processes
with difference clearance levels, then you admit discretionary transfer of
information from HIGH to LOW - regardless of what capabilities are involved.
Either the request or the reply must go from HIGH to LOW and therefore
can constitute a declassification.  Put a Trojan Horse into that situation
and you can violate the principle on which the simple security and the star
properties are based - whether or not there are suitable objects involved.

>The incompleteness of Boebert's
>analysis is made clear in the first sentence of his conclusions.
>
>'The attack is made possible by an inherent attribute of pure capability
>systems:  the right to exercise access carries with it the right to
>propagate that access.'
>
>That is not the reason the attack is possible.  DVH has this property
>but is not subject to Boebert's attack, even though that's the paper
>Boebert cites.

Regarding the above and Mark Miller's comment:

>At 10:07 AM 7/19/2006, Mark Miller wrote:
>
>Alan & I just talked about it, but for the record...
>
>DVH does *not* have this property. In DVH, if Alice has access to
>Carol, Alice can only propagate this right to Bob if Alice also has
>access to Bob. While I agree with Alan that this propagation issue
>doesn't account for Boebert's error, it does account for the error
>repeatedly read in to Boebert's paper - that capabilities cannot do
>confinement.

I agree with Mark on the above point.  However, I don't think it
provides any help in the defense of capability systems from
Boebert's attack.

Boebert says, "The attack is made possible by an inherent attribute
of pure capability systems:  the right to exercise access carries with
it the right to propagate that access."

This is where I believe he gets things wrong.  As we have discussed
with the communicating conspirators problem, it isn't the property
of pure capability system of allowing the propagation of permissions
that gives rise to this problem.  It's the mere ability to communicate
that gives rise to the ability to propagate access - even by proxy
if necessary.

For the case of the concern with MLS (dealing with data at various
classification levels) the situation is even more stark.  Put any
subject (process, active object) in the position of being able to
communicate data between other processes at distinct levels
and you create the possibility of violating the MLS criteria.
This situation has nothing to do with the communication of
capabilities per se, it related to the opportunity to communicate
data.

>Uncontrolled delegation is clearly not the issue.  The attack is
>possible if the capability is data.  It's clear that's what Boebert
>assumes based on his statement in the first section of the paper.
>
>'In order for a program to exercise access to a storage object, the
>program must possess a capability granting the desired access.
>"Possess" in this sense means that the program has access to the storage
>object which contains the capability.'
>That assumption means the capability is data in "an unmodified
>capability machine", one lacking special hardware to distinguish
>capabilities from data.

I don't believe it does.  All it means is that it can fetch the 
capability through
some capability that it has.  I know certainly in the RATS systems
(that was based quite closely on DVH) the low_object could easily
have been an unclassified directory (there were no classifications in
DVH or RATS, but I think you have to imagine how they might work
for such a discussion) and the RW_low_object and R_high_object
both files to unclassified and secret data respectively.

>That is not the case in DVH or any other c-list
>like system.  "Possess" in these systems means that the process may
>invoke the capability, but the process doesn't have access to the bits
>of the capability.  Clearly, DVH and other systems that distinguish
>capabilities from data fall outside of Boebert's analysis.

I disagree.  The Boebert analysis doesn't say anything about
accessing bits of a capability.  What doesn't exist in DVH is any notion
of classification and clearance.  One has to imagine how they would
be put in, as Boebert does with his imagination and oracle and
as Miller, Yee, and Shapiro do in their Capability Myths Demolished
paper.  Since they do so differently (as does NLTSS) it isn't surprising
that they arrive at systems (or imagined systems) with different
properties.

Miller, Yee, and Shapiro (Capability Myths Demolished) argue that
if one constructs a system in which, "no capability-carrying capabilities
cross between levels" then "no capabilities can cross between levels."
Of course this is true, but it in no sense saves any such system
from classification violations.  In a situation like I describe above:

Unclassified process <->  Trojan Horse secret process <-> Secret process

just because the Unclassified process doesn't have direct read
access to a secret file, doesn't mean that the classification system
isn't just as much violated if a process cleared to the secret level
reads the data, sends it to the Trojan Horse (whatever it's classification),
which then sends it to the Unclassified process which then writes it
into the unclassified file (you can eliminate the Secret process if you
like and just have the Trojan Horse run cleared to secret, read the
secret data directly, and send it to the unclassified process for
writing to the unclassified file).

>Boebert's analysis is correct for systems in which capabilities are
>data.  It's a shame that he attributes the cause of the failure to be
>delegation.

I believe the Boebert attack works in any system where you have
classification levels and you allow communication between subjects
with different clearances.

The prevailing view on this list seems to be that since capabilities
can be used for confinement (I agree regarding explicit confinement,
though we all know about the issues of wall banging) then they can
be used to limit violations of the simple security and the star
properties - without considering a specific model for doing so.
I argue that there is no such model that allows any communication
between processes with different clearances.  Boebert anticipates
this when he says, "The attack can be stopped only if both reading
and writing are restricted to cases where clearance equals classification,
which is of course the trivial case of no flow whatsoever."

I believe the Boebert attack can be stopped only if communication is restricted
to being between processes with clearances at the same level, which
is a partitioned system.

I think the NLTSS system can be seen as something of a compromise
in this space.  It allowed communication between processes with
different clearances, but only by processes authorized to act as
declassifiers (communication level lower than clearance).  Servers
(acting across levels) necessarily had this property.  Most processes
did not.  User processes were not allowed to communicate between
levels, and so weren't subject to the sort of threat Boebert considers
with his Trojan Horse.

I think it appropriate that we're discussing the Beobert attack in the
context of communicating conspirators.

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