[cap-talk] What are caps good for? - kindred spirit.

[Jed Donnelley]

At 01:21 PM 5/7/2004, David Wagner wrote:
>David Hopwood writes:
> >Imagining that there is a single boundary, between the user's shell and
> >applications, where POLA needs to be applied is a misconception. It is
> >commonplace for applications to need to enforce their own security
> >boundaries. Mechanisms like confinement are intended to support this.
>
>Naah.  I still maintain that full-bore confinement (in Lampson's sense
>of the word) is irrelevant.  What we really care about is the ability
>to draw security boundaries.

Hurray.  Boundaries to allow POLA.

>I worry that the meaning of the word "confinement" may be causing
>confusion.  If there is any confusion, I blame Lampson: he took a word
>with an intuitive-sounding word and assigned it an unusual definition.
>There's a difference between the idea of (1) using trust perimeters to
>build a restricted execution environment for executing untrusted code
>and (2) confinement for executing untrusted code.  Trust perimeters are
>mainly about preserving the integrity of the rest of the system, in case
>the untrusted code misbehaves, whereas confinement also asks that we
>protect the confidentiality of any data given to that untrusted code.
>Confinement, as Lampson used the word, is concerned not merely with
>providing a trust boundary to protect us from Word scripts (see (1)),
>but also with the problem of covert channels.  Can a Word script that
>is legitimately given access to some confidential content leak that
>data to a colluder on the same machine or out somewhere on the network?
>The confinement problem (as Lampson explained it) is to eliminate all
>covert channels that might allow such leakage.
>
>Confinement (in Lampson's sense) appears to be unachievable in practical
>systems.  There's no known way to eliminate all covert channels in any
>useful, multi-user system.
>
>Fortunately, confinement is not needed.  All we really need is a way
>to draw a trust perimeter, so that we can execute the Word script in a
>restricted execution environment that has very limited privileges and
>that is firewalled off from the rest of the system.  Second, we need
>to avoid giving untrusted Word scripts access to confidential content;
>otherwise, we must accept that the Word script could leak any data it is
>allowed to read.  Thus, it might be reasonable to set up the security
>policy so that a Word script only has access (at most) to the Word
>document it was found in, but nothing else.

Hurray!  Seemingly a kindred spirit!

One thing I would point out (at the risk of seeming to switch sides,
I'm not, just clarifying) is that the notion of "confinement" (ala
Lampson) can be extended/divided into two types:
data confinement and authority confinement.

I don't want to suggest that you aren't aware of these (they've
come up several times in this discussion), just to bring the
distinction into what I see as this more focused dialog.

Data confinement refers to the more discussed type of trying to
insure that an agent not be able to communicate data outside
itself (except perhaps for some sort of return path).  Authority
confinement goes a bit beyond that in that it is concerned with
restricting the ability of such an agent to share rights (e.g. rights
that might be long lasting) outside itself.  I have discussed
elsewhere how I believe the "long lasting" concern can be
addressed without "confinement" and even without proxying.

I believe that both types of confinement are comparably
difficult/impossible to achieve and more importantly are counter
productive.  I believe that if we give up on "confinement" and
accept what I refer to as an agent's "inalienable" right:

http://www.webstart.com/jed/papers/Managing-Domains/#s6

to share data/authority to implement whatever service it is called upon
to perform then we will be more likely to make progress on building
POLA oriented mechanisms and interfaces (where I started this
discussion).

--Jed http://www.nersc.gov/~jed/