Try Python!

[Armin Ronacher]

Hiho,

One week ago I came across the nice `Try Ruby!`_ demonstration which
features an ajax based ruby console and a 20 minutes ruby tutorial.
I really liked that application and so I started to port that to
python.
Since I got a bit confused by the very complex javascript code I wrote
a
webconsole from scratch.

The result is a very basic python console which behaves like the CLI
one, except that it can't handle `raw_input` or any other method call
trying to access `sys.stdin`.

At the moment the application is multithreaded and evaluated
expressions
in a dict holding the sessions variables of the client connections.

Because of the behaviour the application breaks down easily and isn't
secure. This happens because I haven't finished it yet. Additionally
sessions don't have a timeout so you have to restart the server if it's
eating to much RAM.

If someone is interested in putting up that application on a public
server I can tell the application to spawn from inside XEN hosts and to
use forking instead of the multithreaded approach currently used.

The application is licensed under the GNU GPL, the sourcecode is
available via svn from::

http://trac.pocoo.org/repos/trypy

Since it requires Paste, PasteDeploy and the current colubrid checkout,
here the installation for copy/pasteing:

- easy_install Paste
- easy_install PasteDeploy
- svn co http://trac.pocoo.org/repos/trypy
- cd trypy
- svn co http://trac.pocoo.org/repos/colubrid/trunk/colubrid
- python trypy.py

The last command starts the application.

And here a screenshot of a running session:
http://trac.pocoo.org/wiki/TryPy

Regards,
Armin

 

[BartlebyScrivener]

Armin,

Mike Meyer already took a crack at this, and his starts right up just
by clicking on the link.

http://www.mired.org/home/mwm/try_python/

Yours looks prettier, but I don't think novices are going to be able to
figure out how to start it.

Regards,

rick

 

[Michael Tobis]

We had some discussion of this in the edu-sig meeting at PyCon.

I alleged that I had read that there is no such thing as a Python
sandbox. Others claimed that one could simply preprocess and disallow
"dangerous" constructs. My allegation was based on an argument from
authority; I recalled reading the assertion from one of the c.l.p.
regulars that I consider authoritative, though I don't remember which
(Frederick, Alex, Aahz perhaps?).

This is all in relation to why the rexec module went away, and is
certainly relevant to what can be achieved in the sphere of teaching
with python in general, and teaching python with python in particular.

I refer you in particular to these messages from BDFL:

http://mail.python.org/pipermail/python-dev/2002-December/031246.html

http://mail.python.org/pipermail/python-dev/2002-December/031251.html

So what is the scoop? Why does Guido say there is no such thing as a
secure Python, and (as is generally reasonable) presuming he is correct
on the matter, how can these sites work safely?

thanks
mt

 

[Paul Rubin]

So what is the scoop? Why does Guido say there is no such thing as a
secure Python, and (as is generally reasonable) presuming he is correct
on the matter, how can these sites work safely?

One way is to run the Python interpreter itself in a sandbox, e.g. a
virtual computer.

 

[Terry Reedy]

....

I refer you in particular to these messages from BDFL:

http://mail.python.org/pipermail/python-dev/2002-December/031246.html

This one says that new style classes in 2.2 opened a new, sizable, security
hole. One can avoid this by running 2.1.

http://mail.python.org/pipermail/python-dev/2002-December/031251.html

This one says that he doubts that Python will ever reach a level of no
security flaws. And that he does not want to spend his life just getting
close.

So what is the scoop? Why does Guido say there is no such thing as a
secure Python, and (as is generally reasonable) presuming he is correct
on the matter, how can these sites work safely?

There are, of course, degrees of security. Any site can choose to operate
with a lesser degree than Guido would accept for a 'secure Python' release.

If I were running a publicly available site, I would run Python under *nix
with someone with some security admin experience. I would use a dedicated
machine from a few years ago not needed for anything else. I would have
the full installation backed up on a bootable CD or DVD. I would expect
most visitors to not pee in the fountain. And I would expect to have to
reinstall occasionally when someone did.

And I would at least remove all the net access and protocol modules and
worry about making sure that the interpreter had no access to the system
net resources so as to not be a vehicle for damaging other machines.

Terry Jan Reedy

 

[Armin Ronacher]

Armin,

Mike Meyer already took a crack at this, and his starts right up just
by clicking on the link.

http://www.mired.org/home/mwm/try_python/

Hm. Looks not that useful since you can't create any functions and you
can remove the prompt

Yours looks prettier, but I don't think novices are going to be able to
figure out how to start it.

They don't have to figure out if someone would install that on a public
host. But therefore the application has to run inside of a jail or a
XEN since python doesn't have a secure sandbox.

Regards,
Armin

 

[Serge Orlov]

We had some discussion of this in the edu-sig meeting at PyCon.

I alleged that I had read that there is no such thing as a Python
sandbox. Others claimed that one could simply preprocess and disallow
"dangerous" constructs. My allegation was based on an argument from
authority; I recalled reading the assertion from one of the c.l.p.
regulars that I consider authoritative, though I don't remember which
(Frederick, Alex, Aahz perhaps?).

This is all in relation to why the rexec module went away, and is
certainly relevant to what can be achieved in the sphere of teaching
with python in general, and teaching python with python in particular.

I refer you in particular to these messages from BDFL:

http://mail.python.org/pipermail/python-dev/2002-December/031246.html

http://mail.python.org/pipermail/python-dev/2002-December/031251.html

So what is the scoop? Why does Guido say there is no such thing as a
secure Python, and (as is generally reasonable) presuming he is correct
on the matter, how can these sites work safely?

They should rely on the OS ability to restrict processes: set max
amount of physical and virtual memory used by the process, disable file
system access, disable sending of signals, set max amount of CPU time,
disable creation of new processes, etc...

Serge.

 

[Ben Finney]

So what is the scoop? Why does Guido say there is no such thing as a
secure Python, and (as is generally reasonable) presuming he is correct
on the matter, how can these sites work safely?

"Security is a process, not a product."

There's no such thing as "a secure foo", in absolute terms. One can
point to flaws in non-foo and show how foo avoids those flaws; one can
possibly even defend a claim that "foo is more secure than bar". But
to state "there is no such thing as a secure foo" simply points out
that it is always possible to be "more secure", which is an ongoing
process of improvement that can never be complete.

Security is also not an absolute good. It's a truism that measures
which prevent illegitimate activity also incrementally make legitimate
activity more onerous. The real trick is to maximise the one and
minimise the other. The tradeoff can never be complete or perfect,
since everyone's definition of the right tradeoff is different and
constantly evolving.

Security is also not a single dimension. Physical security, personnel
security, network security, data security, risk management, etc
cetera; all these are areas that have their own set of security versus
accessibility tradeoffs.

In this light, the process of Python security must be ongoing; if it's
not, it's regressing. This doesn't mean Python is "not secure", or
"not safe"; those are absolutes again, and they don't apply.

Sites can operate securely by being aware of the security
ramifications of their infrastructure decisions, and being aware of
security issues that apply to anything they do. To pretend that
security can be obtained by getting hold of a "secure programming
language" is a delusion.

 

[bruno at modulix]

We had some discussion of this in the edu-sig meeting at PyCon.

I alleged that I had read that there is no such thing as a Python
sandbox.

And yet Zope 2 has some restricted environment for TTW scripts...