<br><br><div><span class="gmail_quote">On 7/8/06, <b class="gmail_sendername">Talin</b> <<a href="mailto:talin@acm.org">talin@acm.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Brett Cannon wrote:<br>> On 7/7/06, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>>> On 7/8/06, Ka-Ping Yee <<a href="mailto:python-dev@zesty.ca">python-dev@zesty.ca
</a>> wrote:<br>>> > I'd like the answer to be yes. It sounded for a while like this<br>>> > was not part of Brett's plan, though. Now i'm not so sure. It<br>>> > sounds like you're also interested in having the answer be yes?
<br>>> ><br>>> > Let's keep talking about and playing with more examples -- i think<br>>> > they'll help us understand what goals we should aim for and what<br>>> > pitfalls to anticipate before we nail down too many details.
<br>>><br>>> I'd like the answer to be no, because I don't believe that we can<br>>> trust the VM to provide sufficient barriers. The old pre-2.2<br>>> restricted execution mode tried to do this but
2.2 punched a million<br>>> holes in it. Python isn't designed for this (it doesn't even enforce<br>>> private attributes). I guess this is also the main reason I'm<br>>> skeptical about capabilities for Python.
<br>><br>> My plan is no. As Guido said, getting this right is feasibly<br>> questionable. I do not plan on trying to have security proxies or such<br>> implemented in Python code; it will need to be in C. If someone comes
<br>> along<br>> and manages to find a way to make Python work without significantly<br>> changing<br>> the languages, great, and we can toss out my security implementation for<br>> that.<br>><br>> But as of right now, I am not planning on making Python code safe to run in
<br>> Python code.<br><br>It might be possible for the code *outside* the sandbox to create new<br>security policies written in Python.<br><br>Lets start with the concept of a generic "protection" wrapper - its a C
<br>proxy object which can wrap around any Python object, and which can<br>restrict access to a specific set of methods. So for example:<br><br> protected_object = protect(myObject, methods=set('open','close'))<br><br>
'protect' creates a C proxy which restricts access to the object,<br>allowing only those methods listed to be called.<br><br>Now, lets create a security policy, written in Python. The policy is<br>essentially a factory which creates wrapped objects:
<br><br> class MyPolicy:<br> # Ask the policy to create a file object<br> def file( path, perms ):<br> if perms == 'r':<br> # Trivial example, a real proxy would be more<br> # sophisticated, and probably configurable.
<br> return protect( file( path, perms ),<br> methods=set('open', 'read', 'close') )<br> raise SecurityException<br><br>Now, when we create our sandbox, we pass in the policy:
<br><br> sb = Sandbox( MyPolicy() )<br><br>The sandbox calls 'protect' on the policy object, preventing it from<br>being inspected or called inappropriately.</blockquote><div><br>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.
<br><br><br>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.
<br><br>-Brett<br></div></div>