Песочница в Linux - PullRequest
       83

Песочница в Linux

16 голосов
/ 19 июня 2009

Я хочу создать веб-приложение, которое позволит пользователю загружать некоторый код на C и видеть результаты его выполнения (код будет скомпилирован на сервере). Пользователям не доверяют, что, очевидно, имеет огромное значение для безопасности.

Так что мне нужно создать какую-то песочницу для приложений. На самом базовом уровне я бы хотел ограничить доступ к файловой системе некоторыми указанными каталогами. Я не могу использовать chroot-тюрьмы напрямую, поскольку веб-приложение не запускается как привилегированный пользователь. Я предполагаю, что выполнимый suid, который устанавливает тюрьму, был бы выбором.

Загруженные программы будут довольно маленькими, поэтому они должны выполняться быстро (не более пары секунд). Следовательно, я могу завершить процесс после заданного времени ожидания, но как я могу гарантировать, что он не порождает новые процессы? Или, если я не могу, является ли уничтожение всего pgid надежным методом?

Как лучше всего это сделать, кроме как "вообще не делай этого"? :) Какие еще явные проблемы с безопасностью я пропустил?

FWIW, веб-приложение будет написано на Python.

Ответы [ 12 ]

5 голосов
/ 20 июня 2009

Наряду с другими предложениями вы можете найти это полезным.

http://www.eelis.net/geordi/

Это из http://codepad.org/about, codepad.org о странице.

4 голосов
/ 20 июня 2009

Из нескольких предоставленных вами сведений следует, что вы имеете административный контроль над самим сервером, поэтому мое предположение делает это предположение.

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

Самое интересное в том, как безопасно справиться с исполнением.

Моя операционная система - FreeBSD, поэтому я бы настроил предварительно сконфигурированный jail (не путать с vanilla chroot jail), который будет компилировать, запускать и сохранять выходные данные. Затем для каждой отправки исходного файла запускайте чистую копию тюрьмы для каждого выполнения с копией исходного файла внутри.

При условии, что jail / dev сокращен почти до нуля, ограничения системных ресурсов установлены безопасно, и что трафик не может маршрутизироваться из тюрьмы (связанный с unroutable адресом или просто firewalled), мне лично было бы удобно запустить это на сервере под моим руководством.

Поскольку вы используете Linux, я бы исследовал User Mode Linux или Linux-VServer, которые по своей концепции очень похожи на тюрьмы FreeBSD (я никогда не использовал их сам, но читал о них). Есть несколько других таких систем, перечисленных здесь .

Этот метод намного более безопасен, чем ванильная тюрьма для chroot, и он намного легче, чем использование полной виртуализации, такой как qemu / kvm или VMware.

Я не программист, поэтому я не знаю, какую AJAX-y вещь вы могли бы использовать для опроса результатов, но я уверен, что это можно сделать. Как администратор, я бы посчитал, что это интересный проект для участия. Веселитесь. :)

3 голосов
/ 20 июня 2009

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

3 голосов
/ 19 июня 2009

Я бы сказал, что это чрезвычайно опасно на многих уровнях. По сути, вы открываете себя для любого эксплойта, который можно найти в вашей системе (тогда как вы обычно ограничены тем, что люди могут использовать дистанционно). Я бы сказал, не делайте этого, если вы можете избежать этого.

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

2 голосов
/ 26 июля 2013

Полагаю, libsandbox служит вашей цели. Его основная библиотека написана для C / C ++, но также имеет оболочку для программ на Python. Он предоставляет опции для настройки того, какие системные вызовы могут быть разрешены, сколько памяти можно использовать, как долго можно запускать гостевую программу и т. Д. Он уже используется в нескольких сетевых экспертах, таких как HOJ,

2 голосов
/ 20 июня 2009

См. на этой странице о методах песочницы Google Chrome для Linux . Как вы можете видеть, существует множество методов, но ни один из них не подходит для таких распространяемых приложений, как Chrome, поскольку некоторые дистрибутивы могут их не включать. Это не проблема для веб-приложения, потому что вы можете контролировать то, что установлено на вашем сервере.

Лично мой любимый Seccomp , потому что он имеет очень низкие издержки по сравнению с другими инструментами, такими как ptrace (переключайте адресные пространства на каждый системный вызов!) или KVM (виртуальная машина, требующая большой памяти), и она невероятно проста по сравнению с такими инструментами, как SELinux (и, следовательно, с большей вероятностью безопасна).

2 голосов
/ 20 июня 2009

На Fedora 11 есть SELinux Sandbox , который, кажется, делает именно то, что вы хотите (за исключением, возможно, ограничения порождения новых процессов; в сообщении в блоге об этом не говорится).

Конечно, всегда есть риск ошибок в ядре; даже с SELinux части ядра по-прежнему доступны всем процессам.

1 голос
/ 19 июня 2009

Существует инструмент под названием strace - он отслеживает системные вызовы, сделанные данным процессом. Вам просто нужно следить за конкретными вызовами, предлагающими «незаконный» доступ к функции. AFAIK, это метод, используемый в соревнованиях по программированию для программ участников песочницы.

0 голосов
/ 17 апреля 2013

ptrace-based ограничение для ненадежных программ может использоваться как тот, который описан в http://www.cs.vu.nl/~rutger/publications/jailer.pdf, http://www.cs.vu.nl/~guido/mansion/publications/ps/secrypt07.pdf.

У них есть правило политики корневых изменений, CHRDIR, действие которого аналогично chroot. (Раздел «Тюремная политика»)

Однако они, возможно, не опубликовали свой исходный код (частично на основе модифицированного strace http://www.liacs.nl/~wichert/strace/ - Раздел «Реализация») ...

См. Также другие доступные основанные на ptrace подходы к chroot-in-userpace: https://unix.stackexchange.com/a/72697/4319

0 голосов
/ 25 марта 2013

Создание новой виртуальной машины под KVM или qemu для компиляции и запуска кода выглядит следующим образом. Запуск кода в Jail / LXC может поставить под угрозу машину, если она использует незащищенные части ОС, такие как сетевой код. Преимущество работы под виртуальной машиной очевидно. Можно взломать только ВМ, но не саму машину. Но побочный эффект заключается в том, что вам нужно много ресурсов (ЦП и память) для порождения виртуальной машины для каждого запроса.

...