Secure Python

[Paul Boddie]

[Re-adding material...]

Here is where the issue of sandboxing is indirectly introduced into the
discussion.

i'm not talking about sandboxing, that's a whole different kettle of
fish. i'm talking about resource managment options you can set in for
instance, the linux kernel.

Yes, I know. I was merely covering related concepts of relevance
introduced earlier in the discussion (see above). In any case, if you
only have control over resource limits on execution contexts at the
operating system process level, yet your server architecture is
entirely based on a single process with many (micro)threads, then
you've got to consider the problem of restricting their
behaviour/consumption using the facilities available to you, most
likely by considering other server architectures. This, I argue, is
perfectly reasonable in order to solve both issues being discussed
using operating system facilities.

you can limit the cpu and memory a process uses while still allowing it
the same access it would have outside of a sandbox. that way if any
clever monkeys try to dos you they merely consume their alloted quota.

Indeed.

Paul

 

[Hendrik van Rooyen]

The problem with linux kernel limits are, that they won't work really good
on MacOSX and Windows... OTOH the idea is the right one, but the effect can
be achieved inside of Python. Since Python does byte compile the code and
the interpreter evaluates each byte code token in one evaluation step. The
interpreter could be extended for such usecases to count and limit the
number of evaluation steps allowed for untrusted script or methods in
untrusted script as well as to limit the recursion depth or memory to be
allocated. All those limits are managed by the interpreter for script code
and hence can be limited for untrusted code by the interpreter. This also
does not really make DoS impossible (what about C extensions? - maybe
restricting "import"?). - As I said before in this thread, making a sandbox
really secure is a hard job, and may need some serious changes in the
Python interpreter, but AFAIK from Tcl, it is possible - and would be nice
to have.

I seem to recall previous discussion on this group about a thing called the
bastion module,
and that it was deprecated. Not sure if it has any relevance.

- Hendrik

 

[Hendrik van Rooyen]

The problem with linux kernel limits are, that they won't work really good
on MacOSX and Windows... OTOH the idea is the right one, but the effect can
be achieved inside of Python. Since Python does byte compile the code and
the interpreter evaluates each byte code token in one evaluation step. The
interpreter could be extended for such usecases to count and limit the
number of evaluation steps allowed for untrusted script or methods in
untrusted script as well as to limit the recursion depth or memory to be
allocated. All those limits are managed by the interpreter for script code
and hence can be limited for untrusted code by the interpreter. This also
does not really make DoS impossible (what about C extensions? - maybe
restricting "import"?). - As I said before in this thread, making a sandbox
really secure is a hard job, and may need some serious changes in the
Python interpreter, but AFAIK from Tcl, it is possible - and would be nice
to have.

I seem to recall previous discussion on this group about a thing called the
bastion module,
and that it was deprecated. Not sure if it has any relevance.

- Hendrik

 

[Hendrik van Rooyen]

The problem with linux kernel limits are, that they won't work really good
on MacOSX and Windows... OTOH the idea is the right one, but the effect can
be achieved inside of Python. Since Python does byte compile the code and
the interpreter evaluates each byte code token in one evaluation step. The
interpreter could be extended for such usecases to count and limit the
number of evaluation steps allowed for untrusted script or methods in
untrusted script as well as to limit the recursion depth or memory to be
allocated. All those limits are managed by the interpreter for script code
and hence can be limited for untrusted code by the interpreter. This also
does not really make DoS impossible (what about C extensions? - maybe
restricting "import"?). - As I said before in this thread, making a sandbox
really secure is a hard job, and may need some serious changes in the
Python interpreter, but AFAIK from Tcl, it is possible - and would be nice
to have.

I seem to recall previous discussion on this group about a thing called the
bastion module,
and that it was deprecated. Not sure if it has any relevance.

- Hendrik

 

[Hendrik van Rooyen]

The problem with linux kernel limits are, that they won't work really good
on MacOSX and Windows... OTOH the idea is the right one, but the effect can
be achieved inside of Python. Since Python does byte compile the code and
the interpreter evaluates each byte code token in one evaluation step. The
interpreter could be extended for such usecases to count and limit the
number of evaluation steps allowed for untrusted script or methods in
untrusted script as well as to limit the recursion depth or memory to be
allocated. All those limits are managed by the interpreter for script code
and hence can be limited for untrusted code by the interpreter. This also
does not really make DoS impossible (what about C extensions? - maybe
restricting "import"?). - As I said before in this thread, making a sandbox
really secure is a hard job, and may need some serious changes in the
Python interpreter, but AFAIK from Tcl, it is possible - and would be nice
to have.

I seem to recall previous discussion on this group about a thing called the
bastion module,
and that it was deprecated. Not sure if it has any relevance.

- Hendrik

 

[Stephan Kuhagen]

I seem to recall previous discussion on this group about a thing called
the bastion module,
and that it was deprecated. Not sure if it has any relevance.

Never heard about it, maybe it's worth a look for the OP.

Stephan

 

[Fredrik Lundh]

Never heard about it, maybe it's worth a look for the OP.

$ more Misc/HISTORY

...

What's New in Python 2.3 alpha 2?
=================================

*Release date: 19-Feb-2003*

...

- Bastion.py and rexec.py are disabled. These modules are not safe in
Python 2.2 or 2.3.

historical references:

http://effbot.org/librarybook/rexec.htm
http://effbot.org/librarybook/bastion.htm

</F>

 

[Hendrik van Rooyen]

The problem with linux kernel limits are, that they won't work really good
on MacOSX and Windows... OTOH the idea is the right one, but the effect can
be achieved inside of Python. Since Python does byte compile the code and
the interpreter evaluates each byte code token in one evaluation step. The
interpreter could be extended for such usecases to count and limit the
number of evaluation steps allowed for untrusted script or methods in
untrusted script as well as to limit the recursion depth or memory to be
allocated. All those limits are managed by the interpreter for script code
and hence can be limited for untrusted code by the interpreter. This also
does not really make DoS impossible (what about C extensions? - maybe
restricting "import"?). - As I said before in this thread, making a sandbox
really secure is a hard job, and may need some serious changes in the
Python interpreter, but AFAIK from Tcl, it is possible - and would be nice
to have.

I seem to recall previous discussion on this group about a thing called the
bastion module,
and that it was deprecated. Not sure if it has any relevance.

- Hendrik

 

[Steve Holden]

I seem to recall previous discussion on this group about a thing called the
bastion module,
and that it was deprecated. Not sure if it has any relevance.

Anyone with an interest in secure Python should take a look at what
Brett Cannon is doing in his postgraduate work. There have been some
discussions on the python-dev list.

regards
Steve

 

[Hendrik van Rooyen]

stupidity...

sorry about this - the message was stuck in my outbox for some reason, and I hit
the send key multiple times, not noticing that it was in fact being sent...

- Hendrik

 

[Stephan Kuhagen]

Anyone with an interest in secure Python should take a look at what
Brett Cannon is doing in his postgraduate work. There have been some
discussions on the python-dev list.

Can you some links to his work, the discussions or some other starting
point?

Stephan

 

[gene tani]

Can you some links to his work, the discussions or some other starting
point?

ok, here's how you can google python-dev. cut/paste into the box

"site:mail.python.org/pipermail/python-dev/ brett cannon sandbox"