Sandboxes
42
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...overkill; 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
> 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?
Yes. There have been numerous discussions about this, and there are so
many different ways to overcome such imposed limitations - it won't work.
>
> 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.
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
> 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?
Yes.
> 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).
If they are malicious, this is asking for trouble.
> 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.
No, that's not enough.
> 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?
Yes. It's even difficult with Java and Javascript, which were designed
to have such security.
Raymond Hettinger
> 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).
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
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;
PublishedInterface.Drawline(x,y, x+r*sin(i), y+r*cos(i),color)
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
> I want the 'worst case' a malicious script to be able to accompish to be
> a program crash or hang.
You should not rely on Python to provide any kind of security from
malicious users who can run Python scripts.
Leif K-Brooks
> I was wondering if it would be effective to pre-parse incoming scripts
> and reject those containing "import"?
getattr(__builtins__, '__imp' + 'ort__')('dangerousmodule')
42
eur...@ecritters.biz says...
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
> Thoughts? Still gaping holes?
Certainly. And rather than rehash them all here, I'm going to suggest
you check the comp.lang.python 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
says...
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
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.
Magnus Lycka
> 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 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
nos...@nospam.nospam says...
> 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.
Except that linking from the .net framework to jpython doesn't seem to
be as transparent. :/
-dave
Peter Hansen
> 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?
"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
> 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.
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 SecurityPermissionFlag, PermissionSet, SetAppDomainPolicy...
http://www.gamedev.net/community/forums/topic.asp?topic_id=264462&whichpage=1�
And here are docs on using boo as an embedded scripting language:
http://boo.codehaus.org/Boo+as+an+embedded+scripting+language
42
says...
I was planning on "sanitizing" the language instead of relying on rexec
and bastion so issues with them shouldn't be relevant.
And I'd already covered that the sanitized language would not have eval
and exec along with a dozen or so other builtin keywords/commands (which
I listed in a previous post) would not be allowed in scripts... the pre-
parser will simply reject any script containing them before running it.
If eval and exec (and others) simply aren't allowed in the scripts; then
the 'sneaky' things they might do aren't an issue.
I'm curious about the 'other' stuff that was alluded to, that could
still occur in a python with all its __import__, import, exec, eval, and
various reflection/metadata builtins prohibited (e.g. getattr)...
regards
-Dave
42
I was also looking at IronPython 0.9 and it might do longer term; I
don't need a lot of 'complicated' functionality so its alpha status
might not even really be a problem. But its targeted at .net2 beta.
I did bump into boo, but I'd never heard of it... I was hoping to use a
fairly mainstream language. I guess I should look a little harder at
boo.
Peter Hansen
> I was planning on "sanitizing" the language instead of relying on rexec
> and bastion so issues with them shouldn't be relevant.
I think in dealing with security, deciding what might be relevant before
you fully understand the problem is somewhat premature... but it's your
neck. :-)
> I'm curious about the 'other' stuff that was alluded to, that could
> still occur in a python with all its __import__, import, exec, eval, and
> various reflection/metadata builtins prohibited (e.g. getattr)...
Okay, but are you saying that combining those keywords with "security"
when searching comp.lang.python in Google Groups produced no useful
results? When I do it, I generally get to threads where somebody rushes
in with suggestions about how to add security where the core Python
people fear to tread (so to speak), and after a short period of back and
forth where each idea is quickly shot down, the thread sort of dies out
as (I suspect) the OP realizes the problems are fundamental and probably
can't be fixed without changes to the Python core itself, or at least
can't be fixed *with confidence* without a thorough security audit which
so far nobody has valued enough to actually do.
-Peter
42
says...
> 42 wrote:
> > I was planning on "sanitizing" the language instead of relying on rexec
> > and bastion so issues with them shouldn't be relevant.
>
> I think in dealing with security, deciding what might be relevant before
> you fully understand the problem is somewhat premature...
True enough, but I don't think in this case it applies.
Its ok to rule as irrelevant the various security problems with various
locking solutions for your front door when the proposed solution is to
simply brick the door over, removing it entirely.
> > I'm curious about the 'other' stuff that was alluded to, that could
> > still occur in a python with all its __import__, import, exec, eval, and
> > various reflection/metadata builtins prohibited (e.g. getattr)...
>
> Okay, but are you saying that combining those keywords with "security"
> when searching comp.lang.python in Google Groups produced no useful
> results?
I couldn't say that. I will say that none of the links I clicked on
revealed an attack that could bootsrap without the functions I proposed
'removing'.
> When I do it, I generally get to threads where somebody rushes
> in with suggestions about how to add security where the core Python
> people fear to tread (so to speak), and after a short period of back and
> forth where each idea is quickly shot down, the thread sort of dies out
> as (I suspect) the OP realizes the problems are fundamental and probably
> can't be fixed without changes to the Python core itself, or at least
> can't be fixed *with confidence* without a thorough security audit which
> so far nobody has valued enough to actually do.
Difference being that all the threads I read are trying to 'put full
python in sandbox' whereas I'd proposed literally hacking out chunks of
the language.
FWIW I've already given up on making python secure. I agree that odds
are extremely high that I've missed something. I'm just curious to see
what one of the holes I left is, preferably without wading through
hundreds of pages :)
Leif K-Brooks
> FWIW I've already given up on making python secure. I agree that odds
> are extremely high that I've missed something. I'm just curious to see
> what one of the holes I left is, preferably without wading through
> hundreds of pages :)
f = [x for x in [].__class__.__bases__[0].__subclasses__() if
x.__name__=='file'][0]
f('/path/to/important/file', 'w').close()
42
eur...@ecritters.biz says...
Thanks.
Still it clearly falls within the the scope of what I wanted to remove:
the built in reflection/metadata functions. I just didn't read enough of
the language spec to know there were more of them hidden here and there
than what were listed in keywords and built-in functions.
But they are a finite set. Evidently I'm not the one to do it, but
someone who knew python better, could probably enumerate the reflection
stuff more effectively than me.
I already gave up, but I don't think its a dead concept.
Diez B. Roggisch
> 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;
> PublishedInterface.Drawline(x,y, x+r*sin(i), y+r*cos(i),color)
> i++
> end while
>
> I want the 'worst case' a malicious script to be able to accompish to be
> a program crash or hang.
The you migth want to think about not criplling the language, but the
library - I'm not sure what has to be done to do that, but maybe these
lines of thought help more - the "usual" thing for restricted execution
was to provide it inside a otherwise fully working interpreter (like
ZOPE). But I might be mistaken.
Diez