[cap-talk] What sustained interest in capabilities

[Mitsu Hadeishi]

That's not an apt metaphor.  Every security approach is ultimately  
implemented "on top of" an insecure "layer" --- the physical world.   
The physical world is itself highly insecure in and of itself.  All  
approaches to security involve creating a layer of some sort of  
another on top of an insecure layer; it's not possible to completely  
rewrite the laws of physics, for example, to be "capability secure"  
--- nor is it necessary.

A layer is more akin to a wrapper (as in packaging) than it is to a  
building resting on a foundation.  If the wrapper has a hole in it,  
yes, there can be a breach in security, but again that applies to  
every approach to security --- we're always building wrappers of one  
sort or another, even in a top-to-bottom approach.

Mitsu

On Dec 29, 2008, at 5:01 PM, Dave Chizmadia - Gmail wrote:

> Hmmm,
>
> So to check this assertion against our physical world
> intuitions, it should be the case that securing a
> multi-story building to a 2-meter thick reinforced
> concrete slab that is then laid on the sand of an
> ocean beach will secure the building against the
> effects of the ocean during a hurricane?
>
> -DMC
>
> PS: This doesn't mean that the slab is a bad idea,
>    since it would provide better protection against
>    normal tidal forces than setting the floor of the
>    building directly on the sand. But it doesn't
>    provide any protection against the basic problem
>    that sand is a poor foundations for stable buildings.
>
>
> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Rob Meijer
> Sent: Monday, December 29, 2008 4:51 PM
> To: General discussions concerning capability systems.
> Subject: Re: [cap-talk] What sustained interest in capabilities
>
>
> On Mon, December 29, 2008 20:09, David-Sarah Hopwood wrote:
>
>>> The "impedance mismatch" is also far less of a problem than it may
>>> seem, it turns out, for reasons I won't elaborate on in detail here,
>>> but in brief it's because once you wrap an external ACL-based  
>>> service
>>> in a capability (which can have arbitrarily complex code controlling
>>> access), the laws of capability authority transfer then take over.
>>> You really don't have to think in terms of ACLs at all, or the fact
>>> that the service itself is unaware of the capability wrapper, from  
>>> the
>>> POV of the layer it is pure capabilities.
>>
>> I disagree. Complexity is the enemy of security, and it's not  
>> possible
>> to make a system simpler by adding layers. Since an ACL layer is
>> typically already too complicated, it is only by removing such layers
>> that we can obtain a high degree of confidence in the security of the
>> whole system.
>
> I think it is definitely possible to make a system simpler by adding
> layers, in fact layering is an important tool in keeping complexity
> manageable.
> Adding a layer on top of a preexisting complex layer that exposes a
> simpler interface to upper layers can certainly reduce the  
> complexity of
> higher layers to an extend that more than compensates for the  
> complexity
> of the intermediate layer. You could look at it partly like removing a
> layer by adding a layer. AppArmor + my MinorFs project for example  
> remove
> a (complex) ACL layer from visibility to higher layers by adding
> additional layers on top of that ACL layer.
>
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk