[cap-talk] What sustained interest in capabilities

[Mark Miller]

On Wed, Jan 7, 2009 at 7:17 PM, Steve Witham <sw at tiac.net> wrote:
> It reminds me of an E vat, in this case talking to some
> software, files and OS services outside itself, still with their
> vulnerabilities but hopefully fewer of them exposed.
>
> So this layer can't "add security" to existing systems, but the
> idea adds a way to create more secure systems.

Yes. In writing The Structure of Authority with Bill Tulloh and Shap,
(and again in editing this text into my thesis), I tried to carefully
explain what kind of security you do and do not obtain with this
approach.

I quote from section 21.2 of <http://erights.org/talks/thesis/> at
length because the context is needed. This may still not be sensible
by itself, in which case please read it in its larger context.


One possibility would be
that Doug runs a non-conventional operating system that supports
finer-grained POLA
[DH65, Har85, SSF99]. In this chapter, we explore a surprising
alternative—the use of
language-based security mechanisms such as those provided by E. We
will explain how
Doug uses CapDesk and Polaris to reduce his exposure while still
running on a conventional
operating system. But first, it behooves us to be clear about the
limits of this approach. In
our story, we combine the functionality of CapDesk and Polaris, though
they are not yet
actually integrated. (Integrating CapDesk's protection with that
provided by an appropri-
ate secure operating system would yield yet further reductions in
exposure, but these are
beyond the scope of this dissertation.)

CapDesk [SM02] is a capability-secure distributed desktop written in
E, for running
caplets —applications written in E to be run under CapDesk. CapDesk is
the user's graphical
shell, turning a user-interface action into a request to a caplet,
carrying a reference saying
what ob ject the caplet should operate on. As with the cat example in
Section 3.2, these
requests also convey the permission to operate on this ob ject. For
legacy applications like
Excel, CapDesk delegates their launching to Polaris [SKYM04]. Like cp,
Excel needs to run
with all the authority of its user's account. Polaris creates and
administers separate user
accounts for this purpose, each of which starts with little authority.
CapDesk has Polaris
launch Excel in one of these accounts, and dynamically grant to this
account the needed
portion of the actual user's authority.

CapDesk is the program Doug uses to subdivide his authority among
these applications.
To do this job, CapDesk's least authority is all of Doug's authority.
Doug launches CapDesk
as a conventional application in his account, thereby granting it all
of his authority. Doug
is no less exposed to a flaw in CapDesk than Barb is to a flaw in each
application she runs.
CapDesk is part of Doug's platform, and is therefore a central point
of failure for Doug; but
the programs launched by CapDesk are not.

CapDesk does not affect Doug's vulnerability to Barb. Doug is no more
or less exposed
to an action taken by Barb, or one of her applications, than he was
before. If the base
operating system does not protect his interests from actions taken in
other accounts, then
the whole system is a central point of failure for him. Without a base
operating system
that provides foundational protection, no significant reduction of
exposure by other means
is possible. So, let us assume that the base operating system does
provide effective per-
account protection. For any legacy programs that Doug installs or runs
in the conventional
manner—outside the CapDesk framework—Doug is no less exposed than he
was before. All
such programs remain central points of failure for him. If the "~doug"
account is corrupted
by this route, again, CapDesk's protections are for naught.

However, if the integrity of "~doug" survives these threats, Doug can
protect the assets
entrusted to him from the programs he runs by using CapDesk + Polaris
to grant them
least authority.


-- 

    Cheers,
    --MarkM