Now that rexec is gone...

[Rainer Deyke]

Now that rexec is gone, is there any code or information available on
executing Python in a restricted environment? And before I roll my own
solution, exactly where the security holes in rexec anyway?

(I know one way of getting a restricted environment: butcher the Python
interpreter by removing everything that's even remotely dangerous, use
Python only for restricted execution, and do everything else in a C++
program that embeds the butchered Python interpreter. I'd like to avoid
doing that, for obvious reasons.)

 

[Terry Reedy]

Now that rexec is gone, is there any code or information available on
executing Python in a restricted environment? And before I roll my own
solution, exactly where the security holes in rexec anyway?

Suggest you google last year of c.l.py for 'rexec'. Also check out
py-dev summaries of last fall for discussion of why removed.

TJR

 

[Michael Hudson]

Now that rexec is gone, is there any code or information available on
executing Python in a restricted environment?

There was a thread on python-dev about Zope's version of rexec
(RestrictedPython?) which looked promising on casual inspection.

Cheers,
mwh

--

> It might get my attention if you'd spin around in your chair,
> spoke in tongues, and puked jets of green goblin goo.

I can arrange for this. ;-) -- Barry Warsaw & Fred Drake

 

[Alex Martelli]

Now that rexec is gone, is there any code or information available on
executing Python in a restricted environment? And before I roll my own
solution, exactly where the security holes in rexec anyway?

(I know one way of getting a restricted environment: butcher the Python
interpreter by removing everything that's even remotely dangerous, use
Python only for restricted execution, and do everything else in a C++
program that embeds the butchered Python interpreter. I'd like to avoid
doing that, for obvious reasons.)

Actually, such a "butchered" Python interpreter might be a fun and
useful project indeed. You would have to add programmable limits on
resource consumptions -- e.g., memory allocatable by the script,
time (CPU or maybe elapsed) usable thereby, etc. And you should rename
everything, say to use Qy instead of Py, so that a normal and a
butchered interpreter could easily be embedded in the same program.

Once the hard work of "butchering" is done, you might in fact quite
easily expose "the butchered interpreter" via an extension module for
Python proper -- no need to do "everything in C++", you'd just have two
separate Pythons, a full-function one and a seriously-hobbled one.

Not *QUITE* as good as running untrusted code in a separate "jail"'d
process, perhaps, but probably the closest you can come to that on
such environments as Windows. Note that the need to add resource
limitations is crucial (and was never addressed by rexec, making it
pretty useless to ward against denial-of-service kinds of attacks!).


Alex

 

[Rainer Deyke]

Actually, such a "butchered" Python interpreter might be a fun and
useful project indeed. You would have to add programmable limits on
resource consumptions -- e.g., memory allocatable by the script,
time (CPU or maybe elapsed) usable thereby, etc. And you should
rename everything, say to use Qy instead of Py, so that a normal and a
butchered interpreter could easily be embedded in the same program.

That might be a useful project, but it also sounds like a lot of work. I
don't think I'll be going that route.

As it turns out, I can solve my security problem in a different way
entirely: by confirming that any Python code I run is from a trusted source.
No need to run untrusted code at all.

 

[Rainer Deyke]

Suggest you google last year of c.l.py for 'rexec'. Also check out
py-dev summaries of last fall for discussion of why removed.

I see... It turns out that, short of modifying the Python interpreter, there
is no way to get real security. '"".__class__' gives access to 'str', 'str'
gives access to 'object', and 'object' gives access to 'file'.

 

[Erik Max Francis]

As it turns out, I can solve my security problem in a different way
entirely: by confirming that any Python code I run is from a trusted
source.
No need to run untrusted code at all.

Yes, that sounds like the most reasonable approach.

 

[Cameron Laird]

.
.
.

Actually, such a "butchered" Python interpreter might be a fun and
useful project indeed. You would have to add programmable limits on
resource consumptions -- e.g., memory allocatable by the script,
time (CPU or maybe elapsed) usable thereby, etc. And you should rename

Good instincts! Yes, some of the recent work in regard to
safe interpretation that I find most interesting focuses
on precisely this: resource management. That's as op-
posed to the rather static causal tracing where Java's
core security theoreticians have put their attention.
I know there are people working with Java who care about
resource management; I don't *think* their results are
showing up in the libraries Sun specifies.

Apt proxies for your "time" include lots of easy ones for
an introspective interpreter, such as number-of-bytecodes
processed. That's another reason this is likely to be
"fun and useful" for Python: it already builds in good
introspection.

