<br><br><div><span class="gmail_quote">On 7/20/06, <b class="gmail_sendername">Lawrence Oluyede</b> <<a href="mailto:l.oluyede@gmail.com">l.oluyede@gmail.com</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;">
That's great. I just read your draft but I have little comments to do<br>but before let me say that I liked the idea to borrow concepts from E.<br>I've crossed the E's path in the beginning of this year and I found it<br>
a pot of really nice ideas (for promises and capabilities). Here are<br>my comments about the draft:<br><br>- it's not really clear to me what the "powerbox" is. I think I got<br>the concept of "super process" but maybe it's to be clarified, isn't
<br>it? It become clear in the "threat model" paragraph</blockquote><div><br>The powerbox is the thing that gives your security domains their initial abilities. The OS gives the process its abilities, but it does not directly work with the interpreter. Since the process does, though, it is considered the powerbox and farms out abilities that it has been given by the OS.
<br><br>I have tried to clarify the definition at the start of the doc.<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;">- I hope no Rubystas will read the "Problem of No Private Namespace"
<br>section because they have private/protected keywords to enforce this<br>stuff :-) Writing proxies in C will slow down the dev process (altough<br>will speed up the performance maybe) but in a far future someone will<br>
come up with an alternative closer to the Python level</blockquote><div><br>Maybe. As I said in the doc, any changes must be Pythonic and adding private namespaces right now wouldn't be without much more thought and work.
<br><br>And if Ruby ends up with this security model but more thoroughly, more power to them. Their language is different in the right ways to support it.<br><br>As for coding in C, thems the breaks. I plan in adding stuff to the stdlib for the common case. I might eventually think of a good, generic proxy object that could be used, but as of right now I am not worrying about that since it would be icing on the cake.
<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;">- Can you write down a simple example of what you mean with "changing<br>
something of the built-in objects"? (in "Problem of mutable shared<br>state")</blockquote><div><br>Done. <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 about the performance issues of the capabilities model overall?</blockquote><div><br>Should be faster than an IBAC model since certain calls will not need to check the identity of the caller every time.<br><br>But I am not worrying about performance, I am worrying about correctness, so I did not try to make any performance claims.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- I know what you meant to say but the paragraph about pythonicness<br>and the security model seems a little "fuzzy" to me. Which are the
<br>boundaries of the allowed changes for the security stuff?</blockquote><div><br>Being "pythonic" is a fuzzy term in itself and Guido is the only person who can make definitive claims over what is and is not Pythonic. As I have said, this doc was mostly written with python-dev in mind since they are the ones I have to convince to let this into the core and they all know the term.
<br><br>But I have tacked in a sentence on what the term means.<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;">- You don't say anything about networking and networked resources in
<br>the list of the standard sandboxed interpreter</blockquote><div><br>Nope. Have not started worrying about that yet. Just trying to get the basic model laid out. <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;">
- Suppose we have a .py module. Based on your security model we can<br>import it, right? When imported it generates a .pyc file. The second<br>time we import it what happens? .pyc is ignored? import is not allowed<br>at all? We can't rely on the name of the
file.pyc because an attacker<br>who knows the file.py is secure and the second import is done against<br>file.pyc can replace the "secure" file.pyc with an implementation not<br>secure and can do some kind of harm to the sandbox
</blockquote><div><br>It will be ignored. But I am hoping that through rewriting the import machinery more control over generating .pyc files can be had (see Skip Montanaro's PEP on this; forget the number). This is why exact details were left out of the implementation details. I just wanted people understand the approach to everything, not the concrete details of how it will be coded up.
<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;">- About "Filesystem information". Does the sandboxed interpreter need
<br>to know all that information about file paths, files and so on? Can't<br>we reset those attributes to something arbitrary?</blockquote><div><br>That is the point. It is not that the sandbox needs to know it, its that it needs to be hidden from the sandbox.
<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;">- About sys module: I think the best way is to have a purged fake sys<br>module with only the stuff you need. pypy has the concept of faked
<br>modules too (altough for a different reason)</blockquote><div><br>OK. <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;">- About networking: what do you think about the E's model of really
<br>safe networking, protected remotable objects and safe RPC? Is that<br>model applicable to Python's in some way? We can't use the E's model<br>as a whole (ask people to generate a safe key and send it by email is<br>unfeasible)
</blockquote><div><br>I have not looked at it. I am also not trying to build an RPC system *and* a security model for Python. That is just too much work right now. <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;">
- is the protected memory model a some kind of memory monitor system?</blockquote><div><br>Basically. It just keeps a size_t on the memory cap and another on memory usage, and when memory is requested it makes sure that it won't go over the cap. And when memory is freed the usage goes down. It's very rough (hard to account for padding bits, etc. in C structs), but it should be good enough to prevent a program from hitting 800 MB when you really just wanted it to have 5 MB.
<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;">I think that's all for the draft. I wrote these comments during the<br>reading of the document.
<br><br>Hope some of these help</blockquote><div><br>Thanks, Lawrence.<br><br>-Brett <br></div><br></div>