[cap-talk] Horton - what are applications thinking?

[Jed Donnelley]

Karp, Alan H wrote:
> Jed wrote:
>   
>> A in step (1), executes b.foo(c),
>> "thinking" it is sending the message "foo" to receiver
>> B with a reference to object C as an argument.
>>
>>     
> This statement is tied back to the earlier comparison with Polaris and
> Plash, which provide protection without changing the application.
> "Thinks" is meant to denote that an application can be written for a
> Horton-free environment and later run without modification on top of
> Horton.
While it is important that applications can run using Horton without 
change, I believe
it's also important to note that applications can be written with the 
intent to make
use of the added value (transition of responsibility) that Horton 
provides.  In that
case A is "thinking" something different while still executing the same 
invocation.
In fact A might not be inclined to do the invocation of P1, sending it 
P2 (with
the idea of communicating permission to access to C, but only by "Bob") 
if it
didn't have the assurance that P1 and P2 were Horton proxies.
> Of course, there is still the bootstrap problem of getting
> Horton under the application in the first place, but this paper only
> covers the inductive case.
>   
Agreed.  I personally don't see that bootstrapping as a difficult issue 
(having dealt
with it in a few capability based infrastructures), but we won't know 
until we get there.

I think this might be a reasonable point to introduce my slightly 
broader perspective on Horton, so here goes:
<tome - lower priority than reviewing and cleaning up the Horton paper 
for publication>
______________________
Capability systems have a significant advantage over Access Control List 
(ACL) systems (think Windows and Unix) in that they can dynamically 
assign just the permissions needed for any application (e.g. unlike 
Windows/Unix where Solitaire runs as a "user" with all privileges) - 
nothing new there.

Since this is the case, why haven't capability systems come to dominate? 
There were a number of problems pointed out with capability systems 
during the late 1980s (the days of the "Orange Book", etc.). In recent 
years I've particularly focused on criticisms like this one (discussed 
previously on cap-talk, e.g. starting:

http://www.eros-os.org/pipermail/cap-talk/2006-November/005815.html
):
V. D. Gligor, J. C. Huskamp, S. Welke, C. Linn, and W. Mayfield. 
Traditional capability-based systems: An analysis of their ability to 
meet the trusted computer security evaluation criteria. Technical 
report, National Computer Security Center, Institute for Defense 
Analysis, 1987.

These sorts of documents were very (!) critical of capability systems. 
They focused on a number of areas. One area was MLS (so-called 
"mandatory" access controls). Another was auditing/logging and general 
identity based access control.

In the years since those papers nearly all the criticisms (particularly 
the "mandatory" access control criticisms) have been answered. The one 
area that hasn't been addressed has been that of auditing/logging and 
identity based access control - which superficially seems at odds with 
capability based access control.

This Horton paper deals with this criticism by showing that capability 
systems can manage identities and responsibility (e.g. 
auditing/logging), and in fact can do so better than ACL systems (e.g. 
Windows/Unix) - mostly in that they can track responsibility for both 
authorized requests and for serving those requests (rather than just the 
requests as in ACL systems). Horton describes an implementation for the 
simplest of object systems (e.g. E, Java). It can also be done with 
encryption such as public keys, e.g. for the Internet.

This result seems somewhat counter intuitive (to me anyway). 
Capabilities generally operate on an anonymous "bearer right" basis - 
sort of like a physical key. Any domain (process, active object) that 
possesses such a key (capability) can exercise the permission and can 
also communicate it anywhere that it has permission to communicate.  The 
"conspiring communicators" 'problem' (I consider it an opportunity) is 
alive and well - capabilities or ACLs.

What we show in this paper is that a mechanism can be set up in a pure 
capability system that essentially labels capabilities with who is 
responsible for both exercising access to them and for servicing 
requests on them. This mechanism can be set up in such a way that:

