<div>On 9/4/06, Ian Bicking <<a href="mailto:ianb@colorstudy.com">ianb@colorstudy.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Ivan Krstić wrote: >> peer-to-peer code sharing that isn't entirely trusted (and I'm not sure >> how feasible that is) then we'll need to really consider the security of >> those communications. > > It seems like the Sugar guys want to do this, but they're not providing > a security model, nor an explanation of how they're addressing it. > They're implementing mobile agents, and well, the security industry > learned in the '90s that mobile agents don't work well at all. So, I'd > like to see some careful thought about security from them really soon, > or I'll be screaming murder. Brett Cannon has been doing some work on a Python interpreter that has limited capabilities; i.e., the entire interpreter is hobbled so it can't open files or do anything to effect the system, unless (I think) C modules are specifically loaded to give it abilities.  Kind of how Javascript works.  At least, I think Brett has been working on something like that.  I don't know the status.  I'll copy him to find out.</blockquote><div> So my work is being done in the bcannon-objcap branch of Python's svn repository.  In that branch there is a text file named securing_python.txt that explains the approach to the security model as well as the current status. Basically I am making sure that Python, at the interpreter level (of which there can be several in a single process), can be sandboxed so that they don't harm the OS or other interpreters.  Pure Python code will be safe based on the security settings that are turned on, but importing C modules will need to be whitelisted for importing since C code can obviously get around any security measure I implement. This is being actively worked on as it is part of my PhD dissertation to add Python to the web browser for client-side web scripting.  The question is not if JavaScript-level protection will come into place, but how extensible and configurable it will be beyond that (it's all dependent on my supervisor wanting to fund the work if it drags on to make it more configurable instead of exactly what we need for my PhD). </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">With RPC and some security around RPC, this could be a useful strategy.   I'm not sure if PyGTK would be safe enough to expose to untrusted code -- it seems like it's exposing a lot, and I don't know if GTK is robust enough or written with that kind of use in mind.  Providing higher-level known-safe interfaces would be possible, but using a restricted interpreter you couldn't write those higher level interfaces in Python.   They'd either have to be out-of-process (back to RPC, and I don't know if writing a GUI app over RPC is reasonable), or the higher level interfaces would have to be written in something like C or Pyrex.  Which may be feasible.</blockquote><div> Yeah.  Taking the the PyGTK API, writing a C module that wraps it in a safe manner, and then allow importation of that wrapper and not PyGTK would be the way to secure it.  And with that you then choose whether the app can open aribtrary windows, or if there is a cap, or a request to open windows, etc. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Running untrusted code is very interesting, but also scary.  OTOH, anything we can do to make untrusted Python code possible also could be helpful as an introductory environment where children can safely experiment with little danger of causing problems with their system.</blockquote><div> My hope is to come up with an interpreter that could run code uploaded by a random user to a web page without any worries of the system being harmed.  Hopefully that is enough to let kids experiment without destroying their machines. -Brett </div></div>