[sugar] Integration with web apps (and Moodle specifically!)

[Brett Cannon]

On 9/4/06, Ian Bicking <ianb at colorstudy.com> wrote:
>
> 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.


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).

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.


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.

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.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.laptop.org/pipermail/sugar/attachments/20060904/869eaa90/attachment-0001.html