1. It's invisible to the users of the capabilities. That is, the 
programs can still treat them as bearer rights and things just work.
2. Behind the scenes identities can be assigned to permissions and an 
infrastructure built so that capabilities can either:
  a. Be communicated directly (in which case they keep the 
responsibility they had in the sender), or
  b. Be communicated through a "Horton" transformation, in which case 
they will take on the responsibility of the receiver - but only after 
only the receiver (not the sender) is able to access them.

Whether such a Horton transformation is allowed or even required depends 
on the initial condition set up for sender and receiver (amplifying 
Alan's point about initial conditions) and generally on policies used in 
systems and between people.

The basic idea is to set up proxies for capabilities that remember 
identity labels for who is responsible for them. These proxies can then 
cooperate to transform capabilities as they transit from one 
responsibility to another. Horton shows how to do this without having to 
trust the sender, the receiver, or even any shared infrastructure.

How does this help address the issues standing in the way of a 
transition to ocap systems?  At a high level I believe those issues are:

1.  The user interface issues that we've discussed so often 
(initializing applications, power boxes, etc., etc.).  I believe these 
are straight forward (though a lot of work) to solve.

2.  Implementation complexity/performance issues.

3.  Legacy issues - which of course are huge.

I think it's still widely believed that #2 is a blocking situation for 
ocaps.  For most of this concern (e.g. those voiced by Lampson - ocaps 
force fine grained access control which is too complex and impossible to 
get right) I simply disagree with those who voice the issue.

If once considers #2 in the light of Horton, on the surface Horton 
appears rather complex (e.g. the proxies, sealers, etc.) and would seem 
to suggest rather high overhead.

One point that I believe mitigates against this concern is that I don't 
believe Horton transformations will be (need be) used very often.  In 
particular I only see such transformations used when permissions are 
communicated between people (of course through processes/active objects 
acting on their behalf).  Since this happens rather rarely in computer 
systems, I don't see the overhead/complexity of Horton to be a practical 
concern.

In my thinking I imagine something like the infrastructure that we had 
at LLNL through much of the 1970s and 1980s, where there was a 
centralized facility (in our case a shared directory structure) for 
sharing between people.  By adding something like Horton to such a 
mechanism, if I delegate a permission to you, the process for doing so 
insures that:

1.  The responsible party for the delegated capability (permission) is 
you, and
2.  You are assured that only you can access the newly labeled capability.

As long as everybody knows what's going on (above) then this seems quite 
a workable mechanism to me.  I know that if anything shows up in my 
"Here's your new responsibility" directory/folder, then I'm responsible 
for any requests on it and I should treat it carefully.

Generally speaking I would treat such objects with the same POLA care 
that I do for anything else, but generally I wouldn't directly 
communicate such permissions with other people (in effect letting them 
act with my identity), but would rather delegate through such a person 
to person responsibility delegation mechanism like Horton.  After all, I 
don't want to be held responsible for what that other bozo might end up 
doing with the permission.

For example, if I were to run an editor on a delegated file or charge to 
a delegated account or ...  I would generally have 'my' software invoke 
the capability that was delegated directly - e.g. vs. having it run as 
some other responsible party and then going through Horton to give it a 
copy of the permission that the person responsible for the software will 
be responsible for.  Of course Horton can also track the delegation 
chain, so it's possible to figure out how a permission came to be where 
it is (in so far as Horton was used).  Still, I wouldn't imagine using 
Horton to communicate capabilities to processes running applications 
running on my behalf.

It is for the above reasons I believe noting the distinction between 
what an application is "thinking" when invoking a Horton proxy is 
important.  Whether we have space to mention anything about this topic 
in the current paper I'm not sure, but I wanted to at least state my 
thoughts on the topic for feedback.

I hope I'm being clear on this topic as I believe clarity in this are to 
be very important to the viability of something like Horton and the 
future of capability systems.  I'm quite interested in feedback on this 
broader topic, though as a lower priority than getting the Horton paper 
reviewed and cleaned up for publication.
</tome>

--Jed
http://www.webstart.com/jed/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20070516/bc8dc059/attachment.html