Проверка исходников python с целью ограничить им доступ к классам проекта?

Question

[rPman]

Есть ли механизмы, и какие могут быть подводные камни, если для создания модульного проекта с абсолютным разграничением прав доступа между модулями и доступа к объектам проекта и системы просто не подключать 'опасные' модули в коде.


Если сложно/глупо/не реально разработать виртуальную машину для разграничения прав доступа (а разделять на отдельные процессы может оказаться не выгодным, не говоря уж о проблеме ограничения доступа к системе), то…

Есть ли какие-либо механизмы по статическому анализу исходных кодов программы python, с целью выявить попытки обойти организационные ограничения (если нельзя запретить автоматически, то можно договориться с программистами, чтобы они не использовали запрещенные модули/объекты/классы) а так же опасные встроенные функции.


Достаточно ли будет проанализировать код программы на основные лексемы и выявить выполнение динамического кода (тот же eval который далеко не безопасен). Какие инструментарии имеются на этот счет?


Достаточно ли проверить набор import в коде программы, чтобы гарантировать, что программа не сможет вызвать запрещенные методы динамически подключив модуль?


Нет ли опасности что модуль сумеет как-то получить доступ к объектам (обратиться к его методам), созданным в другом модуле, не подключенном в import, кроме как через специально предоставленный объект-прослойку.

Answer 1

[MikhailEdoshin]

Если модуль импортирует sys, то он может добраться до уже импортированного модуля через sys.modules, не используя явный import. Плюс у каждой питоновской функции есть func_globals, ссылка на словарь модуля, в котором она определена. Со всем содержимым модуля, естественно. Так что если вы передаете безопасную питоновскую функцию из опасного модуля, можно будет получить доступ ко всему модулю, и, соответственно, по цепочке ко всем другим модулям из которых тот что-то импортировал.

Comments

[MikhailEdoshin]

P.S. А импортируют модули много и часто. У меня в проекте есть анализ связей между модулями, так полные зависимости модуля для работы с zip-архивами — около 200 модулей. (Это если судить по import'ам; при обычной работе импортируется куда меньше, потому что часть импортов условные, включая те, что активируются только если модуль выполняется, как скрипт (__name__ == "__main__")).

[MikhailEdoshin]

С другой стороны, если завернуть это в C-объект или функцию… И даже где-то был подобный модуль, но не могу вспомнить названия.

[rPman]

Можно запретить sys, а разрешить только sys.требуемый подмодуль.

Answer 2

[rPman]

Мне тут подсказали github.com/haypo/pysandbox по уму очень интересный проект…

Думаю это и будет решением

Но всплывают еще небольшие неудобства — это установка на клиенте.
Если сам питон ванильный установить не проблема, то это дополнение ставить уже сложнее (как я понял это дополнение к питону собирается при установке — т.е. нужны нативные бинарники)… вся идея проекта, распространение модулей между пользователями максимально просто для них, и с какими то гарантиями, что каждый новый модуль не сможет выйти из песочницы.