Sandboxes

[42]

Re: Sandboxes

In article <CtGdnQr23dpbdp TeRVn-2A@powergate.ca >, peter@engcorp.c om
says...[color=blue]
> 42 wrote:[color=green]
> > 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.[/color]

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]

Re: Sandboxes

In article <n7ednZxwhd8IbZ TeRVn-jA@comcast.com> , no@spam says...[color=blue]
> 42 wrote:[color=green]
> > 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+em...pting+language
>[/color]

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]

Re: Sandboxes

42 wrote:[color=blue]
> I was planning on "sanitizing " the language instead of relying on rexec
> and bastion so issues with them shouldn't be relevant.[/color]

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. :-)
[color=blue]
> 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)...[/color]

Okay, but are you saying that combining those keywords with "security"
when searching comp.lang.pytho n 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]

Re: Sandboxes

In article <z9adnZyPsq8R3Z feRVn-3A@powergate.ca >, peter@engcorp.c om
says...[color=blue]
> 42 wrote:[color=green]
> > I was planning on "sanitizing " the language instead of relying on rexec
> > and bastion so issues with them shouldn't be relevant.[/color]
>
> I think in dealing with security, deciding what might be relevant before
> you fully understand the problem is somewhat premature...[/color]

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.
[color=blue][color=green]
> > 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)...[/color]
>
> Okay, but are you saying that combining those keywords with "security"
> when searching comp.lang.pytho n in Google Groups produced no useful
> results?[/color]

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'.
[color=blue]
> 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.[/color]

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]

Re: Sandboxes

42 wrote:[color=blue]
> 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 :)[/color]

f = [x for x in [].__class__.__ba ses__[0].__subclasses__ () if
x.__name__=='fi le'][0]
f('/path/to/important/file', 'w').close()

[42]

Re: Sandboxes

In article <MewOe.289$hn4. 51508@newshog.n ewsread.com>,
eurleif@ecritte rs.biz says...[color=blue]
> 42 wrote:[color=green]
> > 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 :)[/color]
>
> f = [x for x in [].__class__.__ba ses__[0].__subclasses__ () if
> x.__name__=='fi le'][0]
> f('/path/to/important/file', 'w').close()
>[/color]

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]

Re: Sandboxes

> Basically I just want a language to allow users to write macros,[color=blue]
> 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.[/color]

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