Существует ли "безопасное" подмножество Python для использования в качестве встроенного языка сценариев?
Во многих приложениях Python, которые я создал, я часто создаю простые модули, содержащие только константы, которые будут использоваться в качестве конфигурационных файлов. Кроме того, поскольку файл конфигурации на самом деле является файлом кода Python, я могу добавить простую логику для изменения переменных в зависимости от уровня отладки и т. Д.
Хотя это прекрасно работает для внутренних приложений, я бы с осторожностью выпустил такие приложения на волю, опасаясь, что кто-то случайно или злонамеренно добавит в файл деструктивный код. То же самое относится и к использованию Python в качестве встроенного языка сценариев.
Существует ли подмножество Python, которое считается "безопасным" для встраивания? Я понимаю, насколько безопасно это можно считать довольно субъективным. Тем не менее, Java-апплеты и Flash имеют четко определенную изолированную программную среду безопасности Мне интересно, есть ли версия Python с похожими правилами?
РЕДАКТИРОВАТЬ: я спрашиваю не столько из-за подхода файла конфигурации, а потому, что я заинтересован в реализации некоторых механизмов сценариев / плагинов в более новом приложении и не хочу, чтобы плагин или сценарий могли, скажем, удалять файлы. Это выходит за рамки того, что приложение должно уметь делать.
12 ответов
Вот пара ссылок, чтобы дать вам представление о том, с чем вы столкнулись:
- Как я могу безопасно запустить ненадежный скрипт Python (например, песочницу)
- Возможности для Python? сам Гвидо
На http://code.google.com/p/sandbox-python/ также есть проект мертвого кода Google.
Нет, не существует готового к производству подмножества Python, которое является "безопасным". В Python было несколько модулей песочницы, которые устарели из-за недостатков.
Лучше всего либо создать свой собственный парсер, либо изолировать процесс python с помощью перехватчиков syscall и заблокированной учетной записи.
Некоторые люди могут указать вам на PyPy, но он медленный и незавершенный.
Виртуальная машина PyMite отвечает всем требованиям, если все, что вам нужно сделать, это установить простые переменные, циклы, условия и функции. PyMite крошечный, написан на C, использует статический пул памяти и может быть встроен. Он имеет чрезвычайно ограниченный набор встроенных функций, которые легко настроить. Точно так же единственными стандартными библиотеками являются частичные реализации string, dict, list и sys. Виртуальная машина PyMite является частью проекта python-on-a-chip, поэтому она была разработана для работы на микроконтроллерах, но может работать на настольных системах в стиле posix. Недостатком является то, что PyMite не так сильно отлажен, как другие реализации Python.
Проект pypy предлагает функции песочницы, см. http://doc.pypy.org/en/latest/sandbox.html.
tinypy ( http://tinypy.org/) был создан, чтобы быть небольшим, встраиваемым подмножеством Python, написанным в стиле Lua. И так как у lua есть способ создать песочницу, я считаю, что tinypy можно взломать в том же духе. Поскольку база кода tinypy настолько мала, ее довольно легко изучить и выяснить, как изменить ситуацию в соответствии с вашими потребностями.
AFAIK, некоторые попытки были сделаны в стандартной библиотеке Python, но они не увенчались успехом. См. Ограниченное выполнение для деталей.
Предупреждение
В Python 2.3 эти модули были отключены из-за различных известных и не легко исправляемых дыр в безопасности. Модули все еще задокументированы здесь, чтобы помочь в чтении старого кода, который использует модули rexec и Bastion.
Немного трудно понять, что вы пытаетесь сделать - недостаточно подробностей.
Вы размещаете нативное приложение и позволяете пользователям писать плагины? Подумайте об использовании решения на уровне ОС, запустив приложение Python как отдельный процесс выполнения внутри jail / chroot / аналогичного и установив связь через сокеты.
Ожидаете ли вы, что ваши клиенты будут размещать собственное приложение и позволять "ненадежным сторонам" писать плагины? Есть ли причина, по которой вышеприведенное решение не сработает? (Например, клиент хотел бы развернуть на странных ОС без таких опций...)
Ожидаете ли вы, что те же люди разместят нативное приложение и "ненадежный скрипт" и захотят защитить их от самих себя? В смысле защиты их от написания "os.remove" и заставить его делать то, что они написали? Вы можете объяснить, почему?
Обратите внимание, что одной песочницы часто недостаточно без более строгих ограничений (максимальные циклы ЦП, максимальная память, проблемы с владением памятью...)? Какую вредоносность вы хотите остановить? Обратите внимание, что и здесь ОС обладают замечательными возможностями (приоритетами, процессами уничтожения, ограничениями), которые копируются не во всех средах "песочницы", и, безусловно, менее проверены на безопасность, чем в ОС. (Я бы поверил, что у Linux не будет хрупких предельных значений, прежде чем я буду доверять PyPy, чтобы он не позволял злонамеренному кодеру занимать неограниченное количество памяти, просто потому, что Linux подвергался атакам в дикой природе)
starlark - это подмножество Python, реализованное в go.
Он используется Google в качестве языка конфигурации для Bazel, своего инструмента сборки. Документов / подробностей об этом крайне мало, но, возможно, это соответствует всем требованиям.
Я не очень хорошо знаю, какие именно функции безопасности вы получаете в среде виртуальной машины Java или.NET, но вы можете подумать, может ли запуск кода на Python с Jython или IronPython позволить вам получить дополнительную безопасность.
Вы можете попробовать IronPython на Silverlight/Moonlight, как кажется, делают эти парни. Здесь много полезной информации об этих типах приложений IronPython от разработчиков Resolver One.
Я бы с осторожностью выпускал такие приложения в дикую природу, опасаясь, что кто-то случайно или злонамеренно добавит в файл деструктивный код.
Ваш нативный код, который "в дикой природе", одинаково уязвим для этой атаки; то, что это в машинном коде, является просто ударом скорости, и никакой безопасности.
Если вы крайне параноидальны и хотите увеличить скорость, вы можете заставить свое собственное приложение, в котором размещается экземпляр скрипта, проверять хэш содержимого. Тогда случайные изменения невозможны; только преднамеренные изменения могут привести к обновлению контрольной суммы. Вы можете пойти дальше и проверить, что они тоже подписаны открытым ключом; тогда только взлом вашего нативного приложения может пустить новые скрипты.
Но песочница? Не беспокойся об этом!
Это звучит как то, что вы хотите: Reviving Python ограниченный режим.
Интерпретатор Python имеет встроенный "ограниченный" режим, включаемый путем изменения __builtins__ магическая переменная. Статья, прокладывающая путь к обеспечению безопасности интерпретатора Python, объясняет хитрость более подробно. Обратите внимание, что для полноценной работы требуется патч для интерпретатора Python; Я не знаю, было ли оно уже применено.
Для полной проверки концепции Python см. Его предыдущий пост "Задача взломать безопасность Python".
Для некоторого обсуждения вопросов, ранее встречавшихся с rexec модуль:
- http://mail.python.org/pipermail/python-dev/2002-December/031160.html
- http://mail.python.org/pipermail/python-dev/2003-January/031848.html
Они пришли из HOWTO об ограниченном исполнении.