Осуществление возможно вредной программы на Linux

passwd -l user

то, что Вы хотите.

Это заблокирует учетную запись пользователя. Но Вы все еще сможете

su - user

но Вы будете иметь к su - user как корень.

С другой стороны, можно выполнить то же самое путем предварительного ожидания a ! к паролю пользователя в /etc/shadow (это - все passwd -l делает негласно). И passwd -u отменит это.

33
13.01.2013, 09:23
5 ответов
  • Виртуальная машина может дать Вам самую высокую безопасность без перезагрузки, но самую низкую производительность.

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

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

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

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

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

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

28
27.01.2020, 19:37
  • 1
    благодарит за ответ. Я - реальный newb когда дело доходит до материала как этот, могли Вы объяснять меня одна вещь: почему я должен препятствовать тому, чтобы программа читала файлы в системе (например, chroot)? (если программа не может изменить их). –  korda 16.11.2011, 14:21
  • 2
    учетная запись пользователя испытания на ударную прочность при столкновении дает Вам некоторую основную безопасность наверняка. Все еще существует много вещей, которые Вы могли бы хотеть/нуждаться предотвратить. Это может быть в форме использования общих уязвимостей, встроенных в программу или некоторое социальное взламывание, сбор информации в целях будущего удаленного нападения... И вероятно намного больше. –  rozcietrzewiacz 16.11.2011, 14:29
  • 3
    Почему мы - это: существует ли способ препятствовать тому, чтобы пользователь использовал интернет-соединение? –  korda 16.11.2011, 14:34
  • 4
    Интересно если nobody имеет доступ в Интернет. –  korda 16.11.2011, 14:50
  • 5
    @rozcietrzewiacz, который состоит в том, чтобы быть важное требование для chroot для обеспечивания любой защиты не запустить chrooted программу как пользователя, который также запускает программу вне chroot. Иначе процесс chrooted может ptrace non-chrooted обрабатывать и делать что-либо тот путь. –  Gilles 'SO- stop being evil' 17.11.2011, 10:32

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

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

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

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

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

10
27.01.2020, 19:37

На BSD полученный unixes (включая Mac OS X) существует названное средство sandbox. В странице справочника говорится

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

Это является отдельным от chroot средство, которое также доступно.

1
27.01.2020, 19:37

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

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

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

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

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

2
27.01.2020, 19:37

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

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

2
27.01.2020, 19:37

Теги

Похожие вопросы