Creating a reliable sandboxed Python environment

[Steven D'Aprano]

On Sat, 30 May 2015 02:48 pm, Paul Rubin wrote:

> Chris Angelico <rosuav at gmail.com> writes:
>> You can *easily* sandbox something that has very little functionality
>> - all you have to do is provide a minimalist "language" that permits
>> only a very few actions, and you know it's safe. But that security
>> comes at a price.
> 
> This is a non-sequitur. The reason they didn't put more features into 
> Lua is that it would have made the memory footprint bigger and they
> pitch it as an embeddable extension engine so they want to keep it
> small.  

I wouldn't have imagined that the claim "it's easier to secure a small
language with a few features than a big language with lots of features"
would have been so controversial. I wonder if this claim will be equally as
controversial?

There is a rough correlation between the number of lines of code in a code
base, and the number of potential security holes that need to be guarded
against.


> Stuff like bignums and unicode in themselves wouldn't have 
> affected security. 

Do you consider a Denial of Service or Memory Exhaustion attack to be a
security issue? If not, try running this in Python:

100**100**100

(Perhaps not a great idea.) How about defeating cryptographic protection
mechanisms?

https://www.auscert.org.au/21885

Or using Unicode to bypass data validation?

https://capec.mitre.org/data/definitions/71.html

Unicode encoding attacks?

https://www.owasp.org/index.php/Unicode_Encoding
https://cwe.mitre.org/data/definitions/176.html

Unicode spoofing? Buffer overflows? UTF-8 exploits? IDNA exploits? Code
point deletion exploits? Malicious rendering?

http://unicode.org/reports/tr36/
http://unicode.org/faq/security.html


[...]
> Heck, think of Java, which is monstrously more complicated than Python
> and supports applet sandboxing, plus it can run Python programs (under
> Jython).  Or Javascript, which has similar complexity to Python and runs
> sandboxes in millions (billions?) of browsers.

Funny you should mention Javascript...

http://securityevaluators.com/knowledge/papers/engineeringheapoverflow.pdf
http://security.stackexchange.com/questions/41966/
https://nakedsecurity.sophos.com/exploring-the-blackhole-exploit-kit-7/
http://resources.infosecinstitute.com/fbi-tor-exploit/
https://www.mozilla.org/en-US/security/advisories/mfsa2013-53/

Yes, I can see why you think Javascript is securely sandboxed...

*wink*



-- 
Steven