Игра в песочнице в Linux

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

Таким образом вы можете на некоторое время избежать вашего уровня взлома.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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