Restricted Execution of untrusted code

[Emanuele D'Arrigo]

I noticed that this issue has been discussed in this newsgroup
periodically over the years and I seem to understand that -
comprehensive- safe/restricted execution of untrusted code in python
is currently quite hard to achieve.

What if the safety requirements are a little relaxed though? All I'd
want to prevent is for the code opening/damaging files, formatting
drives or similarly catastrophic exploits. I'm not particularly
concerned if the application freeze or crashes. Nor if the
application's objects are inspected and exploited. All I want is to
make sure that if somebody uses my application plus a third party
plugin for it, the worst that can happen is that they can't use my
application with that plugin.

Is that feasible?

Thanks for your help!

Manu

[Aaron Brady]

On Oct 30, 6:35*am, "Emanuele D'Arrigo" <[e-mail]:

I noticed that this issue has been discussed in this newsgroup
periodically over the years and I seem to understand that -
comprehensive- safe/restricted execution of untrusted code in python
is currently quite hard to achieve.

What if the safety requirements are a little relaxed though? All I'd
want to prevent is for the code opening/damaging files, formatting
drives or similarly catastrophic exploits. I'm not particularly
concerned if the application freeze or crashes. Nor if the
application's objects are inspected and exploited. All I want is to
make sure that if somebody uses my application plus a third party
plugin for it, the worst that can happen is that they can't use my
application with that plugin.

Is that feasible?

Thanks for your help!

Manu

Hi. One opinion is that you could do it with a custom Python
installation, removing or restricting the import statement, removing
or restricting the os module, the file type, etc. Here is some
problematic code:

>>cust= (1).__class__.__bases__[0].__subclasses__()
[ x for x in cust if x.__name__== 'file' ]

[<type 'file'>]

The foreign code can get to the 'file' type. If you don't have it,
that's not a problem.

Otherwise, you might be able to remove access to it by modifying
however it is the 'cust' list is obtained. Perhaps you can use the
technique that's used to change the value of integers. Keep us
posted. Does this give you any ideas?

[Aaron Brady]

On Oct 30, 3:50*pm, Aaron Brady <[e-mail]:

On Oct 30, 6:35*am, "Emanuele D'Arrigo" <[e-mail]:

I noticed that this issue has been discussed in this newsgroup
periodically over the years and I seem to understand that -
comprehensive- safe/restricted execution of untrusted code in python
is currently quite hard to achieve.

What if the safety requirements are a little relaxed though? All I'd
want to prevent is for the code opening/damaging files, formatting
drives or similarly catastrophic exploits. I'm not particularly
concerned if the application freeze or crashes. Nor if the
application's objects are inspected and exploited. All I want is to
make sure that if somebody uses my application plus a third party
plugin for it, the worst that can happen is that they can't use my
application with that plugin.

Is that feasible?

Thanks for your help!

Manu

Hi. *One opinion is that you could do it with a custom Python
installation, removing or restricting the import statement, removing
or restricting the os module, the file type, etc. *Here is some
problematic code:

>cust= (1).__class__.__bases__[0].__subclasses__()
[ x for x in cust if x.__name__== 'file' ]

[<type 'file'>]

The foreign code can get to the 'file' type. *If you don't have it,
that's not a problem.

Otherwise, you might be able to remove access to it by modifying
however it is the 'cust' list is obtained. *Perhaps you can use the
technique that's used to change the value of integers. *Keep us
posted. *Does this give you any ideas?

The hackery I was referring to makes a cut into this particular
vulnerability. It empties the 'tp_subclasses' field of 'object', but
who knows how else one could get to it?

from _ctypes import _cast_addr
_data_cast= c.PYFUNCTYPE(c.py_object, c.py_object, c.py_object,
c.py_object)(_cast_addr)
x= _data_cast( object, None, c.c_void_p )
y= _typeobject.from_address( x.value )
y.tp_subclasses= 0 #<--- dirty work done here (embarassed)
assert (1).__class__.__bases__[0].__subclasses__()== [] #<--- (!!!)

Though, oddly enough,

_data_cast( object, None, _typeobject )

doesn't work.

[Emanuele D'Arrigo]

On Oct 30, 8:50*pm, Aaron Brady <[e-mail]:

Otherwise, you might be able to remove access to it by modifying
however it is the 'cust' list is obtained. *Perhaps you can use the
technique that's used to change the value of integers. *Keep us
posted. *Does this give you any ideas?

Nope! Not really! These are python quirks beyond my current level of
knowledge! <sigh=(

I suspect I'll simply drop from my application the possibility for
users to write their own plugins. Or I'll simply rely on the
unlikelihood of somebody taking the opportunity to do something
malicious. After all there are plenty of applications with an open-
architecture that leave the responsibility in the hands of the plugin
developers and the plugins users.

Thanks anyway!

Manu

[Lawrence D'Oliveiro]

In message
<b4**********************************@m3g2000hsc.g ooglegroups.com>,
Emanuele D'Arrigo wrote:

I noticed that this issue has been discussed in this newsgroup
periodically over the years and I seem to understand that -
comprehensive- safe/restricted execution of untrusted code in python

I think the most reliable solution is to take advantage of a level in the
system that already has to provide protection against malicious code: use a
chroot jail. Or run a complete virtualized machine with its own OS
installation. Then the code is free to do what it wants, it simply won't
see anything sensitive that it could compromise.

[Emanuele D'Arrigo]

On Nov 1, 12:44*am, Lawrence D'Oliveiro wrote:

I think the most reliable solution is to take advantage of a level in the
system that already has to provide protection against malicious code: usea
chroot jail. Or run a complete virtualized machine with its own OS
installation. Then the code is free to do what it wants, it simply won't
see anything sensitive that it could compromise.

[sigh] That sound a little overkill for a small application. I guess
somebody should come up with a sandbox version of python, that can be
executed, say, with a directory provided as a parameter and all the os
calls are never made above that level.

Manu

[Ben Finney]

"Emanuele D'Arrigo" <ma****@gmail.comwrites:

On Nov 1, 12:44Â*am, Lawrence D'Oliveiro wrote:

I think the most reliable solution is to take advantage of a level
in the system that already has to provide protection against
malicious code: use a chroot jail.

[…]

>
[sigh] That sound a little overkill for a small application. I guess
somebody should come up with a sandbox version of python, that can
be executed, say, with a directory provided as a parameter and all
the os calls are never made above that level.

That's exactly what a chroot jail *is*, except you don't need to wait
for a special version of Python. You don't gain anything with the
appropach you describe that you wouldn't have by setting up a chroot
jail using the existing functionality for that purpose.

--
\ “You can't have everything; where would you put it?� —Steven |
`\ Wright |
_o__) |
Ben Finney

[Roy Smith]

In article <87************@benfinney.id.au>,
Ben Finney <bi****************@benfinney.id.auwrote:

"Emanuele D'Arrigo" <ma****@gmail.comwrites:

On Nov 1, 12:44Â*am, Lawrence D'Oliveiro wrote:

I think the most reliable solution is to take advantage of a level
in the system that already has to provide protection against
malicious code: use a chroot jail.

[…]

[sigh] That sound a little overkill for a small application. I guess
somebody should come up with a sandbox version of python, that can
be executed, say, with a directory provided as a parameter and all
the os calls are never made above that level.

That's exactly what a chroot jail *is*, except you don't need to wait
for a special version of Python.

What's more, the kernel is in a much better position to understand how a
pathname maps to a location in the physical file system than any
application could. Should Python attempt to understand what it means to
traverse a symlink? A mount point?

[Emanuele D'Arrigo]

Thanks to those who replied and sorry for not having replied sooner.

Ok, got the message: chroot jail. I understand chroot is available for
unix-like OS as a kernel-provided facility. If I was developing for,
say, Linux or maybe even MacOSX, it might even be easy. My target OS
however are XP and Vista. I did find chroot-like features in various
virtualization platforms for those OS, but it would definitely be
overkill to request the user that he installs a virtualization
software to run a small application. I was reading this page

http://wiki.python.org/moin/How%20ca...i.e.%20Sandbox)

and it seems to me my only two options are pypy-c and Jython. Would
you agree or are there more avenues to explore given my OS
requirements?

Manu

[Ben Finney]

"Emanuele D'Arrigo" <ma****@gmail.comwrites:

My target OS however are XP and Vista. I did find chroot-like
features in various virtualization platforms for those OS, but it
would definitely be overkill to request the user that he installs a
virtualization software to run a small application.

If you're trying to retro-fit secure execution of untrusted code onto
those operating systems, you have a much larger set of problems than
trying to choose the right Python implementation. Good luck.

--
\ “If I haven't seen as far as others, it is because giants were |
`\ standing on my shoulders.� —Hal Abelson |
_o__) |
Ben Finney