[cap-talk] Trust and the Orange Book

[Jed Donnelley]

On 1/15/2008 2:11 PM, Karp, Alan H wrote:
> Jed wrote:
>> I believe it really came (comes) back to those "loose
>> capabilities" fear, the fear of delegation as in:
>>
> It took me a long time to understand what the ACL folks
> mean when they talk about "losing control".  I think I do now.
> 
> Take a perfectly trustworthy individual, Alice, running a
> perfectly trustworthy program, A, that can interact with
> a non-trustworthy program, B, run by an non-trustworthy
> person, Bob.  Alice will not direct A to delegate certain
> authorities to B if she knows Bob is not to be trusted
> with them.  That may not be an easy fact for Alice to
> determine.  The ACL approach requires Alice to ask an
> administrator, who presumably has information Alice does not,
> who would deny access if allowing it would violate policy.
> In this case, it is better for Alice's request to fail than
> for the access to be allowed.
> 
> The problem with this approach, as we all know, is that it
> makes all delegation difficult, even for Alice to delegate
> part of her authority to A.  The result is that A runs with
> all of Alice's authority, and Alice can only delegate by
> sharing her credentials with others, which all too frequently
> includes Bob.
> 
> A system that enforces Voluntary Oblivious Compliance allows
> Alice to freely delegate authorities with the assurance that
> policy will not be violated.  Designing and implementing such
> a system is left as an exercise for the reader.

I believe this is exactly what Horton can do:

http://www.erights.org/elib/capability/horton/

Give Alice the ability to delegate to whoever or whatever
she needs to be able to delegate to through a Horton tunnel.
She can delegate exactly what she needs to delegate and
only to whom she needs to delegate it (remember, Alice is
trusted) through the Horton labeling/policy (VOC) mechanism.
That mechanism can provide the policy support from on high
that will block inappropriate delegations and even revoke
delegations after the fact if circumstances change.  Of
course it can also provide the needed auditing and information
display about "who" (identity) has access to what.

One note, however.  I don't believe Alice should have to
"ask" an administrator.  That would effectively block
delegations.  I would hope that the policies that would
block/revoke inappropriate delegations (e.g. Joe is no longer
on the executive board, that system is no longer trusted
with company sensitive information, etc.) would be
supported administratively in bulk.  Within those
constraints Alice should be able to delegate as per
her POLA ('need to know') needs.

I think you said the key thing, Alan, when you said that
Alice is trustworthy (she has broad permissions for
access and communication, so she better be) and Alice's
program A is also trusted (same argument).  At that
point we can trust Alice to use available and appropriate
Voluntary Oblivious Compliance modules such as those that
are available through the Horton tunnels which provide the
needed policy checks that can be administered centrally.

Of course it would even be easy to support multi-level
security as desired by the defense community within
such a system.  Information resource are labeled
with classifications and information consumers (IDs,
e.g. people and computer systems) are labeled with
clearances.  The centralized checks are quite simple.
The whole thing is based, however, on the assumption that
the trusted components are, well, trusted.  If Alice
has secret information and the ability to communicate
with people or programs only cleared to unclassified,
(unconfined as Toby would say) and she chooses to do
so without going through the appropriate voluntary
oblivious compliance check (e.g. through a Horton
tunnel) - well, that's it then.

If we want to make use of a person or program that
we don't fully trust, we have to confine them/it.
I believe we can even give them/it the opportunity
to communicate through Horton tunnels to limited
destinations that won't cause problems, but we can't
give them/it the opportunity to communicate
"unconfined".  If we give them/it both access to
sensitive resources and the opportunity for
unconfined communication, then the game's over.
I believe this is the essence of the issue that
Toby and I are discussing.

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.

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