[Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]

[Brett Cannon]

On 7/10/06, Talin <talin at acm.org> wrote:
>
> Brett Cannon wrote:
> > Using a factory method callback, one could store the PyCodeObject in a C
> > proxy object that just acts as a complete delegate, forwarding all
> method
> > calls to the internally stored PyCodeObject.  That would work.
> >
> >
> > For this initial implementation, though, I am not going to try to
> support
> > this.   We can always add support like this later since it doesn't
> > fundamentally break or change anything that is already planned.  Let's
> > focus
> > on getting even more basic stuff working before we start to get too
> fancy.
> >
> > -Brett
>
> Thinking about this some more, I've come up with a simpler idea for a
> generic wrapper class. The wrapper consists of two parts: a decorator to
> indicate that a given method is 'public', and a C 'guard' wrapper that
> insures that only 'public' members can be accessed.
>
> So for example:
>
>     from Sandbox import guard, public
>
>     class FileProxy:
>        # Public method, no decorator


Is that supposed to say "no decorator", even though there is one?

       @public
>        def read( length ):
>           ...
>
>        @public
>        def seek( offset ):
>           ...
>
>        # Private method, no decorator
>        def open( path ):
>           ...
>
>     # Construct an instance of FileProxy, and wrap a
>     # guard object around it. Any attempt to access a non-public
>     # attribute will raise an exception (or perhaps simply report
>     # that the attribute doesn't exist.)
>     fh = guard( FileProxy() )


But wouldn't you still need to protect things like object.__metaclasses__()
so that you can't get access to the class and mutate it?  And if you use a
custom metaclass to avoid having object expose the reference you then would
need to protect the metaclass.

I guess I would need to see an implementation to see if there is any way to
get around security protections since it is still Python code.

Now, from my point of view this *is* 'the basic stuff'. In other words,
> this right here is the fundamental sandbox mechanism, and everything
> else is built on top of it.
>
> Now, the C 'guard' function is only a low-level means to insure that
> no-one can mess with the object; It is not intended to be the actual
> restriction policy itself. Those are placed in the wrapper classes, just
> as in your proposed scheme.
>
> (This goes back to my basic premise, that a simple "yes/no" security
> feature can be used to build up much more complex and subtle security
> features.)


Yeah, this tends to be true.

-Brett

The only real complexity of this, as I see it, is that methods to
> references will have to be themselves wrapped.
>
> In other words, if I say 'fh.read' without the (), what I get back can't
> be the actual read function object - that would be too easy to fiddle
> with. What I'd have to get is a wrapped version of the method that is a
> callable.
>
> One relatively simply way to deal with this is to have the 'public'
> decorator create a C wrapper for the function object, and store it as an
> attribute of the function. The class wrapper then simply looks up the
> attribute, and if it has an attribute wrapper, returns that, otherwise
> it fails.
>
> (Although, I've often wished for Python to have a variant of __call__
> that could be used to override individual methods, i.e.:
>
>      __call_method__( self, methodname, *args )
>
> This would make the guard wrapper much easier to construct, since we
> could restrict the methods only to being called, and not allow
> references to methods to be taken.)
>
> -- Talin
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060711/b11958de/attachment.html