Sandboxes

[42]

Hi,

I'm extremely new to python, and am looking at using it as an embedded
script engine in a dotnet project I'm working on. I'm currently playing
with the "Python for Net" (http://www.zope.org/Members/Brian/PythonNet)
stuff, and it seems to work well.

Googling for information on securing Python in a "sandbox" seems
indicate that there are some built in features, but they aren't really
trustworthy. Is that correct?

For my purposes, I really just want to let users run in a sandbox, with
access to only the language, manipuate a few published objects in the
application (and perhaps give them some string and math libraries if
applicable).

I was wondering if it would be effective to pre-parse incoming scripts
and reject those containing "import"? I'd also have the application
inject the (short) list of trusted imports to the script before passing
it to the interpreter.

In theory I'm hoping this would mean script writers would have access to
the stuff they need and no way to add in anything else.

Would this sufficient? Are there any drawbacks or giant gaping holes?
I'm anticipating that I'd also need to block 'exec' and 'eval' to
prevent an import from being obfuscated past the pre-parse.

Or is this a hopeless cause?

Finally, either way, would anyone recommend a different script engine
that might be more suitable for what I'm trying to accomplish that I
might not have looked at. I don't need much; it needs to work with C#,
and be able to easily interact with 'published' interface. I'd also like
to leverage a "popular" language instead of something obscure.

I also looked at Javascript, but couldn't find a way to embed an
interpreter into a C# app. There's some CodeDom stuff with JScript, but
that seemed backwards...ove rkill; I don't really want to compile
temporary assemblies for hundreds of 2 and 3 line scripts... and the VSA
stuff has been marked deprecated with no apparent successor... seems
like I jumped into this at precisely the wrong time. :)

Any thoughts, insights, or comments welcome. Forgive my lack of Python
savvy... I've only been playing with it for a few hours now; after
bumping into the "python for net" link.

-regards,
Dave

[Diez B. Roggisch]

Re: Sandboxes

> Would this sufficient? Are there any drawbacks or giant gaping holes?[color=blue]
> I'm anticipating that I'd also need to block 'exec' and 'eval' to
> prevent an import from being obfuscated past the pre-parse.
>
> Or is this a hopeless cause?[/color]

Yes. There have been numerous discussions about this, and there are so
many different ways to overcome such imposed limitations - it won't work.
[color=blue]
>
> Finally, either way, would anyone recommend a different script engine
> that might be more suitable for what I'm trying to accomplish that I
> might not have looked at. I don't need much; it needs to work with C#,
> and be able to easily interact with 'published' interface. I'd also like
> to leverage a "popular" language instead of something obscure.[/color]

Maybe LUA? I only heard that it's well suited for such tasks.

The overall question for me is: Why crippled acess at all? What do you
fear your users could do that harms you or others? There are of coures
valid reasons, I don't question that generally. E.g. applets and the
like. So what is the actual usecase?

Regards,

Diez

[Paul Rubin]

Re: Sandboxes

42 <nospam@nospam. com> writes:[color=blue]
> Googling for information on securing Python in a "sandbox" seems
> indicate that there are some built in features, but they aren't really
> trustworthy. Is that correct?[/color]

Yes.
[color=blue]
> For my purposes, I really just want to let users run in a sandbox, with
> access to only the language, manipuate a few published objects in the
> application (and perhaps give them some string and math libraries if
> applicable).[/color]

If they are malicious, this is asking for trouble.
[color=blue]
> I was wondering if it would be effective to pre-parse incoming scripts
> and reject those containing "import"? I'd also have the application
> inject the (short) list of trusted imports to the script before passing
> it to the interpreter.[/color]

No, that's not enough.
[color=blue]
> Would this sufficient? Are there any drawbacks or giant gaping holes?
> I'm anticipating that I'd also need to block 'exec' and 'eval' to
> prevent an import from being obfuscated past the pre-parse.
>
> Or is this a hopeless cause?[/color]

Yes. It's even difficult with Java and Javascript, which were designed
to have such security.

[Raymond Hettinger]

Re: Sandboxes

> Googling for information on securing Python in a "sandbox" seems[color=blue]
> indicate that there are some built in features, but they aren't really
> trustworthy. Is that correct?
>
> For my purposes, I really just want to let users run in a sandbox, with
> access to only the language, manipuate a few published objects in the
> application (and perhaps give them some string and math libraries if
> applicable).[/color]

It depends on your desired level of security. If you want to make it
hacker-proof, it is a lost cause. If you're creating an environment
that just offers protection against accidents, that can be done.

[42]

Re: Sandboxes

In article <3mog8aF17j66oU 1@uni-berlin.de>, deets@nospam.we b.de says...[color=blue][color=green]
> > Would this sufficient? Are there any drawbacks or giant gaping holes?
> > I'm anticipating that I'd also need to block 'exec' and 'eval' to
> > prevent an import from being obfuscated past the pre-parse.
> >
> > Or is this a hopeless cause?[/color]
>
> Yes. There have been numerous discussions about this, and there are so
> many different ways to overcome such imposed limitations - it won't work.
>[color=green]
> >
> > Finally, either way, would anyone recommend a different script engine
> > that might be more suitable for what I'm trying to accomplish that I
> > might not have looked at. I don't need much; it needs to work with C#,
> > and be able to easily interact with 'published' interface. I'd also like
> > to leverage a "popular" language instead of something obscure.[/color]
>
> Maybe LUA? I only heard that it's well suited for such tasks.
>
> The overall question for me is: Why crippled acess at all? What do you
> fear your users could do that harms you or others? There are of coures
> valid reasons, I don't question that generally. E.g. applets and the
> like. So what is the actual usecase?[/color]

