Безопасный способ запуска кода других людей (песочница) на моем сервере?

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

Каков наилучший способ сделать это?

Запустить VMware/Virtualbox:

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

(+) может ограничить процессор и память, которые использует процесс

(+) легко настроить.. просто создайте VM

(-) сложнее "подключить" папку песочницы от хоста к гостевому

(-) тратит лишнюю память и процессор для управления VM

Запустить недопустимый пользователь:

(+) не тратит лишних ресурсов

(+) песочница - это просто обычный каталог

(?) не может ограничивать cpu и память?

(?) не знает, достаточно ли он защищен...

Любой другой способ?

Сервер, на котором запущены Fedora Core 8, "другие" коды, написанные на Java и С++

ОТВЕТЫ

Ответ 1

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

Ответ 2

Чтобы ограничить процессор и память, вы хотите установить лимиты для групп процессов (ограничения ресурсов POSIX применяются только к отдельным процессам). Вы можете сделать это с помощью групп.

Например, чтобы ограничить запуск памяти, установив файловую систему групп памяти:

# mount cgroup -t cgroup -o memory /cgroups/memory

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

# mkdir /cgroups/memory/my-users

Поместите процессы, которые вы хотите ограничить (процесс с PID "1234" здесь) в эту группу:

# cd /cgroups/memory/my-users
# echo 1234 >> tasks

Установите общий предел памяти для группы:

# echo 1000000 > memory.limit_in_bytes

Если процессы в дочерних процессах группы fork также будут в группе.

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

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

Ответ 3

Чтение страницы codepad.org/about может дать вам несколько интересных идей.

http://codepad.org/about

Ответ 4

chroot, jail, контейнер, VServer/OpenVZ/и т.д., как правило, более безопасны, чем запуск как непривилегированный пользователь, но более легкий, чем полная виртуализация ОС.

Кроме того, для Java вы можете доверять встроенной песочнице JVM, а для компиляции С++ NaCl утверждает, что может использовать песочницу x86 код.

Но, как говорится в ответе Checkers, было доказано, что в прошлом было возможно нанести вредоносный ущерб практически из любой "песочницы", и я ожидал, что в будущем будут обнаружены новые дыры (и, надеюсь, исправлены). Вы действительно хотите запустить ненадежный код?

Ответ 5

попробуйте использовать lxc в качестве контейнера для вашего сервера apache.

Ответ 6

Откажитесь от ulimit и друзей, чтобы ограничить обезвреживаемую способность пользователя к DOS машине.

Ответ 7

Попробуйте немного узнать о настройке политик для SELinux. Если вы используете окно Red Hat, вам хорошо идти, поскольку они упаковывают его в дистрибутив по умолчанию.

Это будет полезно, если вы знаете, к каким кодам не должен иметь доступ. Или вы можете сделать обратное, и только предоставить доступ к определенным вещам.

Однако эти политики сложны и могут потребовать больше инвестиций вовремя, чем вы можете пожелать.

Ответ 8

Используйте Ideone API - самый простой способ.

Ответ 9

Не уверен, сколько усилий вы хотите внести в эту вещь, но можете ли вы запустить Xen, как веб-хосты VPS?

http://www.xen.org/

Это позволит обеспечить полный доступ root на их маленьком фрагменте сервера без ущерба для других пользователей или базовой системы.