Как вы контролируете, управляете и запускаете ненадежный сторонний код в размещенной службе?

Question

Допустим, у меня запущенный сервис, который хочет разрешить плагины, написанные сторонними клиентами.

Возможно, поставщик игровых услуг, который предоставляет инфраструктуру, но позволяет клиентам разрабатывать своих собственных игровых судей. Или сайт конкурса кодирования, который позволяет кодировщикам предоставлять код для запуска в качестве решения какой-то проблемы с кодированием.

Как бы вы защитили / заблокировали / изолировали / запретили этот пользовательский код от нанесения потенциального вреда серверу, который намеревается его запустить?

Как бы вы контролировали и ограничивали использование ресурсов (ЦП, память в основном)?

Это хорошее начало для Python, но мне интересно, если у кого-нибудь здесь есть более специфический опыт, которым он может поделиться независимо от языка (Python, Lua, Ruby и т. Д.) .

Answer 1

RestrictedPython (показано по указанной вами ссылке) выглядит многообещающе. Однако я не могу сказать, что на самом деле пытался сделать это.

Еще один вариант, который может сработать, - это создать чрезвычайно минимальный дистрибутив Linux, а затем реплицировать его в виртуализированной среде для каждого пользователя. Используйте механизмы мониторинга виртуальной машины, чтобы ограничить использование процессора и памяти путем приостановки виртуальной машины, как только ресурсы достигнут определенного уровня. Если бы вы сделали дистрибутив достаточно маленьким, сама виртуальная машина не сильно повлияла бы на ресурсы, но я бы подумал, что для такого решения вам все равно понадобится достаточно большой объем ОЗУ (просто для безопасности ).

Только мои 2 цента. Хотя я не эксперт по Python.

Answer 2

Вероятно, невозможно быть на 100% безопасным , но chroot'ing - хорошее начало. Я использую несколько скриптов на своих серверах, запущенных в тюрьмах chroot'd. Один сценарий стал жертвой атаки (я упустил из виду довольно хитрую лазейку - упс!), И хотя проникший нарушил сценарий, тюрьма помешала им нанести дальнейший урон.

Если вы опускаете вариант минимального Python, взгляните на Minimal Python .

Answer 3

FWIW, Apache / mod_wsgi версия 3.0 может запускать процессы в режиме демона в среде chroot.

Если вас интересует только попытка защитить основную операционную систему, то это один из возможных компонентов, способных сделать это.

Если вы также хотите запретить пользователям вмешиваться в код других пользователей, и может быть произвольное количество пользователей, которые могут динамически меняться, тогда это сложнее, хотя Apache / mod_wsgi еще не имеет возможности динамических групп процессов демона вместо этого полагается на статическую конфигурацию.

Answer 4

У Луа лучшая песочница и сторожевой таймер, которые я когда-либо видел. Мой принимающий язык Python. Таким образом, я решил пойти с Lunatic Python .

Answer 5

Возможно, вы захотите сделать что-то вроде следующего:

1. Скомпилируйте входящий код, чтобы выбрать ВСЕ import операторы и ограничить то, что можно импортировать.

2. Проверьте также использование функций _import_ и reload.

3. Определите API для этих модулей, который позволяет им запускаться как отдельный процесс, заключенный в предоставляемый вами легкий сервер WSGI. Разделяйте их как подпроцессы и взаимодействуйте через API вашего сервера. Если они сломаются или зависнут, вы обнаружите это по таймауту.