Basically I just want a language to allow users to write macros,
interact with application objects, set property values, sequence
operations, supporting loops and branch logic and so forth.

Something along the lines of a drawing program that allowed uers to
write and/or download scripts to perform batches of arbitrary
(parameterized) operations.

e.g.scripts along the lines of:

function drawfan(x,y,r)
i=45
while (i<90)
if i.isEven()
color=red;
else
color=blue;
PublishedInterf ace.Drawline(x, y, x+r*sin(i), y+r*cos(i),colo r)
i++
end while

I want the 'worst case' a malicious script to be able to accompish to be
a program crash or hang.

regards,

[Paul Rubin]

Re: Sandboxes

42 <nospam@nospam. com> writes:[color=blue]
> I want the 'worst case' a malicious script to be able to accompish to be
> a program crash or hang.[/color]

You should not rely on Python to provide any kind of security from
malicious users who can run Python scripts.

[Leif K-Brooks]

Re: Sandboxes

42 wrote:[color=blue]
> I was wondering if it would be effective to pre-parse incoming scripts
> and reject those containing "import"?[/color]

getattr(__built ins__, '__imp' + 'ort__')('dange rousmodule')

[42]

Re: Sandboxes

In article <tpLNe.187$hn4. 34901@newshog.n ewsread.com>,
eurleif@ecritte rs.biz says...[color=blue]
> 42 wrote:[color=green]
> > I was wondering if it would be effective to pre-parse incoming scripts
> > and reject those containing "import"?[/color]
>
> getattr(__built ins__, '__imp' + 'ort__')('dange rousmodule')
>[/color]

See that's sort of thing I'm talking about. :)

Earlier I mentioned that I figured I'd be ok to pre-parse the script to
sanitize the langauge a bit.

There are what 30 odd built in functions? And a dozen or so keywords?

Basically if I turn off anything that deals with 'executable code',
'meta data', or 'reflection' I'm hoping I'd be in the clear.

e.g.: looking at the built in function list these would be suspect...
probably not all of them are dangerous, but I beleive I could get by
without any of them:

first the keywords:
exec, import

and then the built in functions:

type, super, setattr, reload, property, open, locals, issubclass,
isinstance, hasattr, globals, getattr, file, execfile, eval, dir, dict,
delattr, compile, classmethod, callable, __import__

I'd also filter:

raw_input, input, and help (as they don't make sense in the
application) context anyway.

Sure I might be seriously crippling the power of python by doing this,
but that's rather the point :), and it should be fine for my purposes.

Thoughts? Still gaping holes?

thanks in advance,
Dave

[Peter Hansen]

Re: Sandboxes

42 wrote:[color=blue]
> Thoughts? Still gaping holes?[/color]

Certainly. And rather than rehash them all here, I'm going to suggest
you check the comp.lang.pytho n archives for any of the many past
discussions about this before you spend too much time thinking
(repeatedly) that you've nailed that one last hole only to have somebody
point out yet another way around it.

-Peter

[42]

Re: Sandboxes

In article <38SdnUU_VbGFkZ TeRVn-qA@powergate.ca >, peter@engcorp.c om
says...[color=blue]
> 42 wrote:[color=green]
> > Thoughts? Still gaping holes?[/color]
>
> Certainly. And rather than rehash them all here, I'm going to suggest
> you check the comp.lang.pytho n archives for any of the many past
> discussions about this before you spend too much time thinking
> (repeatedly) that you've nailed that one last hole only to have somebody
> point out yet another way around it.
>
> -Peter
>[/color]

Fair enough. I'm more or less ready to 'give up' on this fantasy of
python in a sandbox. I'll either use something else, or just accept the
risk. :)

But for what its worth, I *am* curious what sorts of holes persist. I
did try googling the archives, but with no idea what I'm looking for --
python security brings up a mess of unrelated issues... Python in
Apache, rexec/bastion stuff, xss, issues with infinite loops and many
other 'security' issues that might be relevant to someone running python
on a web server where you have to be concerned about DOS but not of any
concern to me... and so on and so forth.

Can you, or someone, at least give me a few keywords I should be looking
for that will bring matches for the sorts of attachs you've hinted at?

Mostly just to satisfy my curiousity.

-regards,
Dave

[Steve Jorgensen]

Re: Sandboxes

Clearly, Pyton does not directly offer any kind of useful security sandbox
capability, but since Java does, I suppose JPython is an option. I know there
are a lot of downsides to JPython, but it should be a genuine solution to the
sandbox problem.

