Re: Python CGI sandboxing advice (packaging of Online Python Tutor)

2014-04-09 Thread Jakub Wilk 

* Jakub Wilk jw...@debian.org, 2014-02-13, 00:27:

The CGI's code is supposed to be safeguarding against abuse,

The protection is not very good. (I'll disclose the details later.)


The exploit I had in mind was:

import re
from re import sys
imp = re.sys.modules['imp']
posix = imp.load_dynamic('', 'posix')

which gives you access to the goodies of the posix module. There's a 
resource limit that prevents you from opening any file, but you can do 
chmod(), chown(), remove(), rename(), kill(), …


Apparently this is now fixed:
https://github.com/pgbovine/OnlinePythonTutor/commit/eab7cb1c717a

I wouldn't be surprised if there were other clever ways to bypass OPT's 
security restrictions, and upstream doesn't seem to confident about this 
code either.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140409121133.ga2...@jwilk.net

Re: Python CGI sandboxing advice (packaging of Online Python Tutor)

2014-04-09 Thread Olivier Berger 
Hi.

Jakub Wilk jw...@debian.org writes:

 * Jakub Wilk jw...@debian.org, 2014-02-13, 00:27:
The CGI's code is supposed to be safeguarding against abuse,
The protection is not very good. (I'll disclose the details later.)

 The exploit I had in mind was:

   import re
   from re import sys
   imp = re.sys.modules['imp']
   posix = imp.load_dynamic('', 'posix')

 which gives you access to the goodies of the posix module. There's a 
 resource limit that prevents you from opening any file, but you can do 
 chmod(), chown(), remove(), rename(), kill(), …

 Apparently this is now fixed:
 https://github.com/pgbovine/OnlinePythonTutor/commit/eab7cb1c717a

 I wouldn't be surprised if there were other clever ways to bypass OPT's 
 security restrictions, and upstream doesn't seem to confident about this 
 code either.

Thanks for sharing this. I'll have to read about re.sys (WTF ?)...

FWIW, I've put a hold to my tests of packaging OPT, while I was
investigating the use of Docker for sandboxing Web apps in its
containers.

For instance, I've been playing with FusionForge's mediawiki (including
its PostgreSQL and Apache dependencies) in such an environment, and it
seems one possible way...

I'm not sure whether others have similar plans using Docker for
something that could be done the debian way. Probably deserves another
post.

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8738hmveul@inf-8660.int-evry.fr

Re: pybuild sphinxdoc and extensions

2014-04-09 Thread Thomas Goirand 
On 04/07/2014 03:39 PM, picca wrote:
 As for http_proxy='localhost', it's much better to write
 http_proxy='127.0.0.1:9', as there really could be a web proxy running
 on localhost, and you don't really want to use it, do you?
 
 I just used the snipset of the wiki page explaining the library
 packaging. Maybe the wiki should be changed.

Yes. Which wiki page? URL?

 Also, are you
 doing like this to avoid intersphinx? In this case, why don't you just
 remove the intersphinx extension from conf.py? That's IMO much cleaner
 than just blocking the connection.
 
 It is easier for me to deal with this from the debian/rules files instead of
 maintaining a patch.

Ahum... maintaining a patch is probably an overstatement here.

Here's an example diff (not a valid diff for computers, but enough for
understanding by humans):

 extensions = ['sphinx.ext.autodoc',
   'sphinx.ext.todo',
   'sphinx.ext.coverage',
-  'sphinx.ext.intersphinx',

So, you'd be just removing 'sphinx.ext.intersphinx' from the extensions
list, that's a really minimalistic one liner patch. And that's much much
much cleaner than forcing sphinx to fail accessing the network.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53457de4.1000...@debian.org

RE:pybuild sphinxdoc and extensions

2014-04-09 Thread PICCA Frederic-Emmanuel 
 Yes. Which wiki page? URL?

this one [1]

 Ahum... maintaining a patch is probably an overstatement here.

 Here's an example diff (not a valid diff for computers, but enough for
 understanding by humans):

 extensions = ['sphinx.ext.autodoc',
   'sphinx.ext.todo',
   'sphinx.ext.coverage',
-  'sphinx.ext.intersphinx',


yes this is a one liner patch.

 So, you'd be just removing 'sphinx.ext.intersphinx' from the extensions
 list, that's a really minimalistic one liner patch. And that's much much
 much cleaner than forcing sphinx to fail accessing the network.

I just follow the LibraryStyleGuide...

cheers

Frederic

[1] https://wiki.debian.org/Python/LibraryStyleGuide

--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b1e58...@sun-dag3.synchrotron-soleil.fr