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

33

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

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

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

Корда
источник
7
Просто запустите программу в Linux в браузере ( bellard.org/jslinux ). Это очень хорошая песочница. :)
Fixee
вау, это действительно интересно! однако я должен был бы написать какой-то интерфейс, чтобы использовать его (поскольку весь процесс будет автоматическим) ... Мне нужно проверить это. Если окажется, что этот Javascript Linux - больше, чем гаджет, я могу даже использовать его.
Корда
Я действительно задумал свой комментарий как шутку, но если вы действительно сможете его использовать, это было бы замечательно. Честно говоря, ответ LiveCD (с RAMdisk) - отличное решение.
Fixee
Ну, если бы мне удалось использовать его, я бы также использовал его на веб-странице, на которой я могу получить доступ к результатам - это было бы очень приятно и удобно. Также учитывается фактор гика;) также и живой диск не вариант - как я уже говорил, я создаю программу, которая будет работать на каком-то сервере, поэтому перезагрузка - это не то, что я могу себе позволить ... Думаю, я все равно буду придерживаться виртуальной машины. ..
Корда

Ответы:

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

  • Другой вариант, даже для более высокой безопасности, чем у виртуальной машины: загрузите «живой» 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.

rozcietrzewiacz
источник
Спасибо за ответ. Я настоящий новичок, когда дело доходит до таких вещей, не могли бы вы объяснить мне одну вещь: почему мне нужно запретить программе читать файлы в системе (например, с помощью chroot)? (если программа не может их изменить).
Корда
Краш теста счет пользователя дает вам некоторую базовую безопасность наверняка. Тем не менее, есть ряд вещей, которые вы можете / должны предотвратить. Это могут быть эксплойты общих уязвимостей, встроенных в программу, или некоторый социальный взлом, сбор информации с целью будущей удаленной атаки ... И, вероятно, намного больше.
rozcietrzewiacz
Почему мы это: есть ли способ запретить пользователю использовать интернет-соединение?
Корда
1
Интересно, nobodyесть ли доступ в интернет.
Корда
1
@rozcietrzewiacz Важное требование для chroot для обеспечения какой-либо защиты - не запускать программу chroot как пользователя, который также запускает программу вне chroot. В противном случае процесс chrooted может выполнить процесс без поддержки chroot и делать что-либо таким образом.
Жиль "ТАК - перестань быть злым"
10

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

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

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

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

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

Жиль "ТАК - перестань быть злым"
источник
2

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

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

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

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

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

RapidWebs
источник
2

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

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

Брюс Эдигер
источник
1

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

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

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

dmckee
источник