Embedding a restricted python interpreter

Craig Ringer craig at postnewspapers.com.au
Fri Jan 7 00:17:31 EST 2005


On Thu, 2005-01-06 at 23:05, Peter Maas wrote:
> Craig Ringer schrieb:

> It would certainly be difficult to track all harmful code constructs.
> But AFAIK the idea of a sandbox is not to look at the offending code
> but to protect the offended objects: files, databases, URLs, sockets
> etc. and to raise a security exception when some code tries to offend
> them.

That's a good point. I'm not sure it's really all that different in the
end though, because in order to control access to those resources you
have to restrict what the program can do.

It'd probably be valid to implement a restricted mode at CPython level
(in my still-quite-new-to-the-Python/C-API view) by checking at the
"exit points" for important resources such as files, etc. I guess that's
getting into talk of something like the Java sandbox, though - something
Java proved is far from trivial to implement. Of course, CPython is just
a /tad/ smaller than Java ;-) .

Personally, I'd be worried about the amount of time it'd take and the
difficulty of getting it right. One wouldn't want to impart a false
sense of security.

My original point, though, was that I don't think you can use the
standard interpreter to create a restricted environment that will be
both useful and even vaguely secure. I'd be absolutely delighted if
someone could prove me wrong.

> Python is a very well designed language but progress is made by
> criticism not by satisfaction ;)

Heh, I'm hardly complacent... I run into quite enough problems,
especially with embedding and with the C API. Maybe one day I'll have
the knowledge - and the time - to have a chance at tackling them.

I'd love a restricted mode - it'd be great. I'm just not very optimistic
about its practicality.

--
Craig Ringer




More information about the Python-list mailing list