[cap-talk] cap-talk Digest, Vol 57, Issue 14

[Mitsu Hadeishi]

I'd love to get into the specific details of it but the system Monty  
and I worked on is still not fully released yet, so I think the  
details of that particular system may need to stay somewhat under  
wraps for a while (I'll defer to Monty about that question because  
he's still working there and I'm working at another company now).   
However, I can speak in general, theoretical terms.

So yes, in the case of the systems I've been referring to, they do  
involve significant pluggability (in fact that's the whole point of  
them).  That would also apply to the Caja project which is open source  
as you know, where they use capability security to allow using  
Javascript libraries with far less security risk than raw Javascript  
allows.  In general the "layer" approach Monty and I are talking about  
use capabilities for everything --- all access to any resource,  
whatsoever, is, within the layer, mediated by a capability.  I.e., you  
need a capability to access the filesystem, a database, an internet  
connection, to execute code, etc., everything.  So in that sense the  
capability model is not partial at all; it is complete --- within the  
layer.  The sense in which it is a layer is just that, underneath,  
some of these capabilities are actually implemented by simply wrapping  
ACL-based credentials.  However, because everything within the layer  
is based on capabilities, those ACL-based credentials are never used  
directly --- they are only used by an administrator who has the  
authority to create the capability (this authority itself also being a  
capability).  I think this is a general design that would apply to any  
sort of layer-style capability system of the sort we're discussing.

Thus, ACLs only make an apperance on the edges of the system; they are  
not used except to create what one might call root capabilities which,  
once created, are passed around and used as capabilities, and can in  
fact be further refined and wrapped to create more fine-grained  
capabilities (i.e., a database service that only allows certain  
queries, or only allows access to specific tables, etc., all without  
having to reference ACLs at all).

So yes, these layers are, essentially, languages.  However, I could  
imagine building a system that used capability security as a form of  
access control which wasn't a full-blown language, but merely used  
capability security as a theoretical model for passing around  
authority within the system.  Such a system would be of less utility  
but would still allow fine-grained and mixed permissions which are  
very difficult to model with any role-based approach.

Mitsu

On Dec 29, 2008, at 12:32 PM, Steve Witham wrote:

>> From: Mitsu Hadeishi <mitsu at syntheticzero.com>
>>
>> [W]e found that it was quite
>> possible to implement capability security just at a specific layer of
>> a system, so that one can combine ordinary ACL-based security with
>> capability security principles to gain many of the benefits of cap
>> security without having to make every cooperating system capability
>> secure.
>
> Mitsu and Monty, to the extent you're able to talk about it,
>
> I'm curious what this looks like: how the cap layer is accessed by
> users or software making use of it, what sorts of plumbing go on
> within it, and how (and by what authorities) it in turn reaches out to
> things like disk files and internet connections.
>
> How does a user divide up his power on the outside, so that
> he's giving only limited powers to agents on the inside?
>
> I thought the benefit of cap security was in the ability to construct
> and connect things with components.  That wouldn't seem very helpful
> if the layer within which you use capabilities is thin, static, or
> very simple.  Do the layers you're thinking of involve significant
> constructability or plugability?
>
> Capability security means a safer framework for plugging new
> chunks of software together in.  You don't get
> the benefit if one component works within one framework, but
> another component only works within an incompatible framework,
> right?  So the tendency is to want larger & fewer frameworks.
>
> Conversely, doesn't any
> capability framework start to look like a language or OS?
> For instance, in the layer you're talking about, how can you
> implement objects within it such that bad code
> can't break out of its box?  Each object its own OS process?
> A bytecode interpreter?
>
>  --Steve
> P.S. "Deputy" is a good word.
> deputee, someone who's been deputed ("deputize" is newspeak)
> depute -- authorize, delegate
> impute -- attribute cause to, but also credit with a property
> dispute
> computation -- combining imputations
> repute -- reputation
> putative -- supposed or believed (of a quality)
> "From Latin putare, to prune, think, recon."
> http://en.wiktionary.org/wiki/puto#Latin :
>    1. I clean, cleanse.
>    2. I arrange, settle.
>    3. I value, esteem, deem, regard.
>    4. I judge, suspect, suppose.
>    5. I ponder, consider.
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk