Будет ли безопасно использовать пакет python-shell для создания онлайн-песочницы Python, если бэкенд работает на Node.js без применения Docker контейнеров? Может ли передача пользовательского кода напрямую в python-shell как-то негативно повлиять на систему, или он достаточно изолирован?
Использование `python-shell` для запуска кода напрямую на сервере Node.js без дополнительных мер предосторожности может быть небезопасным. Пакет `python-shell` позволяет взаимодействовать с Python скриптами и интерпретатором, исполняя команды и обрабатывая вывод, но он сам по себе не предоставляет полной изоляции от операционной системы хоста. Python-код, запущенный через `python-shell`, может иметь доступ ко всем ресурсам системы, к которым имеет доступ Node.js процесс. Это означает, что ненадежный пользовательский код может: 1. Читать и записывать файлы на сервере (в рамках разрешений процесса Node.js). 2. Использовать сеть для отправки и получения данных. 3. Запускать долгие или ресурсоемкие процессы, которые могут повлиять на производительность сервера. 4. Возможно, эксплуатировать уязвимости в системе или самом Node.js. Для безопасной работы онлайн-песочницы рекомендуется использовать более строгие методы изоляции, такие как: 1. **Docker контейнеры:** Запуск каждой пользовательской сессии в отдельном контейнере может предотвратить многие виды атак и ограничить воздействие на основную систему. 2. **Ограничение прав:** С помощью системных вызовов, таких как seccomp в Linux, можно установить строгие ограничения на операции, которые могут выполняться из песочницы. 3. **Проверка кода:** Предварительная проверка или ограничение выполняемого кода с целью исключения потенциально опасных операций. 4. **Ограничение ресурсов:** Использование cgroups в Linux для ограничения использования CPU, памяти и других ресурсов каждым процессом. Идеальное решение будет зависеть от конкретных требований к безопасности и затрат на инфраструктуру. Если выбран путь без использования Docker или других форм виртуализации, очень важно провести тщательный аудит системы на предмет безопасности и регулярно обновлять её, чтобы предотвратить возможные атаки через песочницу.
Не думаю, он создаёт дочерний процесс от ноды, но в доках не написано, что этому процессу задаются особые права - значит, права будут как у ноды.
Я бы сделал минимум три уровня защиты:
1. Полученный от пользователя скрипт выполняется не напрямую, а в скрипте-обёртке. Обёртка подписывается на события аудита Питона, и мониторит событие импорта. При попытке импорта модуля не из белого списка сигнализируем родительскому процессу и вызываем заранее сохранённую os._exit() , чтобы немедленно прибить интерпретатор. Также на обёртку можно возложить собственно прогон тестов.
2. Скрипт-обёртка должен выполняться от nobody:nobody с правами только на временную директорию, в которой лежит сам скрипт и его виртуальное окружение. Директория должна пересоздаваться заново при каждом запуске скрипта. Может иметь смысл оформить выполнение обёртки внутри chroot.
3. Выполнение должно происходить внутри контейнера, который должен ребилдиться время от времени (не обязательно при каждом запуске скрипта, можно раз в сутки или около того). Передача скрипта внутрь контейнер - через сетевой сервис, хотя можно и через примонтированную директорию. Внутри контейнера сервис сам создаёт временную директорию с окружением, переносит скрипт в эту директорию (с переименованием в заранее известное имя - user_script.py или подобное) и только тогда запускает обёртку.
В этом случае атакующему нужно будет сначала обойти аудит импортов, потом сделать эскалацию привилегий, потом выбраться из-под chroot. И даже если он закрепится в контейнере, контейнер периодически ребилдится, так что малварь будет снесена.
можно. если не запускать от рута.
можно и отдельно ограничить.