Проблемы безопасности Python на основе веб-интерпретатора

Question

Я делаю веб-интерпретатор Python, который принимает код, исполняет его на Linux-интерпретаторе Python3 и выдает результат на той же веб-странице. Но у этого есть серьезные дыры в петлях, например, кто-то может выполнить скрипт bash с помощью модуля os python, может проверить каталог на наличие исходного кода веб-приложения и многое другое.

Может кто-нибудь подсказать мне, как предотвратить подобные неудачи в моем приложении Привет

Answer 1

Краткий ответ: для этого нет простого решения "только для Python".

Некоторые детали:

• пользователь всегда может попытаться позвонить os,sys, with open(SENSITIVE_PATH, 'rw') as f: ... и т. Д., И все эти случаи трудно обнаружить, просто проанализировав код

• Если вы разрешите ЛЮБОМУ стороннему, то все станет еще сложнее,например, какой-то сторонний пакет может локально создать псевдоним os.execv (os_ex = os.execv), и после этого можно будет написать скрипт, подобный from thirdparty.some_internals import os_ex; os_ex(...).

Более или менее надежным решением является использование решений «внешней песочницы»:

• Запуск интерпретатора в непривилегированном док-контейнере.Например:

  1. записать ненадежный скрипт в какой-либо файл, который будет отображаться через том в контейнере докера

  2. выполнить этот скрипт в докере:

     a,subprocess.call(['docker', 'exec', 'CONTAINER_ID', '/usr/bin/python', 'PATH_TO_SCRIPT'])

     б.subprocess.call(['docker', 'exec', 'CONTAINER_ID', '/usr/bin/python', '-c', UNTRUSTED_SCRIPT_TEXT])

• Использование PyPy-s песочница .

• Поиск некоторых "безопасных" Ядро IPython для сервера ноутбуков Jupyter .Или написать свой .Примечание: существующие ядра не гарантируются безопасными и могут позволять вызывать subprocess.check_output, os.rm и другие.Так что для «ядра по умолчанию» все же лучше запустить сервер Jupyter в изолированной среде.
• Запустить интерпретатор в chroot, используя непривилегированного пользователя.Разные реализации имеют разный уровень «безопасности».
• Использование Jython с тонко настроенными разрешениями .
• Некоторые экзотические решения, такие как «реализация JS python на стороне клиента»: brython , pyjs

В любом случае, даже если вам удастся внедрить или повторно использовать существующую «песочницу», у вас все равно будет много потенциальных проблем:

• Если разрешена многопроцессорная обработка или многопоточность, вы можете отслеживать использование ресурсов процессора, поскольку некоторые сценарии могут захотеть использовать ВСЕ.Даже с GIL многопоточность может использовать все ядра (все, что нужно сделать пользователю, это вызвать функции, использующие c-библиотеки в потоках)
• Возможно, вы захотите контролировать использование памяти, потому что некоторые сценарииможет произойти утечка или просто использовать много памяти
• Другие кандидаты для мониторинга: использование дискового ввода-вывода, использование сети, использование открытых файловых дескрипторов, время выполнения и т. д. *
• Также вы всегда должны проверятьдля обновлений безопасности вашего «решения для песочницы», потому что даже докер иногда уязвим и делает возможным выполнение кода на хост-машине

Рекомендуется прочитать: https://softwareengineering.stackexchange.com/questions/191623/best-practices-for-execution-of-untrusted-code