[cap-talk] Trust and the Orange Book

[Jed Donnelley]

On 1/16/2008 9:18 AM, Karp, Alan H wrote:
> Jed wrote:
>> Have I missed a part of the problem or the solution?
>> While there are of course still concerns that trusted
>> people or programs won't live up to their expectation,
>> can any more be done?  If evidence is uncovered that
>> a person or program should no longer be trusted, at
>> least we can (through Horton) limit the damage.  I
>> don't see how we can do better.
>>
> Seems to work.  The key insight is that Alice's Horton
> stubs and proxies invoke a Policy Decision Point (to
> use the SOA term) to make the decision.  The question
> is how that PDP knows what to do.  Perhaps objects can
> implement a getSecurityInfo() method.

Exactly my thought.  The PDP (Ha!) knows "who" is making
the request (in the Horton sense of an identity) and it
can see the object references (capabilities) going through
which it can interrogate for any policy relevant labels
that they may have - classification, company sensitivity,
anything that any organization might consider relevant.
It has all the information that could be relevant and it
is in position to "enforce" any desired policy.  I don't
believe you can do any better.

In the situation where a subject is making a request
(whether an invocation for effect or for delegation),
the policy module can block or allow, it can log
and report.  Also, since it can label and reissue
(membrane) any capabilities that pass through it,
it can enforce it's policy retroactively - if the
environment changes.  If the requester is relatively
unconfined (able to communicate without being
forced through such a PDP), then this amounts to
Voluntary Oblivious Compliance.  If the requester
is confined and only able to communicate through
such a PDP then the policy is mandatory.

I believe that's the best that can be done,
whether for defense/military MAC or for
company proprietary or any other protection
policy, voluntary or mandatory.

In my opinion this approach achieves the best
of multiple worlds:

1.  It provides for flexible (even after the
fact) policy hooks (your PDP) that can deal with
any sort of identity/object access restrictions.

2.  It permits POLA delegation through or around
(when available, allowing for any sorts of
efficiencies possible) the PDP to provide for
"need to know" limits in accord with the best
possible discretionary access control, and,
most importantly:

3.  It's faithful to the full object capability
model that permits capabilities to flow as
parameters for invocations of existing
capabilities.  This means that it is fully
"decomposable" in the OO sense.  There is no
need to provide code to do proxying in order
to subdivide or otherwise delegate work where
appropriate and all invocations can be
optimized to minimize the number of
indirections needed.

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