Песочница в Linux

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

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

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

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

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

ОТВЕТЫ

Ответ 2

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

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

Интересной частью является то, как безопасно обрабатывать выполнение.

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

Ответ 10

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

Ответ 11

Ограничение на основе ptrace для ненадежных программ может быть использовано, как описано в 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

Ответ 12

О единственном шансе, который у вас есть, - запустить VirtualMachine, и у них могут быть уязвимости. Если вы хотите, чтобы ваш компьютер был взломан в краткосрочной перспективе, просто используйте разрешения и создайте специального пользователя с доступом, возможно, к одному каталогу. Если вы хотите отложить взлом в какой-то момент в будущем, запустите веб-сервер внутри виртуальной машины и перейдите к нему. Вы хотите сохранить резервную копию этого, потому что вы, вероятно, будете взломать его через час и хотите перезапустить новую копию каждые несколько часов. Вы также захотите сохранить изображение всей машины, чтобы разглядеть все это раз в неделю или около того, чтобы преодолеть еженедельные хаки. Не позволяйте этой машине разговаривать с любой другой машиной в вашей сети. Черный список - повсюду. Я говорю о виртуальной машине и IP-адресах физической машины. Регулярно проводите проверки безопасности на любых других компьютерах на других компьютерах в сети. Переименуйте машины IHaveBeenHacked1 и IHaveBeenHacked2 и запретите доступ к тем из списков хостов и брандмауэров.

Таким образом, вы можете немного приостановить свой уровень хака.