Checking python sources to restrict their access to project classes?

Question

Python

Are there mechanisms, and what can be pitfalls, if to create a modular project with absolute differentiation of access rights between modules and access to project and system objects, simply do not include 'dangerous' modules in the code.
If it is difficult/stupid/unrealistic to develop a virtual machine to differentiate access rights (and it may not be profitable to divide it into separate processes, not to mention the problem of restricting access to the system), then ...
Are there any mechanisms for static analysis of program source codes python, in order to identify attempts to circumvent organizational restrictions (if it is impossible to prohibit automatically, then you can agree with programmers so that they do not use prohibited modules / objects / classes) as well as dangerous built-in functions .
Will it be enough to analyze the program code for the main tokens and identify the execution of dynamic code (the same eval which is far from safe). What tools are available for this?
Is it enough to check the import set in the program code to ensure that the program cannot call forbidden methods by dynamically linking the module?
Is there any danger that the module will somehow be able to access objects (refer to its methods) created in another module that is not included in import, except through a specially provided layer object.

Answer 1

If a module imports sys, then it can reach the already imported module via sys.modules, without using an explicit import. Plus, each Python function has a func_globals, a reference to the dictionary of the module in which it is defined. With all the contents of the module, of course. So if you pass in a safe Python function from a dangerous module, you can access the entire module, and by extension, all the other modules it has imported.

Answer 2

I was prompted here github.com/haypo/pysandbox by the mind is a very interesting project ...
I think this will be the solution.
But there are still small inconveniences - this is installation on the client.
If the vanilla python itself is not a problem to install, then it is already more difficult to install this add-on (as I understand it, this add-on to python is assembled during installation - that is, native binaries are needed) ... the whole idea of ​​​​the project, distributing modules between users is as simple as possible for them, and with some kind of guarantee that each new module will not be able to get out of the sandbox.