Re: [Python-Dev] The pysandbox project is broken

[Trent Nelson]

On Sat, Nov 16, 2013 at 02:53:22AM -0800, Maciej Fijalkowski wrote:
> On Fri, Nov 15, 2013 at 6:56 PM, Trent Nelson  wrote:
> > On Tue, Nov 12, 2013 at 01:16:55PM -0800, Victor Stinner wrote:
> >> pysandbox cannot be used in practice
> >> 
> >>
> >> To protect the untrusted namespace, pysandbox installs a lot of
> >> different protections. Because of all these protections, it becomes
> >> hard to write Python code. Basic features like "del dict[key]" are
> >> denied. Passing an object to a sandbox is not possible to sandbox,
> >> pysandbox is unable to proxify arbitary objects.
> >>
> >> For something more complex than evaluating "1+(2*3)", pysandbox cannot
> >> be used in practice, because of all these protections. Individual
> >> protections cannot be disabled, all protections are required to get a
> >> secure sandbox.
> >
> > This sounds a lot like the work I initially did with PyParallel to
> > try and intercept/prevent parallel threads mutating main-thread
> > objects.
> >
> > I ended up arriving at a much better solution by just relying on
> > memory protection; main thread pages are set read-only prior to
> > parallel threads being able to run.  If a parallel thread attempts
> > to mutate a main thread object; a SEH is raised (SIGSEV on POSIX),
> > which I catch in the ceval loop and convert into an exception.
> >
> > See slide 138 of this: 
> > https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploited-all-cores-1
> >
> > I'm wondering if this sort of an approach (which worked surprisingly
> > well) could be leveraged to also provide a sandbox environment?  The
> > goals are the same: robust protection against mutation of memory
> > allocated outside of the sandbox.
> >
> > (I'm purely talking about memory mutation; haven't thought about how
> >  that could be extended to prevent file system interaction as well.)
> >
> >
> > Trent.
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe: 
> > https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
> 
> Trent, you should read the mail more carefully. Notably the same
> issues that make it impossible to create a sandbox make it impossible
> to create pyparaller really work. Being read-only is absolutely not
> enough - you can read some internal structures in inconsistent state
> that lead to crashes and/or very unexpected behavior even without
> modifying anything.

What do you mean by inconsistent state?  Like a dict half way
through `a['foo'] = 'bar'`?  That can't happen with PyParallel;
parallel threads don't run when the main thread runs and vice
versa.  The main thread's memory (and internal object structure)
will always be consistent by the time the parallel threads run.

> PS. We really did a lot of work analyzing how STM-pypy can lead to
> conflicts and/or inconsistent behavior.

But you support free-threading though, right?  As in, code that
subclasses threading.Thread should be able to benefit from your
STM work?

I explicitly don't support free-threading.  Your threading.Thread
code will not magically run faster with PyParallel.  You'll need
to re-write your code using the parallel and async façade APIs I
expose.

On the plus side, I can completely control everything about the
main thread and parallel thread execution environments; obviating
the need to protect against internal inconsistencies by virtue of
the fact that the main thread will always be in a consistent state
when the parallel threads are running.

(And it works really well in practice; I ported SimpleHTTPServer to
use my new async stuff and it flies -- it'll automatically exploit
all your cores if there is sufficient incoming load.  Unexpected
side-effect of my implementation is that code executing in parallel
callbacks actually runs faster than normal single-threaded Python
code; no need to do reference counting, GC, and the memory model is
ridiculously cache and TLB friendly.)

This is getting off-topic though and I don't want to hijack the
sandbox thread.  I was planning on sending an e-mail in a few days
when the PyData video of my talk is live -- we can debate the merits
of my parallel/async approach then :-)

> Cheers,
> fijal

Trent.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Maciej Fijalkowski]

On Fri, Nov 15, 2013 at 6:56 PM, Trent Nelson  wrote:
> On Tue, Nov 12, 2013 at 01:16:55PM -0800, Victor Stinner wrote:
>> pysandbox cannot be used in practice
>> 
>>
>> To protect the untrusted namespace, pysandbox installs a lot of
>> different protections. Because of all these protections, it becomes
>> hard to write Python code. Basic features like "del dict[key]" are
>> denied. Passing an object to a sandbox is not possible to sandbox,
>> pysandbox is unable to proxify arbitary objects.
>>
>> For something more complex than evaluating "1+(2*3)", pysandbox cannot
>> be used in practice, because of all these protections. Individual
>> protections cannot be disabled, all protections are required to get a
>> secure sandbox.
>
> This sounds a lot like the work I initially did with PyParallel to
> try and intercept/prevent parallel threads mutating main-thread
> objects.
>
> I ended up arriving at a much better solution by just relying on
> memory protection; main thread pages are set read-only prior to
> parallel threads being able to run.  If a parallel thread attempts
> to mutate a main thread object; a SEH is raised (SIGSEV on POSIX),
> which I catch in the ceval loop and convert into an exception.
>
> See slide 138 of this: 
> https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploited-all-cores-1
>
> I'm wondering if this sort of an approach (which worked surprisingly
> well) could be leveraged to also provide a sandbox environment?  The
> goals are the same: robust protection against mutation of memory
> allocated outside of the sandbox.
>
> (I'm purely talking about memory mutation; haven't thought about how
>  that could be extended to prevent file system interaction as well.)
>
>
> Trent.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com

Trent, you should read the mail more carefully. Notably the same
issues that make it impossible to create a sandbox make it impossible
to create pyparaller really work. Being read-only is absolutely not
enough - you can read some internal structures in inconsistent state
that lead to crashes and/or very unexpected behavior even without
modifying anything.

PS. We really did a lot of work analyzing how STM-pypy can lead to
conflicts and/or inconsistent behavior.

Cheers,
fijal
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Maciej Fijalkowski]

On Sat, Nov 16, 2013 at 12:12 PM, Nick Coghlan  wrote:
> On 16 Nov 2013 11:35, "Christian Tismer"  wrote:
>> IOW: Do we really need a full abstraction, embedded in a virtual OS, or
>> is there already a compromise that suits 98 percent of the common needs?
>>
>> I think as a starter, categorizing the expectations of some measure of 
>> 'secure python'
>> would make sense. And I'm asking the people with better knowledge of these 
>> matters
>> than I have. (and not asking those who don't... ;-) )
>
> The litany of vulnerability reports against the Java sandbox has long
> confirmed my impression that secure sandboxing is a hard, not
> completely solved problem, best left to better resourced platform
> developers (or at least taking the appropriate steps to benefit from
> their work).
>
> A self-hosted language runtime level sandbox is, at best, a first line
> of defence that protects against basic, naive attacks. One of the
> assumptions I see from the folks working on operating systems, virtual
> machine and container security is that the sandboxes *will* be
> compromised at some point, so you have to make sure to understand what
> the consequences of those breaches will be, and the best answer is
> "they run into the next line of defence, so the only thing they have
> gained is the ability to attack that").
>
> In terms of in-process sandboxing of CPython (*at all*, let alone
> self-hosted), we're currently missing some key foundational
> components:
>
> - the ability for a host process to cleanly configure the capabilities
> of an embedded CPython interpreter (that's what PEP 432 is all about)
> - elimination of all of the mechanisms by which hostile untrusted code
> can trigger a segfault in the runtime (any segfault bug can reasonably
> be assumed to be a security vulnerability waiting to be exploited, the
> only question is whether the CPython runtime is part of the exposed
> attack surface, and what the consequences are of compromising the
> runtime). While Victor Stinner's recent work with failmalloc has been
> a big step forward here, as have been various other changes in the
> CPython code base (like adding recursion depth constraints to the
> compiler toolchain), we're still a long way from being able to say
> "CPython cannot be segfaulted by legal Python code that doesn't use
> ctypes or an equivalent FFI library".
>
> This is why I share Guido's (and the PyPy team's) view that secure,
> cross-platform sandboxing of (C)Python is currently not possible.
> Secure in-process sandboxing is hard even for languages like Lua,
> JavaScript and Java that were designed from the ground up with
> sandboxing in mind - sure, you can lock things down to the point where
> untrusted code assuredly can't do any damage, but it often can't do
> anything *useful* in that state, either.
>
> By contrast, the PyPy sandbox model which uses a deliberately
> constrained runtime to execute untrusted code in an OS level process
> that is designed to only permit communication with the parent process
> is *exactly* the kind of paranoid defence-in-depth approach that
> should be employed when running untrusted code. Ideally, all of the
> platform level "this child process is not allowed to do anything
> except talk to me over stdin and stdout" would also be brought to bear
> on the sandboxed runtime, so that as yet undiscovered vulnerabilities
> in the PyPy sandbox don't result in a system compromise.
>
> Anyone interested in sandboxing of Python code would be well-advised
> to direct their efforts towards the parent process bindings for
> http://doc.pypy.org/en/latest/sandbox.html, as well as identifying the
> associated platform specific settings to lock out the child process
> from all system access except communication with the parent process
> over the standard streams.

Note Nick that the part that runs stuff in child process (as opposed
to have two different pythons running in the same process) is really
not a limitation of the approach. It's just that it's a proof of
concept and various other options are also possible, just noone seems
to be interested to pursue them. Additional OS level blocking is
really only working against potential segfaults, since we know that
there is no IO possible from the inner process. A JIT-less PyPy
sandbox can be made very secure by locking the executable pages as
non-writable (we know the code does not do any IO).

Cheers,
fijal
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Nick Coghlan]

On 16 Nov 2013 11:35, "Christian Tismer"  wrote:
> IOW: Do we really need a full abstraction, embedded in a virtual OS, or
> is there already a compromise that suits 98 percent of the common needs?
>
> I think as a starter, categorizing the expectations of some measure of 
> 'secure python'
> would make sense. And I'm asking the people with better knowledge of these 
> matters
> than I have. (and not asking those who don't... ;-) )

The litany of vulnerability reports against the Java sandbox has long
confirmed my impression that secure sandboxing is a hard, not
completely solved problem, best left to better resourced platform
developers (or at least taking the appropriate steps to benefit from
their work).

A self-hosted language runtime level sandbox is, at best, a first line
of defence that protects against basic, naive attacks. One of the
assumptions I see from the folks working on operating systems, virtual
machine and container security is that the sandboxes *will* be
compromised at some point, so you have to make sure to understand what
the consequences of those breaches will be, and the best answer is
"they run into the next line of defence, so the only thing they have
gained is the ability to attack that").

In terms of in-process sandboxing of CPython (*at all*, let alone
self-hosted), we're currently missing some key foundational
components:

- the ability for a host process to cleanly configure the capabilities
of an embedded CPython interpreter (that's what PEP 432 is all about)
- elimination of all of the mechanisms by which hostile untrusted code
can trigger a segfault in the runtime (any segfault bug can reasonably
be assumed to be a security vulnerability waiting to be exploited, the
only question is whether the CPython runtime is part of the exposed
attack surface, and what the consequences are of compromising the
runtime). While Victor Stinner's recent work with failmalloc has been
a big step forward here, as have been various other changes in the
CPython code base (like adding recursion depth constraints to the
compiler toolchain), we're still a long way from being able to say
"CPython cannot be segfaulted by legal Python code that doesn't use
ctypes or an equivalent FFI library".

This is why I share Guido's (and the PyPy team's) view that secure,
cross-platform sandboxing of (C)Python is currently not possible.
Secure in-process sandboxing is hard even for languages like Lua,
JavaScript and Java that were designed from the ground up with
sandboxing in mind - sure, you can lock things down to the point where
untrusted code assuredly can't do any damage, but it often can't do
anything *useful* in that state, either.

By contrast, the PyPy sandbox model which uses a deliberately
constrained runtime to execute untrusted code in an OS level process
that is designed to only permit communication with the parent process
is *exactly* the kind of paranoid defence-in-depth approach that
should be employed when running untrusted code. Ideally, all of the
platform level "this child process is not allowed to do anything
except talk to me over stdin and stdout" would also be brought to bear
on the sandboxed runtime, so that as yet undiscovered vulnerabilities
in the PyPy sandbox don't result in a system compromise.

Anyone interested in sandboxing of Python code would be well-advised
to direct their efforts towards the parent process bindings for
http://doc.pypy.org/en/latest/sandbox.html, as well as identifying the
associated platform specific settings to lock out the child process
from all system access except communication with the parent process
over the standard streams.

Cheers,
Nick.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Ethan Furman]

On 11/15/2013 02:24 PM, Christian Tismer wrote:


I appreciate very much that Victor tried his best to fill that old gap.
And after that breakage happened again, I think it is urgent to have an

> in-depth discussion how that situation should be treated in the
> future.

+1

--
~Ethan~

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Christian Tismer]

On 16.11.13 01:35, Guido van Rossum wrote:
On Fri, Nov 15, 2013 at 4:31 PM, Nick Coghlan > wrote:


"Use an OS level sandbox" *is* better from a security point of
view. It's just not portable :P


Honestly, I don't believe in portable security. :-)

BTW, in case it wasn't clear, I think it was a courageous step by 
Victor to declare defeat. Negative results are also results, and they 
need to be published. Thanks Victor!


Sure it was, and it was great to follow Victor's project!
I was about to use it in production, until I saw it's flaws, a while back.

Nevertheless, the issue has never been treated as much as to be able to
say "this way you implement that security in Python", whatever "that" 
should be.

So I think it is worth discussing, and may it just be to identify the levels
of security involved, to help people to even identify their individual 
needs.


My question is, actually:
Do we need to address this topic, or is it already crystal clear that 
something
like PyPy's approach is necessary and sufficient to solve the common, 
undefined
problem of "run some script on whatnot, with the following security 
constraint"?


IOW: Do we really need a full abstraction, embedded in a virtual OS, or
is there already a compromise that suits 98 percent of the common needs?

