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

At 11:35 AM 7/11/2006 -0700, Brett Cannon wrote: >On 7/11/06, Phillip J. Eby ><[EMAIL PROTECTED]> wrote: >>At 10:56 AM 7/11/2006 -0700, Brett Cannon wrote: >> >On 7/10/06, Talin >> <[EMAIL PROTECTED]> >> wrote: >> >>(A

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

On 7/11/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: At 10:56 AM 7/11/2006 -0700, Brett Cannon wrote:>On 7/10/06, Talin <[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote:>>(Although, I've often wished for Python to have a variant of __call__ >>that could be used to override individual methods, i.e.:

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

At 10:56 AM 7/11/2006 -0700, Brett Cannon wrote: >On 7/10/06, Talin <[EMAIL PROTECTED]> wrote: >>(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, *

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

On 7/10/06, Talin <[EMAIL PROTECTED]> 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

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

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

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

On 7/8/06, Talin <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> On 7/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:>> On 7/8/06, Ka-Ping Yee <[EMAIL PROTECTED] > wrote:>> > I'd like the answer to be yes.  It sounded for a while like this>> > was not part of Brett's plan, though.  Now i'm not so

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

Brett Cannon wrote: > On 7/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> On 7/8/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: >> > I'd like the answer to be yes. It sounded for a while like this >> > was not part of Brett's plan, though. Now i'm not so sure. It >> > sounds like you're also i

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

On 7/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: On 7/8/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:> The situation you're describing here is a classic case of one> component keeping a closely held authority while using it to > provide some limited capability to some other component.  This> com

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

On 7/7/06, Talin <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> On 7/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:> On 7/7/06, Brett Cannon <[EMAIL PROTECTED] > wrote:>> > I guess I am just not seeing where your approach is better than>> preventing>> > the constructor in 'file' and having

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

On 7/8/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > The situation you're describing here is a classic case of one > component keeping a closely held authority while using it to > provide some limited capability to some other component. This > comes up quite often when you're trying to write secure

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

On Fri, 7 Jul 2006, Talin wrote: > While I was typing this, I did realize a drawback to poisoned objects, > which I will illustrate by the following example: > > Suppose we want to grant to the sandboxed program permission to read and > write cofiguration properties. We don't want to give them arbi

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

Brett Cannon wrote: > On 7/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > >> >> On 7/7/06, Brett Cannon <[EMAIL PROTECTED]> wrote: >> > I guess I am just not seeing where your approach is better than >> preventing >> > the constructor in 'file' and having open() return the 'file' object or >>

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

On 7/7/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:>  Good point.  C code could circumvent the bit check by doing all of the> work behind the scenes without pushing the object on the stack.  But if> the check is in the C code for the object itself it is much harder to > get aroun

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

Brett Cannon wrote: > Good point. C code could circumvent the bit check by doing all of the > work behind the scenes without pushing the object on the stack. But if > the check is in the C code for the object itself it is much harder to > get around. C code can circumvent the bit check by ca

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

On 7/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: On 7/7/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> I guess I am just not seeing where your approach is better than preventing> the constructor in 'file' and having open() return the 'file' object or > proxy object.  With your approach 'file' w

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

On 7/7/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > I guess I am just not seeing where your approach is better than preventing > the constructor in 'file' and having open() return the 'file' object or > proxy object. With your approach 'file' would be flagged, but with the > other you just put th

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

On 7/7/06, Talin <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> On 7/6/06, Talin <[EMAIL PROTECTED]> wrote:>> And if we can call it for every operation, then we don't have to spend>> time hunting down all of the possible loopholes and ways in which 'file' >> or other restricted objects might be ac

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

Brett Cannon wrote: > On 7/6/06, Talin <[EMAIL PROTECTED]> wrote: >> And if we can call it for every operation, then we don't have to spend >> time hunting down all of the possible loopholes and ways in which 'file' >> or other restricted objects might be accessed. > > Not true. You have to set t

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

On 7/6/06, Talin <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> On 7/5/06, Talin <[EMAIL PROTECTED]> wrote:>> Transitioning from the checked to the unchecked state could only be done>> via C code. So the 'file' wrapper, for example, would switch over to the >> unchecked interpreter before calling

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

Brett Cannon wrote: > On 7/5/06, Talin <[EMAIL PROTECTED]> wrote: >> Transitioning from the checked to the unchecked state could only be done >> via C code. So the 'file' wrapper, for example, would switch over to the >> unchecked interpreter before calling the actual methods of 'file'. That >> C w

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

On 7/5/06, Talin <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> On 7/5/06, Michael Chermside <[EMAIL PROTECTED]> wrote:>> If you were using capabilities, you would need to ensure that>> restricted interpreters could only get the file object that they >> were given. But then _all_ of these fancy ve

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

Brett Cannon wrote: > On 7/5/06, Michael Chermside <[EMAIL PROTECTED]> wrote: >> If you were using capabilities, you would need to ensure that >> restricted interpreters could only get the file object that they >> were given. But then _all_ of these fancy versions of the >> restrictions would be im

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

On 7/5/06, Greg Ewing <[EMAIL PROTECTED]> wrote: Michael Chermside wrote:> That leaves the other problem: auxiliary means of accessing> objects. There are things like gc.get_objects(). In the special> case of file, which is a type that's also dangerous, there are > tricks like "object().__class__._

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

Michael Chermside wrote: > That leaves the other problem: auxiliary means of accessing > objects. There are things like gc.get_objects(). In the special > case of file, which is a type that's also dangerous, there are > tricks like "object().__class__.__subclasses__()". My approach to that would

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

On 7/5/06, Michael Chermside <[EMAIL PROTECTED]> wrote: In response to Ka-Ping's comments on the subject of "Resource Hiding"vs "Resource Crippling", Brett says:> It seems that your criticisms are aimed at resource crippling> being a "plug holes as needed but if you foul up you are screwed" > with

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

In response to Ka-Ping's comments on the subject of "Resource Hiding" vs "Resource Crippling", Brett says: > It seems that your criticisms are aimed at resource crippling > being a "plug holes as needed but if you foul up you are screwed" > with resource hiding being more "fix the fundamental issu