[cap-talk] Avoid overconfidence (was: Any hope in RSA 2008?)
Stiegler, Marc D
marc.d.stiegler at hp.com
Sat Apr 5 18:55:22 CDT 2008
To be both more optimistic and more pessimistic,
-- The bugs in the darpabrowser were all implementation, not architecture, bugs -- there was nothing as fundamentally flawed as the typical acl flaw of being so heavy weight that it has to be so coarse-grained that you cannot implement POLA. The consequence might be that ocap systems would actually become more secure over time.
-- Not only is our sample size awfully small, the systems in the sample are themselves each individually small. How much more flawed would a 10 million line ocap system be than a 10,000 line ocap system? Would there be a geometric increase in vulnerabilities because of the larger number of cross-module interactions? Or would there be a less-than-linear increase in vulnerabilities because POLA would allow the average module to have much less authority than the average module in the 10K system? I can argue it either way. Indeed, I can argue it both ways at the same time -- a geometric rise in weak vulnerabilities because of unexpected cross-module interactions that allow small escalations of authority, and a less than linear increase in severe vulnerabilities because the percentage of the system with strong powers is so small :-)
--marcs
> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Mark Miller
> Sent: Saturday, April 05, 2008 8:44 AM
> To: General discussions concerning capability systems.
> Subject: Re: [cap-talk] Avoid overconfidence (was: Any hope
> in RSA 2008?)
>
> On Sat, Apr 5, 2008 at 8:00 AM, Mark Miller <erights at gmail.com> wrote:
> > Bottom line: Capabilities today can make a system's security much
> > more robust against its own bugs.
>
> To expand a bit:
>
> In the DarpaBrowser exercise, many of the holes that Wagner &
> Tribble found, even in security-enforcing modules, were
> unexploitable because these modules had so little authority
> available for abuse. This is empirical evidence for the POLA
> -> working ship compartments analogy.
> However, they did find some holes they were able to drive a
> truck through, and did. I think the Waterken review was
> similar, but someone else will need to speak to this more
> definitively.
>
> The bug Eric Northup found in the KeyKOS kernel design was
> also essentially unexploitable, even though the KeyKOS kernel
> is not internally a capability system.
>
> IIRC, the undetected bugs Wagner & PIng inserted into PVote
> were availability bugs, not integrity bugs. Availabiity and
> confidentiality are so much harder than integrity that I have
> essentially written them off in my own work. Achieving robust
> integrity is already hard enough to eat several careers. It
> is both an easier target, and an adequate one for many applications.
>
> We also need to remember that we're enumerating a very small
> number of cases here. We should avoiding drawing too many
> conclusions from such a small sample size.
>
> --
> Text by me above is hereby placed in the public domain
>
> Cheers,
> --MarkM
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
More information about the cap-talk
mailing list