Как сайты, такие как codepad.org и ideone.com, изолируют вашу программу?

Ответ 1

У codepad.org есть что-то, основанное на geordi, которое запускает все в chroot (т.е. ограничено поддеревом файловой системы) ограничения ресурсов и использует API ptrace, чтобы ограничить ненадежное использование системными вызовами. См. http://codepad.org/about.

Ранее я использовал Systrace, еще одну утилиту для ограничения системных вызовов.

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

Ответ 2

Некоторое время назад я искал решение для песочницы для использования в автоматизированной системе оценки заданий для студентов CS. Как и все остальное, существует компромисс между различными свойствами:

• Зеркальность выделения и контроля доступа
• Производительность и простота установки/конфигурации

В конце концов я решил создать многоуровневую архитектуру на основе Linux:

• Уровень 0 - Виртуализация:

  Используя один или несколько снимков виртуальной машины для всех назначений в течение определенного временного диапазона, можно было получить несколько преимуществ:

  • Четкое разделение чувствительных от нечувствительных данных.

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

  • Первый уровень изоляции компьютерных ресурсов: каждая виртуальная машина имеет ограниченные ресурсы диска, процессора и памяти, а хост-компьютер недоступен напрямую.

  • Прямая фильтрация по сети: имея виртуальную машину на внутреннем интерфейсе, брандмауэр на хосте может выборочно фильтровать сетевые подключения.

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

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

• Уровень 1 - основные противопоказания:

  В операционной системе Unix, которая будет содержать традиционные механизмы управления доступом и ресурсами:

  • Каждая изолированная программа может выполняться как отдельный пользователь, возможно, в отдельной тюрьме chroot.

  • Строгие пользовательские разрешения, возможно, с ACL.

  • ulimit ограничения ресурсов на время процессора и использование памяти.

  • Выполнение в nice для уменьшения приоритета над более критическими процессами. В Linux вы также можете использовать ionice и cpulimit - Я не уверен, какие эквиваленты существуют в других системах.

  • Квоты для диска.

  • Фильтрация соединений между пользователями.

  Вероятно, вы захотите запустить компилятор как немного более привилегированный пользователь; больше памяти и времени процессора, доступ к инструментам компилятора и файлам заголовков e.t.c.

• Уровень 2 - Расширенные ограничения операционной системы:

  В Linux я считаю, что использование Linux Security Module, например AppArmor или SELinux, чтобы ограничить доступ к определенным файлам и/или системным вызовам. В некоторых дистрибутивах Linux есть некоторые профили безопасности для песочницы, но это может быть долгим и болезненным процессом, чтобы нормально работать над этим.

• Уровень 3 - Решения для песочницы для пользовательского пространства:

  Я успешно использовал Systrace в небольшом масштабе, как упоминалось в этом старше мой ответ. В Linux есть несколько других решений для песочницы, таких как libsandbox. Такие решения могут обеспечить более мелкозернистый контроль над системными вызовами, которые могут использоваться, чем альтернативы на основе LSM, но могут оказывать заметное влияние на производительность.

• Уровень 4 - Упреждающие удары:

  Поскольку вы будете сами компилировать код, а не выполнять существующие двоичные файлы, у вас есть несколько дополнительных инструментов в ваших руках:

  • Ограничения на основе кодовых показателей; например простая программа "Hello World" никогда не должна превышать 20-30 строк кода.

  • Селективный доступ к системным библиотекам и файлам заголовков; если вы не хотите, чтобы ваши пользователи вызывали connect(), вы можете просто ограничить доступ к socket.h.

  • Анализ статического кода; запретить ассемблерный код, "странные" строковые литералы (т.е. оболочечный код) и использование ограниченных системных функций.

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

• Уровень 0-5 - Мониторинг и протоколирование:

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

  • призвание любых должностных лиц безопасности отвечает за такие проблемы.

  • нахождение этого настойчивого маленького хакера и предложение им задания.

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

Ответ 3

Я разработчик libsandbox, упомянутый @thkala, и рекомендую его для использования в вашем проекте.

Некоторые дополнительные комментарии к ответу @thkala,

• справедливо классифицировать libsandbox в качестве инструмента пользовательских земель, но libsandbox интегрирует стандартные механизмы безопасности на уровне ОС (например, chroot, setuid и квоту ресурсов);
• Ограничение доступа к заголовкам C/С++ или статический анализ кода пользователя не предотвращает вызов системных функций, таких как connect(). Это связано с тем, что пользовательский код может (1) самостоятельно объявлять прототипы функций, не включая системные заголовки, или (2) ссылаться на базовые системные вызовы ядра без привязки к функциям оболочки в libc;
• защита от компиляции также заслуживает внимания, потому что вредоносный код на C/С++ может исчерпать ваш процессор с бесконечной рекурсией шаблона или расширением макроса предварительной обработки;