[cap-talk] What sustained interest in capabilities

[Mitsu Hadeishi]

On Dec 29, 2008, at 6:07 PM, Charles Landau wrote:

> It sounds like you are saying "security is impossible, so let's not
> bother trying." The goal is to not add any insecurity to whatever  
> layer
> we're starting with.

Not at all, precisely the opposite.  My point is all systems are  
essentially layers on top of an insecure foundation, so simply saying  
that something is a layer isn't in itself a valid critique.  One has  
to look at the layer itself.

> You said you "wrap an external ACL-based service in a capability."  
> If I
> understand your approach, the service can then be accessed using the
> capability, but you do not take away the ability of other programs to
> access the service via its ACL-based interface. After all, if your
> wrapper is able to access the underlying ACL-based interface,  
> presumably
> others can too.

No, other programs can't access the service via the ACL-based  
interface unless they breach the security layer.  That is to say, in  
the systems we're discussing, the only public interface is the  
security layer.  However, systems "inside" the layer (i.e., behind the  
firewall, etc.) can of course access the systems via pre-existing ACL- 
based authentication schemes.

For example, consider using the approach we're discussing to present  
an external web interface to underlying backend systems.  Many of the  
backend systems may be built, internally, using legacy ACL-based  
technology, but the external interface uses capability security to  
control access.
>
> In that case, the wrapper metaphor is inapt. You have a layer that  
> makes
> no attempt to completely surround the underlying non-capability-based
> service. It's not a wrapper with a small hole due to some flaw that
> might in principle be plugged.

> "Top-to-bottom" is not really the right description of the pure
> capability systems that have been attempted. Those systems enforce
> capability security completely at a single low layer, not at all  
> layers.
> ("Pure" means there is no way around it.) Starting with a foundation  
> of
> rock, you can build with either more rock or sand. But starting with a
> foundation of sand, you can never increase the stability of the  
> system.
>
>
> It appears to me that you're advocating the layered approach to  
> simplify
> the part of the system that uses the capability layer. Your critics  
> are
> saying it does not simplify the entire system and does not increase  
> the
> security of the entire system. I think you are both right.
>
> On the other hand, if you have built a capability layer such that  
> there
> is no way around it, then you have built a pure capability system, and
> congratulations! If the performance and security of such a system  
> meets
> your goals, then great. But you still have the drawback of all pure
> capability systems, that legacy software doesn't work.
>
> A pure capability system can be built on either bare hardware or  
> another
> suitable operating system. But from a security standpoint, I would  
> have
> higher confidence in the security of the less-complex underlying  
> platform.
> _______________________________________________

The disconnect here I believe is coming from a different conception of  
the environment software is running in.  The systems I've been working  
with recently have been designed in the world of software-as-a-service  
or SOA style designs.  What you're referring to are ordinary programs  
running inside an ordinary OS.  But when you transition to software in  
the cloud, or software services, the picture changes radically.  The  
layer can in fact be the entirety of what is exposed (at least to the  
class of clients "outside" the layer), and thus the capability  
security picture can be and is quite total, from the point of view of  
entities interfacing with the service through the exposed interfaces  
of the layer.  However, what makes this different from approaches  
which attempt to put capabilities all the way down to the OS is that  
the backend does not have to be based on capability security, and can  
be built with ordinary technologies such as Linux, Java, etc.  If the  
*layer* is not breachable, then from the POV of clients of the layer  
it is a "top to bottom" capability world.

>
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk