Модули безопасности Linux

редактировать

Модули безопасности Linux (LSM ) - это фреймворк, который позволяет ядру Linux поддерживать различные модели компьютерной безопасности, в то время как избегать фаворитизма по отношению к какой-либо отдельной реализации безопасности Платформа лицензирована в соответствии с условиями Стандартной общественной лицензии GNU и является стандартной частью ядра Linux, начиная с Linux 2.6. AppArmor, SELinux, Smack и TOMOYO Linux являются в настоящее время принятыми модулями в официальном ядре.

Содержание

  • 1 Дизайн
  • 2 Принятие
  • 3 История
  • 4 Прием
  • 5 Ссылки
  • 6 Внешние ссылки

Дизайн

LSM был разработан для обеспечения специфические потребности всего необходимого для успешной реализации модуля обязательного контроля доступа с минимальным внесением изменений в ядро ​​Linux. LSM избегает подхода, который используется в Systrace, поскольку он не масштабируется до многопроцессорных ядер и подвержен атакам TOCTTOU (гонка). Вместо этого LSM вставляет «перехватчики » (вызовы модуля) в каждую точку ядра, где системный вызов на уровне пользователя должен привести к доступу к важному внутреннему объекту ядра, такому как inodes и управление задачами. блоки.

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

Цель управления доступом LSM очень тесно связана с проблемой, но несколько отличается. Аудит требует, чтобы каждая попытка доступа регистрировалась. LSM не может обеспечить это, потому что для этого потребуется гораздо больше ловушек, чтобы обнаруживать случаи, когда ядро ​​«закорачивает» сбойные системные вызовы и возвращает код ошибки, прежде чем приблизиться к значительным объектам.

Дизайн LSM описан в статье Linux Security Modules: General Security Support for the Linux Kernel, представленной на USENIX Security 2002. На той же конференции была опубликована статья Using CQUAL for Static Analysis of Authorization Hook Placement, в которой изучалась автоматическая статический анализ кода ядра для проверки того, что все необходимые перехватчики действительно вставлены в ядро ​​Linux.

Принятие

История

На саммите ядра Linux 2001 года АНБ предложило, чтобы SELinux должен быть включен в Linux 2.5. Линус Торвальдс отверг SELinux в то время, потому что он заметил, что в разработке находится много различных проектов безопасности, и поскольку все они различаются, сообщество специалистов по безопасности еще не сформирован консенсус по окончательной модели безопасности. Вместо этого Линус поручил сообществу специалистов по безопасности «сделать его модулем».

В ответ предложен LSM: интерфейс для ядра Linux, который обеспечивает достаточное количество "перехватов" (восходящих вызовов) из ядра Linux для загружаемого модуля, чтобы позволить модулю принудительно принудительный контроль доступа. Разработку LSM в течение следующих двух лет проводило сообщество LSM, в том числе значительный вклад от Immunix Corporation, NSA, McAfee, IBM., Silicon Graphics и многие независимые участники. В конечном итоге LSM был принят в основной поток ядра Linux и был включен в качестве стандартной части Linux 2.6 в декабре 2003 года.

В 2006 году некоторые разработчики ядра отметили, что SELinux был единственным широко используемым модулем LSM, включенным в основной поток Linux. дерево исходных текстов ядра. Было рассмотрено, что если должен быть только один широко используемый модуль LSM, то косвенное обращение к LSM не нужно, и LSM следует удалить и заменить самим SELinux. Однако существуют другие модули LSM, поддерживаемые вне основного дерева ядра (AppArmor, Linux Intrusion Detection System и т. Д.), Поэтому этот аргумент привел к двум результатам: 1. Разработчики из этих модулей начали прилагать усилия для апстриминга своих соответствующих модулей, и 2. на конференции Kernel Summit 2006 г. Линус еще раз заявил, что LSM останется, потому что он не хочет определять лучшую модель безопасности.

LSM, вероятно, останется, поскольку дополнительные модули безопасности Smack (версия 2.6.25), TOMOYO Linux (версия 2.6.30, июнь 2009 г.) и AppArmor (версия 2.6.36) были приняты в основное ядро.

Прием

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

Некоторым разработчикам безопасности также не нравится LSM. Автору grsecurity не нравится LSM из-за его истории и того, что LSM экспортирует все свои символы, что облегчает установку вредоносных модулей (руткитов ), а также модулей безопасности. Автору RSBAC не нравится LSM, поскольку он неполон в отношении потребностей RSBAC. В частности, автор RSBAC утверждает, что: «LSM - это только дополнительный, ограничительный контроль доступа. Однако система RSBAC предоставляет множество дополнительных функций, например перенаправление символических ссылок, secure_delete, частичное отключение Linux DAC. Все это необходимо исправить. в функции ядра в отдельном патче. ". В проекте утверждается, что нацеливание на LSM API - это подвижная цель, поскольку она меняется с каждым выпуском ядра, что приводит к дополнительным работам по обслуживанию. Другие разработчики хотели бы, чтобы модули LSM были сложены, например разработчик Yama LSM.

Ссылки

Внешние ссылки

  • Портал бесплатного программного обеспечения с открытым исходным кодом
Последняя правка сделана 2021-05-27 10:48:03
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте