<br><br><div><span class="gmail_quote">On 7/7/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/6/06, Talin <<a href="mailto:talin@acm.org">talin@acm.org</a>> wrote:<br>>> And if we can call it for every operation, then we don't have to spend<br>>> time hunting down all of the possible loopholes and ways in which 'file'
<br>>> or other restricted objects might be accessed.<br>><br>> Not true. You have to set this object restriction flag, right? What<br>> happens if you don't set it on all of the proper classes/types? You end up
<br>> in the exact same situation you are with crippling; making sure you cover<br>> your ass with what you flag as unsafe else you risk having something get<br>> passed you.<br><br>But that's a much simpler problem.
<br><br>With the restricted flag, it isn't just *your* code that is prevented<br>from using 'file' - it's *all* code. Only approved gateways that remove<br>the restriction (by setting the interpreter state) can perform<br>
operations on file objects without blowing up.<br><br>This means that if you call some random library function that attempts<br>to open a file, it won't work, because the random library function is<br>still running in restricted mode.
</blockquote><div><br>Right, but that happens with either approach being proposed anyway.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Similarly, if you have a reference to some externally created object<br>that has a reference to a file (or the file class) somewhere in it's<br>inheritance hierarchy, any attempt to access that object will fail.<br><br>Without this, you would have to chase down every bit of library code
<br>that opens file, or has a reference to a file.</blockquote><div><br>Not true. With the library code running under a sandboxed interpreter the checks by either implementation will still be in effect. And if a proxy is returned by open() instead of 'file' with stuff crippled then the worries alleviated even further.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">What I am proposing shares some aspects of both the crippling and the<br>capability model:
<br><br>It's similar to crippling in the sense that you're protecting the object<br>itself, not access to the object. So you avoid the problem of trying to<br>figure out all of the possible ways an object can be accessed.
<br><br>However, where it resembles capabilities is that its an 'all or nothing'<br>approach - that is, you either have access to file, or you don't. Unlike<br>the crippling model where fine-grained access control is implemented by
<br>modifying individual methods of the crippled object, in this scheme we<br>cripple the object *entirely*, and then provide fine-grained access<br>control via wrappers. Those wrappers, in turn, act just like<br>capabilities - you can have different wrappers that have different sets
<br>of access permissions.<br><br>So it provides the advantage of the capability approach in that the set<br>of restrictions can be extended or modified by writing new wrappers.<br><br>Thus, by providing an extremely simple but unbreakable check at the
<br>interpreter level, we can then write classes that build on top of that a<br>richer and more sophisticated set of permissions, while still<br>maintaining a strong barrier to unauthorized actions.</blockquote><div><br>
</div><br>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 the same check in 'file's constructor. With both you would probably also want open() to be a factory function anyway. So I don't see where you gain simplicity or more security. It seems like you are pushing the check into the eval loop, but you still require the flagging of objects as unsafe. Going with the other two proposals you don't burden the eval loop with the check but the objects that you would have flagged in the first place.
<br><br>It just seems like we are pushing around the flagging of unsafe stuff and that doesn't feel like it buys us much.<br><br>-Brett<br></div>