[Python-Dev] new security doc using object-capabilities

[Brett Cannon]

On 7/23/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>
> At 09:27 PM 7/23/2006 -0700, Brett Cannon wrote:
>
> When I say "name checker" I mean the Zope type that allows you to specify
> a
> list of names that are allowed for a given object.  This allowing is not
> based on identity or code signing or anything like that.  It's just a list
> of attribute names: i.e. a capability mask over an existing object.
>
> When you create a proxy using this name mask, that proxy becomes a
> capability that allows access to the given names on the underlying object.


OK, then using the term "namechecker" through me off.

>I like the fundemental design difference of object-capabilities
>
> It's not a difference at all, let alone a fundamental one.  Zope just
> happens to allow other kinds of security checking *in addition to*
> capabilities, if you want them.  However, most of its more basic
> encapsulation features are 100% capability based.



> Meanwhile, if you want to implement an object-capability system, you will
> need something that is basically a mask, to allow one piece of code to
> create capabilities that can be given to another.  What you end up with
> for
> doing that is going to look almost exactly like a Zope proxy plus a Zope
> name checker.



I hate to harp on this point, but there seems to be a trend that when
> people have capabilities on their mind, they tend to look at Zope and
> dismiss it as not being capability-based, when in fact Zope's approach is
> capabilities *plus* other things.


Well, Jim said that Zope proxies didn't conform to the strict definition of
object-capabilities the last time this all came about:
http://mail.python.org/pipermail/python-dev/2003-March/033884.html and
http://mail.python.org/pipermail/python-dev/2003-March/033915.html .  He
said they *could* be made to be what object-capabilities is defined as, but
they were not currently structured that way.  Those comments are one of the
reasons I never considered thinking of Zope proxies as a object-capabilities
system.

(Of course, most of those "other things" have to do with closing holes like
> __subclasses__, while improving performance by still allowing lots of
> common objects not to be proxied.)
>
>

OK, then I need something clarified.  If you read
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TransitionToSecurityProxies,
it talks about creating the proxies.  I get they restrict attribute
access
and wrap all returned objects in proxies themselves (unless they are
considered safe).  But to judge whether an attribute should be returned, it
checks the security context.  It also mentions how access to the security
policy must be available so that proper security checks can be done to
either grant or deny access.

So what I want to know is if this security context is this global thing that
proxies access every time to check whether something is allowed or not.  Or
is it a per-object specification?  And what is the security domain for Zope
proxies; objects, interpreter, running Python program, what?

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060724/133649ce/attachment-0001.html