Sandboxes
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...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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Sandboxes
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says... > > 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. 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? 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, -- http://mail.python.org/mailman/listinfo/python-list
Re: Sandboxes
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> 42 wrote:
> > I was wondering if it would be effective to pre-parse incoming scripts
> > and reject those containing "import"?
>
> getattr(__builtins__, '__imp' + 'ort__')('dangerousmodule')
>
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: Sandboxes
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says... > 42 wrote: > > 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 > 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Sandboxes
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Sandboxes
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says... > 42 wrote: > > 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. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Sandboxes
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says... > 42 wrote: > > 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 > 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Sandboxes
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 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 :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Sandboxes
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> 42 wrote:
> > 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()
>
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.
--
http://mail.python.org/mailman/listinfo/python-list
Re: transfer data from one machine to another
On Sunday 04 March 2007 13:56, bahoo wrote: > I have ssh access to two linux machines (both WITHOUT root account), > and I'd like to copy data from one to another. > Since the directory structure is different, I want to specify in a > script (ideally in python, because that's what I want to learn) what > to copy over like this: > > source: /home/john/folderA > destination: /home/smith/folderB > > I'm a newbie on linux and ssh networking and python, so your > suggestions are welcome! A small working example would be appreciated! Try rsync, if you need a second run, it will only copy what has been modified in the source. rsync -var -e ssh /home/john/folderA [EMAIL PROTECTED]:/home/smith/folderB Should be enough. Remove 'v' for less verbose operation. -- Research is what I'm doing, when I don't know what I'm doing. (von Braun) -- http://mail.python.org/mailman/listinfo/python-list
Making a simple script standalone
Hi, I'm new to this group. I've tried finding my answer in existing messages, but no such luck. What I want to do is to compile/bundle/prepare/whatever_term a simple Python script for deployment on a Windows machine. Installing Python itself on that machine, is not an option. Ideally I would like to obtain a single executable file, but a script+runtime is acceptable. There is nothing graphical, nothing fancy about the script. The only imports are: os, stat, string and time. Any suggestions on an - easy and clear - path to follow ? -- Research is what I'm doing, when I don't know what I'm doing. (von Braun) -- http://mail.python.org/mailman/listinfo/python-list
Re: Making a simple script standalone
On Wednesday 17 January 2007 03:33, Gabriel Genellina wrote: > At Tuesday 16/1/2007 19:49, Rikishi 42 wrote: > >>What I want to do is to compile/bundle/prepare/whatever_term a simple >>Python script for deployment on a Windows machine. Installing Python >>itself on that machine, is not an option. Ideally I would like to obtain >>a single executable file, but a script+runtime is acceptable. > > distutils + py2exe Tried that, just after asking here. A bit messy (poor docs) and a very bloated result. Thanks for the answer, anyway. -- Research is what I'm doing, when I don't know what I'm doing. (von Braun) -- http://mail.python.org/mailman/listinfo/python-list
Re: Making a simple script standalone
On Wednesday 17 January 2007 00:22, James Stroud wrote: >> There is nothing graphical, nothing fancy about the script. >> The only imports are: os, stat, string and time. >> >> Any suggestions on an - easy and clear - path to follow ? > > > pyinstaller + innosetup. I will look into it, thanks! Hope it's not as heavy as with py2exe... -- Research is what I'm doing, when I don't know what I'm doing. (von Braun) -- http://mail.python.org/mailman/listinfo/python-list
Re: Making a simple script standalone
On Wednesday 17 January 2007 00:48, Larry Bates wrote: >> There is nothing graphical, nothing fancy about the script. >> The only imports are: os, stat, string and time. >> >> Any suggestions on an - easy and clear - path to follow ? > I use py2exe and inno installer. Works great. Thanks, I will look into it. Hope it's not as heavy as py2exe... -- Research is what I'm doing, when I don't know what I'm doing. (von Braun) -- http://mail.python.org/mailman/listinfo/python-list
Re: Making a simple script standalone
On Thursday 18 January 2007 10:13, robert wrote: > stay with py23 for "a script" (and more) and make <700kB > independent distros - UPX and 7zip involved: > > http://groups.google.com/group/comp.lang.python/msg/edf469a1b3dc3802 Thanks, that might be an option. But I might just convince the person to let me install Python. :-( -- Research is what I'm doing, when I don't know what I'm doing. (von Braun) -- http://mail.python.org/mailman/listinfo/python-list
