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

[Jed Donnelley]

At 10:16 PM 2/4/2008, Bill Frantz wrote:
>jed at nersc.gov (Jed Donnelley) on Monday, February 4, 2008 wrote:
>...
> >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).
>
>It sounds like this mechanism needs some form of confinement so the
>YURLs to through the Horton tunnel.

One extreme possibility is that all capabilities (at
least "user" capabilities) are Horton tunnels.  This is
essentially what I proposed in the MLS case.  This
extreme mechanism would certainly suffice.

>One possibility is a VOC
>system.  We do still have the problem of the authorized person who
>took his laptop home and should not be able to access the data from
>home, but hasn't even copied the YURL, much less delegated it.

Let's see, as I recall the issue is that this person should be
able to access some YURLs on the same server through the
firewall, but not these particular ones?

I think the difficulty with this situation is that the only
place there is information about where this communication is
coming from is in the firewall.  To deal with this I suggest
a forwarding service.  The main service is simply not available
for access directly from outside the firewall.  It only accepts
"outside" requests from the forwarding service.  The forwarding
service does the delegation from an inside identity to the
corresponding "outside" identity.  When this request gets
forwarded to the inside server, it has the information that
it needs to enforce it's policy (inside or outside).

A bit awkward perhaps, but it was the first thing that
occurred to me that should work.  I expect there are
other approaches for this aspect of the problem.

Doesn't that do it?

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