Embedding Python in Python

[Robey Holderith]

On Wed, 18 Aug 2004 20:33:09 +0000, JCM wrote:

> Robey Holderith <robey at slash_dev_slash_random.org> wrote:
>> On Wed, 18 Aug 2004 19:44:47 +0000, JCM wrote:
> ...
>>> I don't think it's as difficult as you think.  Your snippet of code
>>> would be rejected by the rules I suggested.  You'd also want to
>>> prohibit other builtins like compile, execfile, input, reload, vars,
>>> etc.
> 
>> I'm going to have to agree with Paul on this one.  I do not feel up to
>> the task of thinking of every possible variant of malicious code.  There
>> are far too many ways of writing the exact same thing.  I think it would
>> be much easier to write my own interpreter. 
> 
> Well it certainly isn't easier to write your own interpreter if you're
> talking about the effort you'd need to put into it.  And I'm not
> convinced it's that tricky to come up with a set of syntax rules to
> decide whether a piece of code is simple/safe enough to run.  It
> basically comes down to disallowing certain statements and certain
> identifiers.  Of course you'll end up rejecting a lot of code that
> isn't malicious.
> 
> If you're interested enough, I'll try to throw a safety-checker
> together.  You'd have to be pretty interested though (I'm lazy).


Don't do it on my behalf.  I started far too many projects doing something
similar before I realized that the only effective way to do security was
from the bottom up.  The problem looks something like this (assuming each
function has 10 places where it is implemented.

Level   |  Malicious Variation Count
-----------------------------------------
0       |    10^0
1       |    10^1
2       |    10^2
x       |    10^x

Suffice to say that in simple code... it is doable.  In a
mature interpreter... near impossible.

-Robey