[cap-talk] Nickel review of Horton (was: Re: Lazy manager scenario.)

[Jed Donnelley]

On 2/6/2008 12:27 PM, William Pearson wrote:
> This can be assumed to be the scenario of all discussions about the
> adaptive system I am working on.
> 
> A manager has a set of people that he is trying to evaluate the
> usefulness of. He assigns in some fashion a subset of the people to do
> some work. He provides bonuses on a competitive basis, that is there
> is a finite pot divided between the workers. He also isn't
> particularly attentive and can't tell when work is being sabotaged,
> all he looks at is the bottom line of the business, and provides
> bonuses based on that. The only thing he is good at is enforcing the
> security arrangements he decides and other people ask of him.
> 
> Eve and Bob happen to be assigned for the first time period, he grants
> them each different capabilities to allow them to work (telephone
> numbers, access to computers, filing cabinets and the ability to hire
> other people and give them a share of the bonus). They grant each
> other some sub set of their capabilities. Then the manager decides he
> wants to see how well Alice and Bob work together, so invalidates all
> of Eve's capabilities and Bob would probably want to invalidate all of
> Eve's capabilities to Bobs resources as well. This would be done to
> prevent Eve from potentially being malicious using the capabilities
> she had to sabotage the work of Alice and Bob to gain a bigger share
> of the pot for herself.
> 
> This is rough outline of all that is important from a security point of view.

In that case for me (others may question my objectivity on this
matter) it seems like a perfect application for Horton on
object capabilities.  As you will see if you read about Horton,
the basic idea is that capabilities are labeled as to who
(e.g. your Eve and Bob above) is responsible for them.
Whenever a capability is delegated, if it goes through
a Horton tunnel (which of course can be forced or not by
confinement - making the only available communication
paths between people such tunnels) the capability gets
relabeled as having been delegated from the sender
(the sending ID, not a process ID or anything like
a "from" address - Horton doesn't go down to that level)
to the receiver.  This mechanism allows anybody who
has access to the logging records (which can be generated
inside the Horton tunnels - even when invocations happen)
to determine who was responsible for what, including:

Who delegated what to who and when, and
Who did what with what capability and when

including the whole delegation path of the
capabilities in each case.

Example records would include:

Eve delegated this capability that had
been delegated from Zelda to Eve, to Bob
at this time.

Bob invoked (did "this" to) this capability
that had been delegated from Zelda to Eve
to Bob at this time.

If that sort of information is what you are
looking for, then Horton is a possible approach.

I was working on this "Nickel review of Horton"
for something else, but it seems appropriate here:


Nickel review of Horton:

http://www.erights.org/elib/capability/horton/
(temporarily at:
https://cypherpunks.to/erights/elib/capability/horton/
Hmmm.  I notice this "mirror" isn't up-to-date).

Horton is based on the notion of an identity,
a "who".  You can think of this as a person,
but of course it could be used for other things.
Internally to the Horton reference implementations
these identities show up as "sealer/unsealer"
capability pairs.  You can think of these as
public/private key pairs but without the cryptographic
concerns.  These identities come with all the
usual issues (e.g. introduction) of public/private
key pairs, but they suffice to serve for "identities".

The essential problem that Horton faces is this:

Alice has some authority via a capability "AuthCap".
Alice would like some help from Bob in doing something.
To get this help from Bob Alice will need to delegate
to Bob the authority that she has in the capability
"AuthCap".  However, in the true spirit of POLA, Alice
wants to make it clear that any actions that Bob
carries out with the delegated capability were
carried out by Bob, not Alice, and are Bob's
responsibility - though of course as delegated
from Alice.

For Bob's part, he has his own motivations, but
he's willing to make use of such a delegated
capability and have it noted that the actions
are his via a capability delegated from Alice.
Bob might prefer that Alice just trust him
with AuthCap directly, but if this is the way
it has to be, then so be it.  He is willing
to have the buck stop with him regarding
responsibility for actions on the capability.
Alice's responsibility stops with the delegation.

Horton solves this problem with the Horton
"tunnel" - e.g. see pages 2,3,4 of:

http://www.erights.org/elib/capability/horton/horton-talk.pdf
(no mirror I believe at present)

The idea is that through some initialization
that isn't discussed, an agent of Alice has a
capability to a Horton tunnel to an agent of Bob.
If Alice sends a message into the tunnel, Bob's
agent will receive it.  The "magic" of the
Horton tunnel is that it is responsibility
transforming.  That is, any capabilities sent
into Alice's side of the tunnel in a message
will emerge with the text of the message on
the Bob side, for Bob's agent, but with
all the capabilities having been relabeled
(by Horton) as having been delegated from
Alice to Bob.  This can be done with mutual
suspicion between Alice and Bob.  Alice only
trusts Bob to operate on the capability
she delegates to Bob (not her own), and
Bob of course doesn't trust Alice to operate
on his delegated copy of the capability.

The delegation goes through Horton, and
any invocations of the capabilities go
through Horton (as with a membrane).
This is how Horton provides a Policy
Decision Point for delegations and invocations.
Horton can log and/or block any delegations
(through Horton - even Horton capabilities
can be sent through non-Horton capability
channels if available) and any invocations
of these capabilities.  This ability allows
a Horton mechanism to server either for
Voluntary Oblivious Compliance (where
Alice could delegate to Bob outside Horton,
but she wishes to follow policy and
correctly track responsibility, so she
uses Horton) or for Mandatory Access
Control (where there are no paths from
Alice to Bob except through Horton).

Authority granted by capabilities through
Horton can generally be managed on an
identity basis, much like with ACLs.
E.g. somebody could decide that Alice
is no longer trusted with a type of
access.  At that point the Horton PDP
could be informed to block any such
access for any capability that includes
Alice in the delegation chain.

FYI.

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