Выполнение потенциально вредоносной программы в Linux

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

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

Может ли кто-нибудь помочь мне с выбором правильного подхода? Безопасность - большая проблема для меня. С другой стороны, я не хочу, чтобы решение было излишним и тратило бы много времени на то, чтобы научиться тому, что мне действительно не нужно.

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

• Другой вариант, даже для более высокой безопасности, чем у виртуальной машины: загрузите «живой» CD / DVD / pendrive без доступа к жесткому диску (временно отключите жесткий диск в BIOS; если вы не можете, по крайней мере, не монтируйте диск / размонтировать его, если он монтируется автоматически - но это гораздо менее безопасно)

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

• Существуют такие программы, как isolate , которые создадут специальную защищенную среду - обычно ее называют песочницей, - как правило, основанную на chroot, с дополнительным контролем - найдите ту, которая подходит вам.

• Простой chroot будет наименее безопасным (особенно в отношении выполнения программ), хотя, может быть, немного быстрее, но ... Вам нужно будет создать / скопировать целое отдельное корневое дерево и использовать привязку для монтирования /devи т. Д. (См. Примечание. 1 ниже!). Поэтому в целом такой подход не может быть рекомендован, особенно если вы можете использовать более безопасную и часто более простую в настройке sandboxсреду.

Примечание 0: к аспекту «специального пользователя», такого какnobodyучетная запись: это практически не обеспечивает безопасности, намного меньше, чем даже простойchroot. nobodyПользователь может еще файлы и программы доступакоторые читали и выполнять полномочияустановленные для другого . Вы можете проверить это сsu -s /bin/sh -c 'some command' nobody. И если у вас есть файл конфигурации / истории / кэша, доступный любому (по ошибке или незначительной дыре в безопасности), программа, работающая сnobodyразрешениями, может получить к ней доступ, grep для конфиденциальных данных (например, «pass =» и т. Д.) много способов отправить его по сети или что-то еще.

Примечание 1: Как указал Жиль в комментарии ниже , простая среда chroot обеспечит очень низкую защиту от эксплойтов, направленных на повышение привилегий. Подошва корневым имеет смыслзрения безопасности, только если среда минимальна, состоящая из безопасности подтвержденных программ только (нопрежнему остается риск использования потенциальных уязвимостейуровне ядра), и все ненадежные программызапущенные в изолированном окружении работают как пользователь, который не запускает никаких процессов вне chroot. Что предотвращает chroot (с упомянутыми здесь ограничениями), так это прямое проникновение в систему без повышения привилегий. Однако, как отметил Жиль в другом комментариидаже этот уровень безопасности может быть обойден, позволяя программе выйти из chroot.

Используйте виртуальную машину. Все, что меньше, не обеспечивает большую безопасность.

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

Я бы порекомендовал запустить VirtualBox. Вы можете настроить виртуальную машину за пару минут, а затем установить в нее дистрибутив Linux. Единственная нестандартная настройка, которую я рекомендую, это настройка сети: создайте интерфейс «NAT» (для связи с миром) и интерфейс «только для хоста» (чтобы вы могли легко копировать файлы на хост и с хоста, а также ssh в ВМ). Отключите интерфейс NAT во время работы программ ваших студентов¹; включайте его только при установке или обновлении пакетов программного обеспечения.

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

¹ _{Вы можете ограничить интерфейс NAT в белый список пользователей, но это более продвинутые , чем вам нужно в простой, установка на-точка.}

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

это не более чем миф о том, что Chroot не является средством защиты. Существуют инструменты, которые автоматически создадут файловую систему chroot, а Chroot встроен во многие основные приложения в качестве целенаправленной функции безопасности.

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

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

Удалите все небезопасные приложения, двоичные файлы setuid, висячие бессимвольные символические ссылки / жесткие ссылки. перемонтируйте ненужные папки, используя nosuid, noexec и nodev. собрать последнюю стабильную версию работающего демона из исходного кода. и, самое главное, обезопасить базовую систему!

Я собираюсь добавить это, вскоре после того, как на вопрос будет официально дан ответ: MAGIC: Malicious Aging in Circuits / Cores , который, к сожалению, заблокирован за платным доступом ACM. Результатом работы является то, что следы очень малой ширины в цепях, используемых сегодня, стареют во время использования и в конечном итоге выходят из строя. Найдя правильные инструкции и повторяя их снова и снова, злоумышленник может быстро прекратить работу IC.

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

В Unix, производных от BSD (включая Mac OS X) есть средство, которое называется sandbox. На странице написано

ОПИСАНИЕ
Средство песочницы позволяет приложениям добровольно ограничивать доступ к ресурсам операционной системы. Этот механизм безопасности предназначен для ограничения потенциального ущерба в случае использования уязвимости. Это не замена для других средств контроля доступа операционной системы.

Это отдельно от chrootобъекта, который также доступен.