[cap-talk] Bill Frantz HP challenge (was: Re: [Confused deputies in hybrid systems (was: Loss of control))

[Jed Donnelley]

On 2/4/2008 4:51 PM, Bill Frantz wrote:
> This thread is generating more confusion than light in my mind.  So,
> let me go back to a simple example, based in Alan's example of the
> HP financials leaking early.
> 
> Assume the HP financial data is kept on an internal web server and
> accessed through a web interface with a YURL.  (In the real
> situation, it was kept in a spread sheet and passed around as an
> email attachment.  Thus it easily went outside HP.)  The security
> policy says, "No access to this data by non-authorized people or
> from outside HP."  The authorized people are given the YURL, and the
> firewall keeps people from accessing the server when they are
> outside.

Let me ask a couple of questions about the ground rules.

Where does the no access "from outside HP" requirement come
from?  Isn't this really an implementation issue?  That is,
isn't the real concern about unauthorized access and the policy
about no access "from outside HP" a means to try to keep
sufficient control to deal with the inadequacy of existing
means to control "No access to this data by non-authorized
people"?

For that matter, what does it mean no access "outside HP"?
Does that mean no access from outside the HP internal
firewall?  As you note, there are various means to
make requests come from inside the firewall even though
the request originates from anywhere on earth.

That said, let me address:

> If we wanted to enforce this policy without using anything like the
> firewall, just using capabilities, what would we do?

First I should note that what you've started as an implementation
(pass around YURLs) is already fraught with problems.  How do I
know if I can re delegate a YURL that I have?  Consult a list?
Where is the VOC policy support?

I'm sure people are going to think I have Horton on the
brain when I propose a Horton based solution, and they
would be right.  For me Horton puts exactly what is needed,
namely knowledge of "who" is responsible for which actions,
into capability systems.

So the basis of the solution is that people communicate
to other people (programs run by other people, people
or programs outside HP, etc.) through Horton tunnels.
We have to label the data accessed by the YURL as
something that can be associated with the authorized
people, e.g. board-only.  The people authorized are
those on the board.

Then the solution is obvious.  The Horton policy mechanism
(much like the MLS proposal I described:

http://www.eros-os.org/pipermail/cap-talk/2008-February/009758.html

) blocks access by anybody not on the "board" list
(authorized) to the data labeled as "board only".
Delegations can of course still happen, but they must
be through Horton tunnels.  If I want to send an email
to a colleague with this YURL I have to do it through
a Horton tunnel.  The capability she receives isn't
the one that I sent.  It has been relabeled as having
been delegated to her (or her outside HP, see below).

> We need to
> construct some structure of capabilities to define what is outside
> and what is inside.

I don't see the need for this as noted, but by similar means
you could re label any capabilities communicated outside
HP through a Horton tunnel as "non-HP" - e.g.
"Alan Karp outside HP".  This might be a little confusing
if capabilities were to get mixed, but it could work.

> I invite people to come up with policy implementation techniques.
> 
> General ground rules:
> 
> * We want to be able to support generally used policies, even if
> they don't provide complete security.  (Note the "lose your job"
> step above.)  We are trying to show that capabilities can support
> common policies, and "no access from outside" is a common policy.
> 
> * We want to do this in a "data as capabilities" environment. 
> (YURLs)

I don't believe my proposed solution has problems with
any of the above.

I also note that it injects the sort of control that
I believe people are looking for in capability systems.
Even delegation of the access to the sensitive information
can be logged and audited.  If there is an unauthorized
access, we can trace it to a responsible person.  We have
complete flexibility to take people off the access "list"
(say people are no longer authorized) or put them back
on.  This is a "pure capability" approach.  The needed
management dealing with people is done in the back end.
Capability communication is used for delegation.

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