Prev: math symbols in unicode (grouped by purpose)
From: Stephen Hansen on 13 Aug 2010 19:37
Howdy-ho.

So, I'm working on a project which embeds Python into a bigger system to
provide extensibility. In this project, there's basically two types of
people who will be entering python code.

The trusted folks, who write code which are in files, and which can do
anything.

The untrusted folks, who are writing very simple chunks of code which
can only do limited things.

This latter group we want to sandbox as good as possible. Now, I know
that its not possible to perfectly sandbox Python, and I know certain
things will never be perfectly safe (like someone doing some crazy [0] *
100000 * 100000 and similar things). That's OK.

For this sandbox, we're killing import, execfile, open, eval, reload in
__builtin__. This all works well. However in previous discussions, I
learned about:

>>> [b for b in
(1).__class__.__bases__[0].__class__.__subclasses__((1).__class__.__bases__[0])
if b.__name__ == 'file'][0]('../blahblah', 'w').write("Hi!")
>>> ^D
ixokai$ more ../blahblah
Hi!

And things like that. (The above may not be the most efficient way to do
it). So, I had an idea: why not just do some simple sanitization. When
input comes in, just directly replace __ with DISALLOWED, and add
getattr/setattr/delattr to the mix of things we kill out of builtins.

This second group of people are doing simple little scripting tasks, and
not things that would ever involve needing to access a __method__, not
even a normal one like __init__. Most of what they do is me.this or
me.that("hi") and such. Occasionally there's a little simple logic, but
that's it.

Can you think of a way out of such a sandbox? A way to access disallowed
stuff, not a way to DOS.

--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/

From: geremy condra on 13 Aug 2010 19:57
On Fri, Aug 13, 2010 at 4:37 PM, Stephen Hansen
<me+list/python(a)ixokai.io> wrote:
> Howdy-ho.
>
> So, I'm working on a project which embeds Python into a bigger system to
> provide extensibility. In this project, there's basically two types of
> people who will be entering python code.
>
> The trusted folks, who write code which are in files, and which can do
> anything.
>
> The untrusted folks, who are writing very simple chunks of code which
> can only do limited things.
>
> This latter group we want to sandbox as good as possible. Now, I know
> that its not possible to perfectly sandbox Python, and I know certain
> things will never be perfectly safe (like someone doing some crazy [0] *
> 100000 * 100000 and similar things). That's OK.
>
> For this sandbox, we're killing import, execfile, open, eval, reload in
> __builtin__. This all works well. However in previous discussions, I
> learned about:
>
>>>> [b for b in
> (1).__class__.__bases__[0].__class__.__subclasses__((1).__class__.__bases__[0])
> if b.__name__ == 'file'][0]('../blahblah', 'w').write("Hi!")
>>>> ^D
> ixokai$ more ../blahblah
> Hi!
>
> And things like that. (The above may not be the most efficient way to do
> it). So, I had an idea: why not just do some simple sanitization. When
> input comes in, just directly replace __ with DISALLOWED, and add
> getattr/setattr/delattr to the mix of things we kill out of builtins.
>
> This second group of people are doing simple little scripting tasks, and
> not things that would ever involve needing to access a __method__, not
> even a normal one like __init__. Most of what they do is me.this or
> me.that("hi") and such. Occasionally there's a little simple logic, but
> that's it.
>
> Can you think of a way out of such a sandbox? A way to access disallowed
> stuff, not a way to DOS.

You may want to check out repy- they use it in the Seattle restricted
execution environment, and some pretty smart people claim it has
decent security properties. Here's a summary of some of the things
they don't allow:

https://seattle.cs.washington.edu/wiki/PythonVsRepy

Full disclosure: while I don't directly work on the repy environment,
I have worked on some other parts of the Seattle project.

Geremy Condra
From: Stephen Hansen on 13 Aug 2010 20:05
On 8/13/10 4:57 PM, geremy condra wrote:
> You may want to check out repy- they use it in the Seattle restricted
> execution environment, and some pretty smart people claim it has
> decent security properties. Here's a summary of some of the things
> they don't allow:
>
> https://seattle.cs.washington.edu/wiki/PythonVsRepy

Thanks, I'll look at it. However, its essential we have a fully capable
and powered Python for the first-class of people. They're not sandboxed
at all.

However, I'll check out what they've done for inspiration.

--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/

 | 
Pages: 1
Prev: math symbols in unicode (grouped by purpose)