[cap-talk] A better reference for the "capabilities propagate too easily" argument

[Jonathan S. Shapiro]

On Wed, 2007-08-01 at 08:58 -0700, Mark Miller wrote:
> On 8/1/07, Jonathan S. Shapiro <shap at eros-os.com> wrote:
> > I think it is much simpler than this. The world model of programmers
> > typically does not assume that programs are internally self-hostile.
> > Modularity is done for manageability and engineerability, not for
> > defensibility. In consequence, a purely discretionary,
> > designation=authority model is a perfect fit, and neither mandatory
> > control issues, confused deputy issues, nor revocation issues are
> > relevant problems.
> 
> Again, I have no idea what you or anyone else (except Alan) means when
> they say "discretionary" or "mandatory". For "mandatory" I will
> substitute "confinement" and hope that adequately captures your
> intent.

It does not. I expressed myself badly.

The idea that a single program may have multiple protection domains is
still new and radical. It is only when multiple domains are introduced
with potentially distinct interests and durability rules that the weak
points of capabilities become an issue.

> Once lambda-based language folks did turn to security, confinement was
> immediately seen as relevant. From Hewitt & Baker 1977
> <http://www.lcs.mit.edu/publications/specpub.php?id=762>:

Respectfully, language folks in the mainstream sense *still* haven't
turned to security. Explorations into this area remain matters of
leading-edge research.

> On first encounter, confused deputy is subtle for everyone. But
> language folks are used to thinking about scoping dangers, like
> non-hygienic name capture in macro systems. I think that makes them
> better armed to appreciate confused deputy when it is presented.

Confused deputy isn't an issue when a program is imagined as having a
single intent. The idea that a module not written by me may be hostile
is still not in the common programmer meme set.

shap