[cap-talk] Horton at HotSec '07: How broadly object/capability?

[Jed Donnelley]

At 02:44 AM 7/9/2007, Ivan Krstić wrote:

I'm glad we agree on so much:

>On Aug 9, 2007, at 5:25 AM, Jed Donnelley wrote:
> > The fact that Microsoft can
> > even publish their 'immutable' first law of security:
>
>I ridiculed that law publicly at RSA this year, and the amount of
>accompanying laughs from the audience seemed to suggest that a non-
>trivial proportion of people knew that the "immutable law" is nonsense.
>
> > 1.  There is simply no alternative but something that
> > amounts to POLA to combat the inherent dangers from
> > running software from a wide variety of sources (which
> > is itself necessary to fully enable a software market).
>
>Agreed.
>
> > The argument will of course be made that certifying
> > software is a viable alternative.
>
>That position is pretty stupid, I think, and amounts to sticking
>one's head in the sand. We're already seeing certified malware for
>mobile platforms in the wild. Right now.

and also glad that we have something to discuss (e.g. to
work on the HotSec discussion):

> > 2.  To support POLA, whose essence is dynamic, there
> > is no viable option other than object/capabilities.
>
>I'm not sure I fully agree, or rather, this might be the wrong way of
>thinking about it. I think capabilities are very much a 90-10 system,
>and no one so far has been willing to spend that 90% of time nailing
>down the details of the last 10% of the functionality in practice.

I believe a number of systems have completed what I consider
to be that final 10% (I could name some - but:), I think
the issue comes down to achieving 100% and at the same time
sufficient compatibility with legacy systems to have enough
code running to increase market share.  That hasn't happened
that I know of.

>In other words, yes, capabilities are the only way I can think of
>achieving true POLA, but this has proven so hard in practice that
>perhaps achieving true POLA shouldn't be the goal.

I'm a little unclear on what constitutes "true" POLA.  Also, I
don't believe there has been anything difficult about achieving
POLA with object/capabilities.  The difficulties come in
getting sufficient software adapted to object/capability
interfaces (e.g. via compatibility or customizing) to
get significant market share.

To me it isn't important how complete the "least" is
in the least authority, but rather how flexible the
interfaces are for allowing as little authority as
is practical to achieve whatever the market requires.
Communicable permission tokens (object parameters) are
the most effective interface that I've seen.  That
is the lowest cost for achieving effectively low
authority.

>On that note, I'd be curious to hear what you think about the
>Bitfrost work as a very impure and merely "capability-inspired"
>approach. I've found, for instance, that developers really like the
>system: almost all I have to tell them about how it works is "imagine
>your program is the only thing running on the machine, except for the
>OS". This is easily understood and designed for.

Probably best the subject of another message.  I think the key
is the dynamics.  That is, from what I understand of your bitfrost
mechanism, it is able to support fine grained access (though I
didn't see how access to files is controlled/communicated),
but the means for managing such access (e.g. running programs
initializing by requesting access rights) seems to me rather
ad hoc and a bit complex (e.g. "certain bundles of rights"
allowed by policy).

When you say that "The laptop's user can use the built-in security
panel to grant additional rights to any application" - this sounds
like what's been referred to on this list as a "power box".  How does
such a "security panel" communicate additional permissions to a
running program?  Sounds like capability communication to me - by
whatever name.  Perhaps you can describe how bitfrost differs
from object/capabilities and we could focus on what value the
differences bring.

--Jed  http://www.webstart.com/jed-signature.html 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20070709/1b732232/attachment.html