On Sat, 20 Aug 2005 10:21:06 GMT, 42 <nospam@nospam. com> wrote:
[color=blue]
>Hi,
>
>I'm extremely new to python, and am looking at using it as an embedded
>script engine in a dotnet project I'm working on. I'm currently playing
>with the "Python for Net" (http://www.zope.org/Members/Brian/PythonNet)
>stuff, and it seems to work well.
>
>Googling for information on securing Python in a "sandbox" seems
>indicate that there are some built in features, but they aren't really
>trustworthy. Is that correct?
>
>For my purposes, I really just want to let users run in a sandbox, with
>access to only the language, manipuate a few published objects in the
>application (and perhaps give them some string and math libraries if
>applicable).
>
>I was wondering if it would be effective to pre-parse incoming scripts
>and reject those containing "import"? I'd also have the application
>inject the (short) list of trusted imports to the script before passing
>it to the interpreter.
>
>In theory I'm hoping this would mean script writers would have access to
>the stuff they need and no way to add in anything else.
>
>Would this sufficient? Are there any drawbacks or giant gaping holes?
>I'm anticipating that I'd also need to block 'exec' and 'eval' to
>prevent an import from being obfuscated past the pre-parse.
>
>Or is this a hopeless cause?
>
>Finally, either way, would anyone recommend a different script engine
>that might be more suitable for what I'm trying to accomplish that I
>might not have looked at. I don't need much; it needs to work with C#,
>and be able to easily interact with 'published' interface. I'd also like
>to leverage a "popular" language instead of something obscure.
>
>I also looked at Javascript, but couldn't find a way to embed an
>interpreter into a C# app. There's some CodeDom stuff with JScript, but
>that seemed backwards...ove rkill; I don't really want to compile
>temporary assemblies for hundreds of 2 and 3 line scripts... and the VSA
>stuff has been marked deprecated with no apparent successor... seems
>like I jumped into this at precisely the wrong time. :)
>
>Any thoughts, insights, or comments welcome. Forgive my lack of Python
>savvy... I've only been playing with it for a few hours now; after
>bumping into the "python for net" link.
>
>-regards,
>Dave[/color]

[Magnus Lycka]

Re: Sandboxes

42 wrote:[color=blue]
> Fair enough. I'm more or less ready to 'give up' on this fantasy of
> python in a sandbox. I'll either use something else, or just accept the
> risk. :)[/color]

But is the scripting language interpreter the right place to put
this? After all, any most languages would allow you to write
something like an infinite loop, which might hog resources unless
there is "something" outside the script that manages resources in
such a way that this is not a problem.

I've said this before: It's seems to me that this sandboxing should
be done by the operating system. If the script runs in something
like a chrooted environment, or with very restricted user permissions,
it's difficult to do a lot of damage. E.g. if it runs as a user with
no rights to execute, read or write files except those explicitly
needed to get the scripts running, you're no worse off than if you
allow the same user to log on to the machine with such limited
ability.

Right? Or have I missed something significant here?

[42]

Re: Sandboxes

In article <diqig11n1e294c sm33se5j1f3r9ur dlbh7@4ax.com>,
nospam@nospam.n ospam says...[color=blue]
> Clearly, Pyton does not directly offer any kind of useful security sandbox
> capability, but since Java does, I suppose JPython is an option. I know there
> are a lot of downsides to JPython, but it should be a genuine solution to the
> sandbox problem.[/color]

Except that linking from the .net framework to jpython doesn't seem to
be as transparent. :/

-dave

[Peter Hansen]

Re: Sandboxes

42 wrote:[color=blue]
> But for what its worth, I *am* curious what sorts of holes persist. I
> did try googling the archives, but with no idea what I'm looking for --
> python security brings up a mess of unrelated issues... Python in
> Apache, rexec/bastion stuff, xss, issues with infinite loops and many
> other 'security' issues that might be relevant to someone running python
> on a web server where you have to be concerned about DOS but not of any
> concern to me... and so on and so forth.
>
> Can you, or someone, at least give me a few keywords I should be looking
> for that will bring matches for the sorts of attachs you've hinted at?[/color]

"security" plus just about anything involved, such as rexec, bastion,
eval, and exec, appear to bring forth reams of relevant info. Try
sorting by date instead of Google's questionable "relevance" to make
sure you're getting some of the more recent discussions too.

-Peter

[D H]

Re: Sandboxes

42 wrote:[color=blue]
> Or is this a hopeless cause?
>
> Finally, either way, would anyone recommend a different script engine
> that might be more suitable for what I'm trying to accomplish that I
> might not have looked at. I don't need much; it needs to work with C#,
> and be able to easily interact with 'published' interface. I'd also like
> to leverage a "popular" language instead of something obscure.[/color]

You need a scripting language that is completely implemented in .NET
(i.e. "managed"). Try Boo: http://boo.codehaus.org/
And then from your C# host, use the .NET security API for restricting
what the script is allowed to do. See the example below, as well as
msdn docs on SecurityPermiss ionFlag, PermissionSet, SetAppDomainPol icy...
http://www.gamedev.net/community/for...age=1&#1620355
And here are docs on using boo as an embedded scripting language:

http://boo.codehaus.org/Boo+as+an+embedded+scripting+language