[cap-talk] More Heresey: ACLs not inherently bad

Jonathan S. Shapiro shap at eros-os.com
Mon Sep 1 13:37:33 CDT 2008


On Mon, 2008-09-01 at 11:09 -0700, ihab.awad at gmail.com wrote:
> On Mon, Sep 1, 2008 at 10:55 AM, Jonathan S. Shapiro <shap at eros-os.com> wrote:
> > The real issue is that the kinds of things that we generally forget are
> > actually parameters: like the space of dynamic libraries...
> 
> Sorry I didn't parse "the space of dynamic libraries".

Umm. Sorry. I should have written "name space of dynamic libraries".

My point is that the execution environment of real-world applications
tends to involve a very large number of objects that are conventionally
organized using hierarchical name spaces (directories). It is only
simple to provide these environments if the name spaces are conveyed to
the applications as a single "root" capability. If selectivity becomes
necessary, filtering at exec time becomes a burden on program startup,
and it becomes better to filter dynamically.

> Are you talking about the ability to load (presumably powerless) code...

No code is powerless. Dynamically loaded code that is loaded by a
sensitive application is actually very powerful.

> That can be provided by a suitably
> configured module loader. Yes that might need some sort of a
> namespace. But making it explicit is great since now (!!) you can have
> co-existent multiple versions of lib{foo} without worrying about how
> the global namespace gets polluted.

I am very much in favor of making the name space explicit. My primary
point is that if you *do* make the name space explicit (e.g. by making
the descriptor to "/" an argument to fork() in UNIX), you have achieved
most of what you are going to get out of capability systems in real
practice.

Couple this with I_SENDFD, and one can readily imagine a system that is
96% UNIX compatible at the source level and much more securable than
current systems.


shap



More information about the cap-talk mailing list