Будет ли безопасно использовать пакет 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 или других форм виртуализации, очень важно провести тщательный аудит системы на предмет безопасности и регулярно обновлять её, чтобы предотвратить возможные атаки через песочницу.
Не думаю, он создаёт дочерний процесс от ноды, но в доках не написано, что этому процессу задаются особые права - значит, права будут как у ноды. <br/> <br/> Я бы сделал минимум три уровня защиты: <br/> 1. Полученный от пользователя скрипт выполняется не напрямую, а в скрипте-обёртке. Обёртка подписывается на <a href="https://docs.python.org/3.9/library/audit_events.html?highlight=import" rel="nofollow">события аудита</a> Питона, и мониторит событие импорта. При попытке импорта модуля не из белого списка сигнализируем родительскому процессу и вызываем <i>заранее сохранённую</i> <a href="https://docs.python.org/3.9/library/os.html#os._exit" rel="nofollow">os._exit()</a> , чтобы немедленно прибить интерпретатор. Также на обёртку можно возложить собственно прогон тестов. <br/> 2. Скрипт-обёртка должен выполняться от nobody:nobody с правами только на временную директорию, в которой лежит сам скрипт и его виртуальное окружение. Директория должна <i>пересоздаваться заново</i> при каждом запуске скрипта. Может иметь смысл оформить выполнение обёртки внутри chroot. <br/> 3. Выполнение должно происходить внутри контейнера, который должен ребилдиться время от времени (не обязательно при каждом запуске скрипта, можно раз в сутки или около того). Передача скрипта внутрь контейнер - через сетевой сервис, хотя можно и через примонтированную директорию. Внутри контейнера сервис сам создаёт временную директорию с окружением, переносит скрипт в эту директорию (с переименованием в заранее известное имя - user_script.py или подобное) и только тогда запускает обёртку. <br/> <br/> В этом случае атакующему нужно будет сначала обойти аудит импортов, потом сделать эскалацию привилегий, потом выбраться из-под chroot. И даже если он закрепится в контейнере, контейнер периодически ребилдится, так что малварь будет снесена.
можно. если не запускать от рута. <br/> можно и отдельно ограничить.