<br><br><div><span class="gmail_quote">On 7/6/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/5/06, Talin <<a href="mailto:talin@acm.org">talin@acm.org</a>> wrote:<br>>> Transitioning from the checked to the unchecked state could only be done<br>>> via C code. So the 'file' wrapper, for example, would switch over to the
<br>>> unchecked interpreter before calling the actual methods of 'file'. That<br>>> C wrapper might also check the current permission state to see what<br>>> operations were legal.<br>><br>> So add the proper checks in Python/ceval.c:call_function() to check for
<br>> this<br>> flag on every object passed in that is called?<br><br>Right. I also realized that you would need to add code that propagates<br>the checked bit from the class to any instances of the class. So<br>whenever you call a class to create an object, if the class has the
<br>checked bit, the instance will have it set as well.<br><br>>> So essentially, what I propose is to define a simple security primitive<br>>> - which essentially comes down to checking a single bit - and use that
<br>>> as a basis to create more complex and subtle security mechanisms.<br>><br>> Right, but it does require that the proper verification function be turned<br>> on so that the permission bit on 'file' is checked. It kind of seems like
<br>> 'rexec' and its f_restricted flag it set on execution frames, except you<br>> are<br>> adding an object-level flag as well.<br>><br>> Either way, the trick is not fouling up switching between the two checking
<br>> functions.<br>><br>> -Brett<br><br>I wasn't aware of how rexec worked, but that seems correct to me.<br><br>Given a 'restricted' flag on a stack frame, and one on the object as<br>well, then the code for checking for permission violations is nothing
<br>more than:<br><br> if (object.restricted && exec_frame.restricted)<br> raise SecurityException<br><br>In particular, there's no need to call a function to check a "permission<br>level" or "access rights" or anything of the sort - all that stuff is
<br>implemented at a higher level.<br><br>By making the check very simple, it can also be made very fast. And by<br>making it fast, we can afford to call it a lot - for every operation in<br>fact.<br><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.</blockquote><div><br>Not true. You have to set this object restriction flag, right? What happens if you don't set it on all of the proper classes/types? You end up in the exact same situation you are with crippling; making sure you cover your ass with what you flag as unsafe else you risk having something get passed you.
<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;">Originally I had thought to simply add a check like the above into the<br>interpreter. However, that would mean that *all* code, whether
<br>restricted or not, would have to pay the (slight) performance penalty of<br>checking that flag. So instead, I thought it might be more efficient to<br>have two different code paths, one with the check and one without. But
<br>all this is based on profound ignorance of the interpreter - there might<br>be a hundred other, better ways to do this without having to create two<br>versions of ceval.</blockquote><div><br>Yeah, keep it simple, especially when it comes to
ceval.c . <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;">Another interesting think about the check bit idea is that you can set
<br>it on any kind of object. For example, you could set it on individual<br>methods of a class rather than the class as a whole. However, that's<br>probably needlessly elaborate, since fine-grained access control will be
<br>much more elegantly achieved via trusted wrappers.</blockquote><div><br>Yeah, that seems a bit extreme.<br><br>-Brett<br></div></div>