Warm-up exercise: list resources of interest. You've
already mentioned (memory) space and time. Anything the
operating system has to conserve--channel handles, threads,
SysV semaphores, display contexts, color maps, physical
device references, ...--is a likely candidate. Another
refinement: the OS could provide higher-level support for
resources usually left in userland. It strikes me that
this could be valuable even outside its use in a restricted
interpreter. Pools of, for example, database connections
are the first example that comes to my mind.
.
.
.

Not *QUITE* as good as running untrusted code in a separate "jail"'d
process, perhaps, but probably the closest you can come to that on
such environments as Windows. Note that the need to add resource
limitations is crucial (and was never addressed by rexec, making it
pretty useless to ward against denial-of-service kinds of attacks!).

Worth repeating. Also, note that "jail" (or sandbox) is
not the only metaphor worth considering in this area.
Another is the positive one behind operating systems (I
need to figure out a one-word label for this): "zero-
based" provision of services for which one has been
authorized. This builds up, rather than down. Instead
of calculating how much is safe to put in the sandbox,
it makes the dual calculation of what building blocks
can safely be allowed the developer.
.
.
.

 

[Jacek Generowicz]

I see... It turns out that, short of modifying the Python interpreter, there
is no way to get real security. '"".__class__' gives access to 'str', 'str'
gives access to 'object', and 'object' gives access to 'file'.

A message-id, or similar, at this point, could save future googlers a
lot of time ...

 

[Gerrit Holl]

How do I check if a value is a number in Python?

One way is (x == type(1)) and (x == type(1.2)) and (x ==
type(2387482734274)) and ...

but this seems kludgy. Any better way?

Why do you want to do so? Maybe, it is better in your
case to just run the piece of code using the number, and
if it fails, it fails. However, if you must, you need to
do type(x) is type(1) and ... etc., or isinstance(x, int)
and isinstance(x, float), etc.

Gerrit.

 

[Jeff Epler]

First, whatever test you use, you should probably encapsulate it in a
function, so that if you need to update the definition you can do it at
one site instead of many:

def isnumeric(x):
return isinstance(x, (int, long, float))

You could have a registry of numeric types:

_numeric_types = ()
def register_numeric_type(t):
global _numeric_types
if t in _numeric_types: return
_numeric_types += (t,)

for value in (0, 0., 0l, 0j):
register_numeric_type(type(value))

def isnumeric(x):
return isinstance(x, _numeric_types)

Now, if someone wants to write a vector type, it merely needs to be
registered.

You could test that common numeric operations work:
def isnumeric(x):
try:
if x*1 == x and x+0 == x:
return 1
except TypeError:
pass
return 0

You could just run your code and let the eventual TypeError speak for
itself.. instead of
def f(x):
if not isnumeric(x): raise TypeError, "can't f() a %s" % type(x)
return x*x
just write
def f2(x):
return x*x
The difference in the quality of the error message is not large: Traceback (most recent call last):
File "<stdin>", line 1, in ?
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 2, in f2
TypeError: unsupported operand type(s) for *: 'str' and 'str'

Jeff

 

[Jean-S?bastien Bolduc]

How do I check if a value is a number in Python?

Why do you want to do so? Maybe, it is better in your
case to just run the piece of code using the number, and
if it fails, it fails. However, if you must, you need to
do type(x) is type(1) and ... etc., or isinstance(x, int)
and isinstance(x, float), etc.

I used to use the latter approach suggested by Gerrit, but I recently
found on the web an alternative, elegant approach that might work
(sorry, I don't recall where I found it!):

hasattr(x, '__int__')

If the "__int__" method is defined for "x", it is a number. This will
work for integer, long, float and complex types, as well as for custom
classes that emulate numeric types.

Regards,
JSeb

 

[Erik Max Francis]

I used to use the latter approach suggested by Gerrit, but I recently
found on the web an alternative, elegant approach that might work
(sorry, I don't recall where I found it!):

hasattr(x, '__int__')

If the "__int__" method is defined for "x", it is a number. This will
work for integer, long, float and complex types, as well as for custom
classes that emulate numeric types.

This is an insidiously bad idea, in my opinion. All having an __int__
method means is there is some _conversion_ from an instance to an int
type. It does not at all mean the custom instance spends most of its
life behaving as an integer.

 

[Aahz]

This is an insidiously bad idea, in my opinion. All having an __int__
method means is there is some _conversion_ from an instance to an int
type. It does not at all mean the custom instance spends most of its
life behaving as an integer.

Yup. There's been some talk of adding an __index___() method or
something to deal with that.