[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