On Wed, Aug 22, 2012 at 3:38 PM, Gregory Szorc <[email protected]> wrote:
> Let's think of what can be done to secure/limit Python. Disabling import > has already been mentioned. That's a start. > > What about the ast module [1]? I /think/ it could be used to ensure parsed > code conforms to whatever we allow. e.g. no import statements, no function > definitions, no classes, etc. Actually, it may be better to think of it in > terms of what would be allowed. Only declaring variables that are strings, > lists, or dicts. Only calling pre-defined functions "exported" by the build > system, etc. We start with the minimum and open it up as we need to. > Instead of disallowing imports, you could replace the importer (during build file evaluation) with something that allows only whitelisted modules, and potentially only allows subsets of those modules. For instance, you might want os.environ, but not os.open. You might also want to do something like replace os.environ with a wrapper that tracks access, so you can detect the environmental dependencies. I don't think functions and classes can make things too much more complicated, so long as the build files can't share those definitions outside the file (which could lead to an ad hoc and hidden library). Something like open() seems perhaps more dangerous in terms of creating hard-to-understand dependencies. Doing strict type checks on the resulting data would be a good check. E.g., you don't want a file to return a clever str subclass that overrides equality. _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
