[cap-talk] Trust and the Orange Book (was: Re: the value of non-delegatable authority?)

Jed Donnelley jed at nersc.gov
Tue Jan 15 16:08:47 EST 2008

On 1/15/2008 8:16 AM, Karp, Alan H wrote:
> The rational for the Orange Book was, "We trust our people.
> It's the programs they run that we don't trust."

That's amusing.  If the above was the case, how did they
get it so spectacularly wrong by forcing systems meeting
the Orange Book criteria to grant programs run by users
*all* the authority of the users (ambient authority ACL-based
systems with programs running with a 'user' ID)??

With the above criteria you'd think POLA would have been
more important to "them".

I believe it really came (comes) back to those "loose
capabilities" fear, the fear of delegation as in:

"Traditional Capability-Based Systems:
An Analysis of Their Ability to Meet the Trusted
Computer Security Evaluation Criteria":


and as expressed in Toby and Duncan's recent paper:

"Non-Delegatable Authorities in Capability Systems"
By Toby Murray and Duncan Grove
(to appear in the Journal of Computer Security)


"...allows some entity A to give an unconfined entity B
authority to access some resource C, while ensuring that B
cannot pass on that exact same authority to any other entity."

that we've been discussing recently.  This is why I feel
so passionately about this issue.

To me there seems to be a fundamental dilemma for those
who may wish to, on the one hand:

1.  Achieve the values of POLA by having program modules
delegate minimum authority between themselves, as with the
amazingly successful "object oriented" paradigm, so as to
protect against possible damage by a misbehaving module

and on the other hand:

2.  Block program modules from doing any delegation
lest there be found a misbehaving module that may
inappropriately delegate an authority where it
shouldn't go.

Many people seem to think that if they could just
manage to make the controls on access "mandatory"
(imposed from the outside by an expert) as opposed
to "discretionary" (subject to manipulation from the
inside by these untrusted programs) then things would
be hunky dory.

However, they don't seem to appreciate two things:

1.  (the lesser of the two) Outside "experts" can't
possibly know enough or have adequate control (let
along be trusted with such control) to be able to
micro manage the details of effective "mandatory"
POLA interactions.  About this aspect of POLP Butler
Lampson got it right.  The needed expertise only
exists where the local knowledge is, in the running
program (much like the economic analog).

but more importantly, as we well know:

2.  Any program that can communicate bidirectionally
with another program can share any of its' authority
with that program - as MarkM so nicely described in:


This means that if you want to block delegation, you
MUST block communication.

Block communication?  Well, if you want to block
unneeded communication, that sounds like a perfect
job for POLA.  Here again capabilities do the job
perfectly.  Communication is only allowed where
access is needed to exercise a needed authority.

But we hear (e.g. P-1935 above) that capabilities
are inadequate to meet the Orange Book criteria??

Instead we end up with a situation where *every*
program we run not only has <access to all the
authority of the user>, but also has the <ability
to communicate openly on the Internet> !!??!

What is wrong with this picture?  What is right
with this picture?

Toby complains that: "none of these techniques
<POLA as with capabilities> can be applied to allow
one to distribute authority to an unconfined subject
already in existence."  The subject is unconfined?
Read "Communicating Conspirators" above.  If the
subject is unconfined, the game is already over.
Why not go back to the base assumptions and *fix the
real problem*?  Actually confine the program that
isn't trusted to do delegation??

Whew.  Sorry if I get a bit "wound up" on this topic.
It does seem of fundamental importance to me.  However,
perhaps we've reached the point where continued discussion
isn't useful?  I think at this point it's more practical
interfaces that will be useful, especially for people
without entrenched positions (the "great unwashed").

I feel most strongly that what's needed in this area is
to provide user interfaces that allow people to do object
oriented delegation for access control, e.g. along the
lines of CapDesk (drag and drop, point and click, etc.),
but for people and programs across the Internet.  At
least across the Internet we start with the right 'no
shared access' base conditions.  You can't access any
of my stuff and I can't access any of yours.  What I
believe we need are interfaces that will allow us to
delegate object references (capabilities) to others
across the Internet.

This seems simple enough - something like what Wideword


but with the links being to local resources on my
computer and on yours and on theirs rather that just
something that only one specific server provides access to.

Ha!  Have people noticed what happened to:


in the "Public Comments" section?  After the two by Toby
and Pelle it seems that area became essentially a spam
collector.  Would somebody (besides me) mind adding another
private comment (after IanGs) so that page shows as being
updated recently?  The "Public Comment" feature seems to
me of rather limited utility ;-)

Hmmm.  Interesting.  I find that if I delete a few of the
"SPAM" public comments and then refresh the page, I see
only the original text and the two comments from Toby and
Pelle.  However, if I then refresh again all the spam
comes back - except that which I deleted.  Oh well, I
must still be a hacker at heart.  Try it.  There are
plenty to delete...

I guess this facility won't be up much longer.

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

More information about the cap-talk mailing list