[cap-talk] Announcing "Analysing Object-Capability Security" Paper and Authodox v. 0.2.0

Neal H. Walfield neal at walfield.org
Fri May 30 12:22:35 CDT 2008


At Fri, 30 May 2008 12:27:59 -0400,
Jonathan S. Shapiro wrote:
> On Fri, 2008-05-30 at 16:53 +0100, Toby Murray wrote:
>   1. The opaqueness boundary at the OS/application layer is a problem,
>      because it forces the OS to make mostly static, conservative
>      assumptions about program behavior. For most programs this is fine,
>      but there are two classes of important programs for which it is
>      a problem:
> 
>      A  Trusted programs -- though the question here is "by whom". The
>         underlying problem in OS-based capability systems is that the
>         primitive capability weakening operations don't have enough
>         information to weaken entry capabilities to trusted programs
>         sensibly.
> 
>      B  Memoryless programs. There is a class of programs that require
>         state for realistic implementations, but none of that state
>         remains live when the program returns from a given request.
>         The OS cannot see this. Functional programming doesn't help,
>         because the compiled realization of a functional program is
>         generally stateful.

I wonder if something akin to what HiStar [1] does wouldn't be a step
in this direction?  In HiStar, data is tagged with labels.  A label's
owner may untaint data with a particular label thereby allowing it to
flow from more to less tainted objects in a given category.  The
result is that one can write a server that handles multiple clients'
data but, which is unable to leak data from one client to another.

Neal



[1] Making Information Flow Explicit in HiStar by Nickolai Zeldovich,
Silas Boyd-Wickizer, Eddie Kohler, and David Mazières, 2007 OSDI.



More information about the cap-talk mailing list