I think as a starter, categorizing the expectations of some measure of 
'secure python'
would make sense. And I'm asking the people with better knowledge of 
these matters

than I have. (and not asking those who don't... ;-) )

cheers -- Chris

--
Christian Tismer :^)   
Software Consulting  : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Guido van Rossum]

On Fri, Nov 15, 2013 at 4:31 PM, Nick Coghlan  wrote:

> "Use an OS level sandbox" *is* better from a security point of view. It's
> just not portable :P
>

Honestly, I don't believe in portable security. :-)

BTW, in case it wasn't clear, I think it was a courageous step by Victor to
declare defeat. Negative results are also results, and they need to be
published. Thanks Victor!

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Nick Coghlan]

On 16 Nov 2013 08:25, "Christian Tismer"  wrote:
>
> On 13/11/13 00:49, Josiah Carlson wrote:
>>
>>
>> Python-dev is for the development of the Python core language, the
CPython runtime, and libraries. Your sandbox, despite using and requiring
deep knowledge of the runtime, is not developing those things. If you had a
series of requests for the language or runtime that would make your job
easier, then your thread would be on-topic.
>>
>
> I think you should consider to re-define you perception of the purpose
> of the python-dev list. Simple feature-requests is not everything.
> Instead, this list also touches the general direction where python should
> go, and discusses the current hard-to-solve problems.
>
> The sand-boxing feature via rexec, bastion etc. was perceived as a
useful, quite
> safe thing, until it was proven to be completely broken (Samuele Pedroni
et. at., 2003
> I think). After that, CPython simply removed those features and failed
completely to
> provide a better solution.

"Use an OS level sandbox" *is* better from a security point of view. It's
just not portable :P

Cheers,
Nick.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Christian Tismer]

On 13/11/13 00:49, Josiah Carlson wrote:


Python-dev is for the development of the Python core language, the 
CPython runtime, and libraries. Your sandbox, despite using and 
requiring deep knowledge of the runtime, is not developing those 
things. If you had a series of requests for the language or runtime 
that would make your job easier, then your thread would be on-topic.




I think you should consider to re-define you perception of the purpose
of the python-dev list. Simple feature-requests is not everything.
Instead, this list also touches the general direction where python should
go, and discusses the current hard-to-solve problems.

The sand-boxing feature via rexec, bastion etc. was perceived as a 
useful, quite
safe thing, until it was proven to be completely broken (Samuele Pedroni 
et. at., 2003
I think). After that, CPython simply removed those features and failed 
completely to

provide a better solution.

I appreciate very much that Victor tried his best to fill that old gap. 
And after
that breakage happened again, I think it is urgent to have an in-depth 
discussion how that

situation should be treated in the future.

--
Christian Tismer :^)   
Software Consulting  : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Trent Nelson]

On Nov 15, 2013, at 12:34 PM, Victor Stinner wrote:

> 2013/11/15 Trent Nelson :
>>This sounds a lot like the work I initially did with PyParallel to
>>try and intercept/prevent parallel threads mutating main-thread
>>objects.
>> 
>>I ended up arriving at a much better solution by just relying on
>>memory protection; main thread pages are set read-only prior to
>>parallel threads being able to run.  If a parallel thread attempts
>>to mutate a main thread object; a SEH is raised (SIGSEV on POSIX),
>>which I catch in the ceval loop and convert into an exception.
> 
> Read-only is not enough, an attack must not be able to read sensitive data.

Well you could remove both write *and* read perms from pages, such that you 
would trap on read attempts too.  What's an example of sensitive data that 
you'd need to have residing in the same process that you also want to sandbox?

I was going to suggest something like:

with memory.protected:
htpasswd = open('htpasswd', 'r').read()
...

But then I couldn't think of why you'd persist the sensitive data past the 
point you'd need it. 

> Protections of memory pages sound very low-level, so not very portable :-/

It's a pretty fundamental provision provided by operating systems; granted, the 
interface differs (mprotect() versus VirtualProtect()), but the result is the 
same.

> How do you know fif SIGSEGV comes from a legal call (parallel thread
> thing) or a real bug?

You don't, but it doesn't really matter.  It'll be pretty obvious from looking 
at the offending line of code in the exception whether it was a legitimate 
memory protection error, or a bug in an extension module/CPython internals.

And having a ProtectionError bubble all the way back up to the top of the stack 
with exact details about the offending frame/line could be considered a nicer 
alternative to dumping core ;-)  (Unless you happen to be in an `except: pass` 
block.)

> Victor


Trent.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Victor Stinner]

2013/11/15 Trent Nelson :
> This sounds a lot like the work I initially did with PyParallel to
> try and intercept/prevent parallel threads mutating main-thread
> objects.
>
> I ended up arriving at a much better solution by just relying on
> memory protection; main thread pages are set read-only prior to
> parallel threads being able to run.  If a parallel thread attempts
> to mutate a main thread object; a SEH is raised (SIGSEV on POSIX),
> which I catch in the ceval loop and convert into an exception.

Read-only is not enough, an attack must not be able to read sensitive data.

Protections of memory pages sound very low-level, so not very portable :-/

How do you know fif SIGSEGV comes from a legal call (parallel thread
thing) or a real bug?

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Trent Nelson]

On Tue, Nov 12, 2013 at 01:16:55PM -0800, Victor Stinner wrote:
> pysandbox cannot be used in practice
> 
> 
> To protect the untrusted namespace, pysandbox installs a lot of
> different protections. Because of all these protections, it becomes
> hard to write Python code. Basic features like "del dict[key]" are
> denied. Passing an object to a sandbox is not possible to sandbox,
> pysandbox is unable to proxify arbitary objects.
> 
> For something more complex than evaluating "1+(2*3)", pysandbox cannot
> be used in practice, because of all these protections. Individual
> protections cannot be disabled, all protections are required to get a
> secure sandbox.

This sounds a lot like the work I initially did with PyParallel to
try and intercept/prevent parallel threads mutating main-thread
objects.

I ended up arriving at a much better solution by just relying on
memory protection; main thread pages are set read-only prior to
parallel threads being able to run.  If a parallel thread attempts
to mutate a main thread object; a SEH is raised (SIGSEV on POSIX),
which I catch in the ceval loop and convert into an exception.

See slide 138 of this: 
https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploited-all-cores-1

I'm wondering if this sort of an approach (which worked surprisingly
well) could be leveraged to also provide a sandbox environment?  The
goals are the same: robust protection against mutation of memory
allocated outside of the sandbox.

(I'm purely talking about memory mutation; haven't thought about how
 that could be extended to prevent file system interaction as well.)


Trent.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Armin Rigo]

Hi Victor,

On Wed, Nov 13, 2013 at 12:58 AM, Victor Stinner
 wrote:
> I now gave up on sandboxing Python. I just would like to warn other
> core developers that trying to put a sandbox in Python is not a good
> idea :-)

I cannot thank you enough for writing this mail :-)  It is a great
place to point people to when they come along with some superficial
idea about sandboxing Python.


A bientôt,

Armin.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Eli Bendersky]

On Wed, Nov 13, 2013 at 10:27 AM, Brett Cannon  wrote:

>
>
>
> On Wed, Nov 13, 2013 at 1:05 PM, Eli Bendersky  wrote:
>
>>
>>
>>
>> On Wed, Nov 13, 2013 at 6:58 AM, Brett Cannon  wrote:
>>
>>>
>>>
>>>
>>> On Wed, Nov 13, 2013 at 6:30 AM, Facundo Batista <
>>> facundobati...@gmail.com> wrote:
>>>
 On Wed, Nov 13, 2013 at 4:37 AM, Maciej Fijalkowski 
 wrote:

 >> Do you think it would be productive to create an independent Python
 >> compiler, designed with sandboxing in mind from the beginning?
 >
 > PyPy sandbox does work FYI
 >
 > It might not do exactly what you want, but it both provides a full
 > python and security.

 If we have sandboxing using PyPy... what also we need to put Python
 running in the browser? (like javascript, you know)

 Thanks!

>>>
>>> You can try to get PNaCl to work with Python to get a Python executable
>>> that at least Chrome can run.
>>>
>>
>> Two corrections:
>>
>> 1. CPython already works with NaCl and PNaCl (there are working patches
>> in naclports to build it)
>>
>
> Anything that should be upstreamed?
>
>
>> 2. It can be used outside Chrome as well, using the standalone "sel_ldr"
>> tool that will then allow to run a sandboxed CPython .nexe from the command
>> line
>>
>
> Sure, but I was just thinking about the "in browser" question Facundo
> asked about.
>

FWIW, if you already have Chrome 31, go to:

http://commondatastorage.googleapis.com/nativeclient-mirror/naclports/pepper_33/988/publish/python/pnacl/index.html

This is CPython running on top of PNaCl, at near-native speed. With C
extensions. With threads. It's 2.7.5 but we'll put up 3.4 too soon (anyone
can do it though - based on naclports).

The first load takes a bit of time, afterwards it's cached and
instantaneous.

Now all that's left is for someone to come up with a friendly API to wrap
around the Pepper interface to conveniently access DOM :-)

Eli
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Eli Bendersky]

On Wed, Nov 13, 2013 at 2:48 PM, Christian Heimes wrote:

> Am 13.11.2013 23:37, schrieb Eli Bendersky:
> > Yeah, it definitely could. There are two problems currently: 1) the
> > patches are for 2.7.x and 2) they have some ugly hacks in them. But I
> > will talk to the guy who worked on that and hopefully we'll be able to
> > have something cleaned up for upstreaming into default/3.x
> >
> > Anyhow, the webstore app is:
> >
> https://chrome.google.com/webstore/detail/python/nodpmmidbgeganfponihbgmfcoiibffi
> >
> > And the code is in: https://code.google.com/p/naclports/wiki/PortList
>
> The patch
>
> https://code.google.com/p/naclports/source/browse/trunk/src/libraries/python/nacl.patch
> looks rather small and simple. Some of the hacks may not be required in
> Python 3.4, too. I'd love to have PNaCl support in Python 3.4!
>

Feel free to chime in, if you want. You can download the PNaCl toolchain
from the latest Native Client SDK and hack on this easily. I'll be happy to
look at any patches you have for this.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Christian Heimes]

Am 13.11.2013 23:37, schrieb Eli Bendersky:
> Yeah, it definitely could. There are two problems currently: 1) the
> patches are for 2.7.x and 2) they have some ugly hacks in them. But I
> will talk to the guy who worked on that and hopefully we'll be able to
> have something cleaned up for upstreaming into default/3.x
> 
> Anyhow, the webstore app is:
> https://chrome.google.com/webstore/detail/python/nodpmmidbgeganfponihbgmfcoiibffi
> 
> And the code is in: https://code.google.com/p/naclports/wiki/PortList

The patch
https://code.google.com/p/naclports/source/browse/trunk/src/libraries/python/nacl.patch
looks rather small and simple. Some of the hacks may not be required in
Python 3.4, too. I'd love to have PNaCl support in Python 3.4!

Christian

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Eli Bendersky]

On Wed, Nov 13, 2013 at 10:27 AM, Brett Cannon  wrote:

>
>
>
> On Wed, Nov 13, 2013 at 1:05 PM, Eli Bendersky  wrote:
>
>>
>>
>>
>> On Wed, Nov 13, 2013 at 6:58 AM, Brett Cannon  wrote:
>>
>>>
>>>
>>>
>>> On Wed, Nov 13, 2013 at 6:30 AM, Facundo Batista <
>>> facundobati...@gmail.com> wrote:
>>>
 On Wed, Nov 13, 2013 at 4:37 AM, Maciej Fijalkowski 
 wrote:

 >> Do you think it would be productive to create an independent Python
 >> compiler, designed with sandboxing in mind from the beginning?
 >
 > PyPy sandbox does work FYI
 >
 > It might not do exactly what you want, but it both provides a full
 > python and security.

 If we have sandboxing using PyPy... what also we need to put Python
 running in the browser? (like javascript, you know)

 Thanks!

>>>
>>> You can try to get PNaCl to work with Python to get a Python executable
>>> that at least Chrome can run.
>>>
>>
>> Two corrections:
>>
>> 1. CPython already works with NaCl and PNaCl (there are working patches
>> in naclports to build it)
>>
>
> Anything that should be upstreamed?
>

Yeah, it definitely could. There are two problems currently: 1) the patches
are for 2.7.x and 2) they have some ugly hacks in them. But I will talk to
the guy who worked on that and hopefully we'll be able to have something
cleaned up for upstreaming into default/3.x

Anyhow, the webstore app is:
https://chrome.google.com/webstore/detail/python/nodpmmidbgeganfponihbgmfcoiibffi

And the code is in: https://code.google.com/p/naclports/wiki/PortList


>
>
>> 2. It can be used outside Chrome as well, using the standalone "sel_ldr"
>> tool that will then allow to run a sandboxed CPython .nexe from the command
>> line
>>
>
> Sure, but I was just thinking about the "in browser" question Facundo
> asked about.
>

Yep, see link above for in-the-browser Python. Same can be done with PNaCl
and not require the web store (this can actually be built by anyone from
the NaCl SDK today).


Eli
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Brett Cannon]

On Wed, Nov 13, 2013 at 1:05 PM, Eli Bendersky  wrote:

>
>
>
> On Wed, Nov 13, 2013 at 6:58 AM, Brett Cannon  wrote:
>
>>
>>
>>
>> On Wed, Nov 13, 2013 at 6:30 AM, Facundo Batista <
>> facundobati...@gmail.com> wrote:
>>
>>> On Wed, Nov 13, 2013 at 4:37 AM, Maciej Fijalkowski 
>>> wrote:
>>>
>>> >> Do you think it would be productive to create an independent Python
>>> >> compiler, designed with sandboxing in mind from the beginning?
>>> >
>>> > PyPy sandbox does work FYI
>>> >
>>> > It might not do exactly what you want, but it both provides a full
>>> > python and security.
>>>
>>> If we have sandboxing using PyPy... what also we need to put Python
>>> running in the browser? (like javascript, you know)
>>>
>>> Thanks!
>>>
>>
>> You can try to get PNaCl to work with Python to get a Python executable
>> that at least Chrome can run.
>>
>
> Two corrections:
>
> 1. CPython already works with NaCl and PNaCl (there are working patches in
> naclports to build it)
>

Anything that should be upstreamed?


> 2. It can be used outside Chrome as well, using the standalone "sel_ldr"
> tool that will then allow to run a sandboxed CPython .nexe from the command
> line
>

Sure, but I was just thinking about the "in browser" question Facundo asked
about.


>
> Note that this is a fundamentally different sandboxing model (the whole
> interpreter is run in a sandbox), but it's also more secure. PNaCl has
> shipped publicly yesterday, so Chrome runs native code *from the web* on
> your machine - a lot of security research and work went into making this
> possible.
>
> As for performance, the sandboxing overhead of NaCl is very low (< 10% in
> most cases).
>

I feel like we need to have a page at python.org (or somewhere) that
provides every which way to run Python from the browser for people to try
the interpreter out as easily as possible.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Eli Bendersky]

On Wed, Nov 13, 2013 at 6:58 AM, Brett Cannon  wrote:

>
>
>
> On Wed, Nov 13, 2013 at 6:30 AM, Facundo Batista  > wrote:
>
>> On Wed, Nov 13, 2013 at 4:37 AM, Maciej Fijalkowski 
>> wrote:
>>
>> >> Do you think it would be productive to create an independent Python
>> >> compiler, designed with sandboxing in mind from the beginning?
>> >
>> > PyPy sandbox does work FYI
>> >
>> > It might not do exactly what you want, but it both provides a full
>> > python and security.
>>
>> If we have sandboxing using PyPy... what also we need to put Python
>> running in the browser? (like javascript, you know)
>>
>> Thanks!
>>
>
> You can try to get PNaCl to work with Python to get a Python executable
> that at least Chrome can run.
>

Two corrections:

1. CPython already works with NaCl and PNaCl (there are working patches in
naclports to build it)
2. It can be used outside Chrome as well, using the standalone "sel_ldr"
tool that will then allow to run a sandboxed CPython .nexe from the command
line

Note that this is a fundamentally different sandboxing model (the whole
interpreter is run in a sandbox), but it's also more secure. PNaCl has
shipped publicly yesterday, so Chrome runs native code *from the web* on
your machine - a lot of security research and work went into making this
possible.

As for performance, the sandboxing overhead of NaCl is very low (< 10% in
most cases).

Eli
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Mark Lawrence]

On 13/11/2013 09:33, Simon Cross wrote:

Thanks for writing this email. It's well written and it takes a lot of
character to stand up and say you went down the wrong road. While I'm
here - thanks also for all your work on core Python. As a Python user
I really appreciate it.

Schiavo
Simon



Big +1s from me to Victor Stinner for his original email and to Simon 
Cross for this response.


--
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/13/2013 01:54 AM, Nick Coghlan wrote:
> I actually applaud his decision to post his final conclusion to the
> list, even though it wasn't the outcome he was hoping for. Negative
> data is still data :)

Amen!  I also applaud the work he put into the idea.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKDmQ0ACgkQ+gerLs4ltQ5XkACgn8riIUhp624gmVxSDqp6KNK+
A74An0Z3BKtc8CU0fSTsr4U76MTMw3Hi
=YtJz
-END PGP SIGNATURE-

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Brett Cannon]

On Wed, Nov 13, 2013 at 6:30 AM, Facundo Batista
wrote:

> On Wed, Nov 13, 2013 at 4:37 AM, Maciej Fijalkowski 
> wrote:
>
> >> Do you think it would be productive to create an independent Python
> >> compiler, designed with sandboxing in mind from the beginning?
> >
> > PyPy sandbox does work FYI
> >
> > It might not do exactly what you want, but it both provides a full
> > python and security.
>
> If we have sandboxing using PyPy... what also we need to put Python
> running in the browser? (like javascript, you know)
>
> Thanks!
>

You can try to get PNaCl to work with Python to get a Python executable
that at least Chrome can run.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Facundo Batista]

On Wed, Nov 13, 2013 at 4:37 AM, Maciej Fijalkowski  wrote:

>> Do you think it would be productive to create an independent Python
>> compiler, designed with sandboxing in mind from the beginning?
>
> PyPy sandbox does work FYI
>
> It might not do exactly what you want, but it both provides a full
> python and security.

If we have sandboxing using PyPy... what also we need to put Python
running in the browser? (like javascript, you know)

Thanks!

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
Twitter: @facundobatista
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Simon Cross]

Thanks for writing this email. It's well written and it takes a lot of
character to stand up and say you went down the wrong road. While I'm
here - thanks also for all your work on core Python. As a Python user
I really appreciate it.

Schiavo
Simon
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Victor Stinner]

2013/11/13 Glenn Linderman :
> If it is an implementation issue, then perhaps a different implementation
> would help. Or perhaps a "safe compiler".

There is PyPy with its sandbox.

> If it is a language design issue, then a different implementation wouldn't
> help, it would require a new language, or a restricted subset. I'm not sure
> whether some of the onerous sounding restrictions result from language or
> implementation issues; some of them certainly sounded like implementation
> issues.
>
> A restricted subset, compiled by a validating compiler, might still be a
> useful language, even if the execution speed has to be reduced by a
> validating runtime.
>
> Perhaps exception handling for exceptions hit inside a sandbox need to stop
> at the sandbox boundary. That is, exceptions within the sandbox stay within
> the sandbox, and exceptions generated due to sandbox calls to the
> implementation need to stay outside the sandbox, and then sanitized and
> limited information passed back in to the sandbox.
>
> Perhaps a different/restricted set of builtins must be provided within the
> sandbox.

The problem is to draw a line between the trusted namespace and the
untrusted namespace. Tracebacks are just one example, there are too
many other examples. Just another example: from types.__bases__, you
may reach all available types in Python, even "sensitive" types.

If you cannot draw a line because it is too complex, it probably means
that it's simpler to consider that the whole Python process is
untrusted. In this case, you have to put the sandbox outside Python,
not inside.

The second problem is that if you modify the Python language and write
a limited implementation of Python, it is no more the Python language.
What is the purpose of your sandbox if you cannot use the full Python
language and the stdlib?

It also depends on you use the sandbox. If it's just to evaluate basic
mathematic expressions, it's easier to use Python with an external
sandbox.

If you want to plug the sandbox "in your application", it's more
complex because you have to give access to your sensitive data through
a proxy, so the proxy must be carefully written.

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Maciej Fijalkowski]

On Wed, Nov 13, 2013 at 2:11 AM, Steven D'Aprano  wrote:
> On Wed, Nov 13, 2013 at 12:58:42AM +0100, Victor Stinner wrote:
>
>> I now gave up on sandboxing Python. I just would like to warn other
>> core developers that trying to put a sandbox in Python is not a good
>> idea :-)
>
> Do you mean CPython?
>
> Do you think it would be productive to create an independent Python
> compiler, designed with sandboxing in mind from the beginning?

PyPy sandbox does work FYI

It might not do exactly what you want, but it both provides a full
python and security.

Cheers,
fijal
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Georg Brandl]

Am 13.11.2013 00:49, schrieb Josiah Carlson:
> Python-dev is for the development of the Python core language, the CPython
> runtime, and libraries. Your sandbox, despite using and requiring deep 
> knowledge
> of the runtime, is not developing those things. If you had a series of 
> requests
> for the language or runtime that would make your job easier, then your thread
> would be on-topic.

Can we please exempt core committers from these misdemeanor notices?

Thanks,
Georg

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Nick Coghlan]

On 13 Nov 2013 09:56, "Josiah Carlson"  wrote:
>
> Python-dev is for the development of the Python core language, the
CPython runtime, and libraries. Your sandbox, despite using and requiring
deep knowledge of the runtime, is not developing those things. If you had a
series of requests for the language or runtime that would make your job
easier, then your thread would be on-topic.

While it may seem off-topic at first glance, pysandbox started out as
Victor's attempt to prove those of us that were saying this wouldn't work
wrong when he proposed replacing the long dead rexec and Bastion with
something more robust.

I actually applaud his decision to post his final conclusion to the list,
even though it wasn't the outcome he was hoping for. Negative data is still
data :)

Cheers,
Nick.

>
> I replied off-list because I didn't want to contribute to the off-topic
posting, but if posting on-list is required for you to pay attention, so be
it.
>
> - Josiah
>
> On Nov 12, 2013 2:51 PM, "Victor Stinner" 
wrote:
>>
>> 2013/11/12 Josiah Carlson :
>> > I'm replying off-list because I didn't want to bother the other folks
in
>> > python-dev (also, your post might have been better on python-list, but
I
>> > digress).
>>
>> I don't understand why you are writing to me directly. I won't reply
>> if you don't write publicly on python-dev.
>>
>> Summary of my email: it's not possible to write a sandbox in CPython.
>> So it's very specific to CPython internals. I'm not subscribed to
>> python-list.
>>
>> Victor
>>
>> >
>> > Long story short, I think that you are right, and I think that you are
>> > wrong.
>> >
>> > I think that you are right that your current pysandbox implementation
is
>> > likely broken by design. You are starting from a completely working
Python
>> > runtime, then eliminating/hiding/blocking certain features. This makes
it a
>> > game of whack-a-mole, for every vulnerability you fix, a new one comes
up
>> > later. The only way to fix this problem is to change your design.
>> >
>> > If you wanted to do it right, instead of removing things that are
>> > vulnerable, start by defining what is safe, and expose only those safe
>> > things. As an example, you did the right thing by splitting your main
and
>> > subprocess into two pieces. But you don't need to serialize your
objects
>> > from the trusted namespace to give access to the sandbox (that exposes
your
>> > "trusted" objects to the sandbox in a raw manner, in obvious
preparation for
>> > exploitation). Instead you would just expose a proxy object whose
method
>> > calls/attribute references are made across your pipe (or socket, or
>> > whatever) to the trusted controlling process. Is it slower? Yes. Does
it
>> > matter? Not if it keeps the sandbox secure.
>> >
>> > Now if you start by saying, "what is allowed?", the most obvious
destination
>> > is that you will more or less end up writing your own Python runtime.
That's
>> > not necessarily a bad thing, as if you know that a new runtime is your
>> > destination, you can look for a viable alternate-language runtime to
begin
>> > with to short-circuit your work. The best option that I can come up
with at
>> > this point is Javascript as a destination language, as there are
several
>> > Python to Javascript compilers out there, Javascript is sandboxed by
design,
>> > and you can arbitrarily eliminate portions of the py->js compilation
>> > opportunities to eliminate attack vectors (specifically keeping only
those
>> > that you know won't lead to an attack).
>> >
>> > Another option is Lua, though I don't really know of any viable Python
to
>> > Lua transpilers out there.
>> >
>> > Good luck with whatever you decide to do.
>> >
>> > Regards,
>> >  - Josiah
>>
>> >
>> >
>> >
>> > On Tue, Nov 12, 2013 at 1:16 PM, Victor Stinner <
victor.stin...@gmail.com>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> After having work during 3 years on a pysandbox project to sandbox
>> >> untrusted code, I now reached a point where I am convinced that
>> >> pysandbox is broken by design. Different developers tried to convinced
>> >> me before that pysandbox design is unsafe, but I had to experience it
>> >> myself to be convineced.
>> >>
>> >> It would also be nice to help developers looking for a sandbox for
>> >> their application. Please tell me if you know sandbox projects for
>> >> Python so I can redirect users of pysandbox to a safer solution. I
>> >> already know PyPy sandbox.
>> >>
>> >> I would like to share my experience because I know that other
>> >> developers are using sandboxes in production and that there is a real
>> >> need for sandboxing.
>> >>
>> >>
>> >> Origin of pysandbox
>> >> ===
>> >>
>> >> In 2010, a developper called Tav wrote a sandbox called "safelite.py":
>> >> the sandbox hides sensitive attributes to separate a trusted namespace
>> >> and an untrusted namespace. Tav challenged Python core developers to
>> >> break his sandbox and... the sandbox was quickly broken. Even if it
>> >

Re: [Python-Dev] The pysandbox project is broken

[Nick Coghlan]

On 13 Nov 2013 12:11, "Christian Heimes"  wrote:
>
> Am 13.11.2013 01:47, schrieb Glenn Linderman:
> > If it is an implementation issue, then perhaps a different
> > implementation would help. Or perhaps a "safe compiler".
> >
> > If it is a language design issue, then a different implementation
> > wouldn't help, it would require a new language, or a restricted subset.
> > I'm not sure whether some of the onerous sounding restrictions result
> > from language or implementation issues; some of them certainly sounded
> > like implementation issues.
> >
> > A restricted subset, compiled by a validating compiler, might still be a
> > useful language, even if the execution speed has to be reduced by a
> > validating runtime.
>
> A limited and well-defined subset of Python may do the trick, perhaps a
> project based on RPython. Zope has a long history of restricted Python
> code with safe-guards and security proxies. Any project must start with
> a proper threat model and goals. Does sandboxed code need to access
> frame objects and use compile()? Could we perhaps use a limited
> subinterpreters with reduced / modified builtins to archive isolation?

Brett Cannon also spent some time exploring exploring the idea of a
security capability based model for a Python implementation.

> CPython still has a couple of crashers, too. These must be resolved. You
> don't want sandboxed code to generate a segfault, do you?

Indeed - it would be interesting to see if any of those have been resolved
by the various edge case fixes in recent months.

> > Is there technology in the smartphone OSes that could be applied? iOS
> > seems to not even provide a file system to its apps, and there is
> > limited sharing of data from one app to the next. Android provides an
> > explicit subset of system services to its apps.
>
> On Linux seccomp may be a feasible way to prevent syscalls. Seccomp
> basically can limit the capability of a thread so it can no longer do
> certain syscalls. Chrome uses it for sandboxing.

Yeah, there's a reason our standard answer to "How do I sandbox Python
code?" has been "Use a subprocess and the OS provided process sandboxing
facilities" for quite some time.

Sandboxing software *at all* is difficult, doing it cross-platform is even
harder.

Cheers,
Nick.

>
> Christian
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Nick Coghlan]

On 13 Nov 2013 13:44, "Ned Batchelder"  wrote:
>
> On 11/12/13 6:48 PM, Terry Reedy wrote:
>>
>> On 11/12/2013 4:16 PM, Victor Stinner wrote:
>>
>>> It would also be nice to help developers looking for a sandbox for
>>> their application. Please tell me if you know sandbox projects for
>>> Python so I can redirect users of pysandbox to a safer solution. I
>>> already know PyPy sandbox.
>>
>>
>> There are several websites running submitted Python code (and in some
cases, many other languages).
>> ProjectEuler
>> CodeAcademy (I think they use someone else's code box)
>> CheckIO.org - python only
>> other coding challenge sites
>> I suspect they use sandboxed processes but have not seen anyone talk
about what they are doing.
>>
>
> At edX, we use CodeJail to apply OS-level sandboxing to untrusted Python
code: https://github.com/edx/codejail

A couple of years ago at PyCon AU, Tim Dawborn went over the sandboxing
approach used for the National Computer Science School infrastructure:
http://m.youtube.com/watch?v=y-WPPdhTKBU&feature=plpp&p=PLpKCScKXUAmerE_uUsImVlPsmhLaYQuQy

Cheers,
Nick.

>
> --Ned.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Ned Batchelder]

On 11/12/13 6:48 PM, Terry Reedy wrote:

On 11/12/2013 4:16 PM, Victor Stinner wrote:


It would also be nice to help developers looking for a sandbox for
their application. Please tell me if you know sandbox projects for
Python so I can redirect users of pysandbox to a safer solution. I
already know PyPy sandbox.


There are several websites running submitted Python code (and in some 
cases, many other languages).

ProjectEuler
CodeAcademy (I think they use someone else's code box)
CheckIO.org - python only
other coding challenge sites
I suspect they use sandboxed processes but have not seen anyone talk 
about what they are doing.




At edX, we use CodeJail to apply OS-level sandboxing to untrusted Python 
code: https://github.com/edx/codejail


--Ned.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Christian Heimes]

Am 13.11.2013 01:47, schrieb Glenn Linderman:
> If it is an implementation issue, then perhaps a different
> implementation would help. Or perhaps a "safe compiler".
> 
> If it is a language design issue, then a different implementation
> wouldn't help, it would require a new language, or a restricted subset.
> I'm not sure whether some of the onerous sounding restrictions result
> from language or implementation issues; some of them certainly sounded
> like implementation issues.
> 
> A restricted subset, compiled by a validating compiler, might still be a
> useful language, even if the execution speed has to be reduced by a
> validating runtime.

A limited and well-defined subset of Python may do the trick, perhaps a
project based on RPython. Zope has a long history of restricted Python
code with safe-guards and security proxies. Any project must start with
a proper threat model and goals. Does sandboxed code need to access
frame objects and use compile()? Could we perhaps use a limited
subinterpreters with reduced / modified builtins to archive isolation?

CPython still has a couple of crashers, too. These must be resolved. You
don't want sandboxed code to generate a segfault, do you?

> Is there technology in the smartphone OSes that could be applied? iOS
> seems to not even provide a file system to its apps, and there is
> limited sharing of data from one app to the next. Android provides an
> explicit subset of system services to its apps.

On Linux seccomp may be a feasible way to prevent syscalls. Seccomp
basically can limit the capability of a thread so it can no longer do
certain syscalls. Chrome uses it for sandboxing.

Christian
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Glenn Linderman]

On 11/12/2013 4:11 PM, Steven D'Aprano wrote:

On Wed, Nov 13, 2013 at 12:58:42AM +0100, Victor Stinner wrote:


>I now gave up on sandboxing Python. I just would like to warn other
>core developers that trying to put a sandbox in Python is not a good
>idea:-)

Do you mean CPython?

Do you think it would be productive to create an independent Python
compiler, designed with sandboxing in mind from the beginning?


In reading this thread, which I took as an on-topic dismissal of an 
integrated CPython sandbox, I also wondered if it was a CPython 
implementation issue, or a language design issue.


If it is an implementation issue, then perhaps a different 
implementation would help. Or perhaps a "safe compiler".


If it is a language design issue, then a different implementation 
wouldn't help, it would require a new language, or a restricted subset. 
I'm not sure whether some of the onerous sounding restrictions result 
from language or implementation issues; some of them certainly sounded 
like implementation issues.


A restricted subset, compiled by a validating compiler, might still be a 
useful language, even if the execution speed has to be reduced by a 
validating runtime.


Perhaps exception handling for exceptions hit inside a sandbox need to 
stop at the sandbox boundary. That is, exceptions within the sandbox 
stay within the sandbox, and exceptions generated due to sandbox calls 
to the implementation need to stay outside the sandbox, and then 
sanitized and limited information passed back in to the sandbox.


Perhaps a different/restricted set of builtins must be provided within 
the sandbox.


These ideas may perhaps still allow a CPython sandbox to be written, or 
may only help a new implementation.


Is there technology in the smartphone OSes that could be applied? iOS 
seems to not even provide a file system to its apps, and there is 
limited sharing of data from one app to the next. Android provides an 
explicit subset of system services to its apps.


Thanks, Victor, for the update on your sandbox efforts. I was hoping you 
would be successful, and then I was wondering if you had abandoned the 
effort, and now I know what the current status is.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Steven D'Aprano]

On Wed, Nov 13, 2013 at 12:58:42AM +0100, Victor Stinner wrote:

> I now gave up on sandboxing Python. I just would like to warn other
> core developers that trying to put a sandbox in Python is not a good
> idea :-)

Do you mean CPython?

Do you think it would be productive to create an independent Python 
compiler, designed with sandboxing in mind from the beginning?


-- 
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Guido van Rossum]

On Tue, Nov 12, 2013 at 3:53 PM, Victor Stinner wrote:

> 2013/11/13 Terry Reedy :
> > There are several websites running submitted Python code (and in some
> cases,
> > many other languages).
> > ProjectEuler
> > CodeAcademy (I think they use someone else's code box)
> > CheckIO.org - python only
> > other coding challenge sites
> > I suspect they use sandboxed processes but have not seen anyone talk
> about
> > what they are doing.
>

I sure hope so.

>
> It's probably a sandbox around the Python process, not inside the process.
>
> There is also http://shell.appspot.com/ which uses Google AppEngine.
> In my opinion, Google AppEngine doesn't use a sandbox in Python, but
> outside Python.


That's not just your opinion, it's a fact.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Victor Stinner]

2013/11/13 Terry Reedy :
> There are several websites running submitted Python code (and in some cases,
> many other languages).
> ProjectEuler
> CodeAcademy (I think they use someone else's code box)
> CheckIO.org - python only
> other coding challenge sites
> I suspect they use sandboxed processes but have not seen anyone talk about
> what they are doing.

It's probably a sandbox around the Python process, not inside the process.

There is also http://shell.appspot.com/ which uses Google AppEngine.
In my opinion, Google AppEngine doesn't use a sandbox in Python, but
outside Python.

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Victor Stinner]

2013/11/13 Josiah Carlson :
> Python-dev is for the development of the Python core language, the CPython
> runtime, and libraries. Your sandbox, despite using and requiring deep
> knowledge of the runtime, is not developing those things. If you had a
> series of requests for the language or runtime that would make your job
> easier, then your thread would be on-topic.

My initial goal was to put pysandbox directly into CPython when it
would be considered safe and stable.

The PEP 416 (frozendict) was a first step in this direction, but the
PEP was rejected.

I now gave up on sandboxing Python. I just would like to warn other
core developers that trying to put a sandbox in Python is not a good
idea :-)

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Josiah Carlson]

Python-dev is for the development of the Python core language, the CPython
runtime, and libraries. Your sandbox, despite using and requiring deep
knowledge of the runtime, is not developing those things. If you had a
series of requests for the language or runtime that would make your job
easier, then your thread would be on-topic.

I replied off-list because I didn't want to contribute to the off-topic
posting, but if posting on-list is required for you to pay attention, so be
it.

- Josiah
On Nov 12, 2013 2:51 PM, "Victor Stinner"  wrote:

> 2013/11/12 Josiah Carlson :
> > I'm replying off-list because I didn't want to bother the other folks in
> > python-dev (also, your post might have been better on python-list, but I
> > digress).
>
> I don't understand why you are writing to me directly. I won't reply
> if you don't write publicly on python-dev.
>
> Summary of my email: it's not possible to write a sandbox in CPython.
> So it's very specific to CPython internals. I'm not subscribed to
> python-list.
>
> Victor
>
> >
> > Long story short, I think that you are right, and I think that you are
> > wrong.
> >
> > I think that you are right that your current pysandbox implementation is
> > likely broken by design. You are starting from a completely working
> Python
> > runtime, then eliminating/hiding/blocking certain features. This makes
> it a
> > game of whack-a-mole, for every vulnerability you fix, a new one comes up
> > later. The only way to fix this problem is to change your design.
> >
> > If you wanted to do it right, instead of removing things that are
> > vulnerable, start by defining what is safe, and expose only those safe
> > things. As an example, you did the right thing by splitting your main and
> > subprocess into two pieces. But you don't need to serialize your objects
> > from the trusted namespace to give access to the sandbox (that exposes
> your
> > "trusted" objects to the sandbox in a raw manner, in obvious preparation
> for
> > exploitation). Instead you would just expose a proxy object whose method
> > calls/attribute references are made across your pipe (or socket, or
> > whatever) to the trusted controlling process. Is it slower? Yes. Does it
> > matter? Not if it keeps the sandbox secure.
> >
> > Now if you start by saying, "what is allowed?", the most obvious
> destination
> > is that you will more or less end up writing your own Python runtime.
> That's
> > not necessarily a bad thing, as if you know that a new runtime is your
> > destination, you can look for a viable alternate-language runtime to
> begin
> > with to short-circuit your work. The best option that I can come up with
> at
> > this point is Javascript as a destination language, as there are several
> > Python to Javascript compilers out there, Javascript is sandboxed by
> design,
> > and you can arbitrarily eliminate portions of the py->js compilation
> > opportunities to eliminate attack vectors (specifically keeping only
> those
> > that you know won't lead to an attack).
> >
> > Another option is Lua, though I don't really know of any viable Python to
> > Lua transpilers out there.
> >
> > Good luck with whatever you decide to do.
> >
> > Regards,
> >  - Josiah
> >
> >
> >
> > On Tue, Nov 12, 2013 at 1:16 PM, Victor Stinner <
> victor.stin...@gmail.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> After having work during 3 years on a pysandbox project to sandbox
> >> untrusted code, I now reached a point where I am convinced that
> >> pysandbox is broken by design. Different developers tried to convinced
> >> me before that pysandbox design is unsafe, but I had to experience it
> >> myself to be convineced.
> >>
> >> It would also be nice to help developers looking for a sandbox for
> >> their application. Please tell me if you know sandbox projects for
> >> Python so I can redirect users of pysandbox to a safer solution. I
> >> already know PyPy sandbox.
> >>
> >> I would like to share my experience because I know that other
> >> developers are using sandboxes in production and that there is a real
> >> need for sandboxing.
> >>
> >>
> >> Origin of pysandbox
> >> ===
> >>
> >> In 2010, a developper called Tav wrote a sandbox called "safelite.py":
> >> the sandbox hides sensitive attributes to separate a trusted namespace
> >> and an untrusted namespace. Tav challenged Python core developers to
> >> break his sandbox and... the sandbox was quickly broken. Even if it
> >> was quickly broken, I was conviced that Tav found something
> >> interesting and that there is a real need for sandboxing Python. I
> >> continued his work by putting more protections on the untrusted
> >> namespace. I published pysandbox 1.0 in june 2010.
> >>
> >>
> >> History of pysandbox
> >> 
> >>
> >> pysandbox was used to build an IRC bot on a french Python channel. The
> >> bot executed Python code in the sandbox. The bot was mainly used by
> >> hackers to test the sandbox to try to find a vulnerability. It

Re: [Python-Dev] The pysandbox project is broken

[Terry Reedy]

On 11/12/2013 4:16 PM, Victor Stinner wrote:


It would also be nice to help developers looking for a sandbox for
their application. Please tell me if you know sandbox projects for
Python so I can redirect users of pysandbox to a safer solution. I
already know PyPy sandbox.


There are several websites running submitted Python code (and in some 
cases, many other languages).

ProjectEuler
CodeAcademy (I think they use someone else's code box)
CheckIO.org - python only
other coding challenge sites
I suspect they use sandboxed processes but have not seen anyone talk 
about what they are doing.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Nick Coghlan]

On 13 Nov 2013 07:18, "Victor Stinner"  wrote:
>
> Please tell me if you know sandbox projects for Python so I can
> redirect users of pysandbox to a safer solution. I already know PyPy
> sandbox.

Sandboxing is hard enough (see also the many JVM vulnerabilities) that the
only ones I even remotely trust are the platform level mechanisms that form
the foundation of the various PaaS services, including SELinux and Linux
containers.

Cross platform? In process? Even Lua is hard to secure in that situation,
and it has a much smaller attack surface than CPython or Java.

Cheers,
Nick.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com