Linux с повышенной безопасностью

редактировать
Модуль безопасности ядра Linux
Linux с повышенной безопасностью
SELinux logo.svg
Графический интерфейс администратора SELinux в Fedora 8 GUI администратора SELinux в Fedora 8
Первоначальный автор (ы) NSA и Red Hat
Разработчик (и) Red Hat
Первоначальный выпуск22 декабря 2000 г.; 19 лет назад (2000-12-22)
Стабильный выпуск 3.0 / 4 декабря 2019 г.; 10 месяцев назад (04.12.2019)
Репозиторий Измените это на Wikidata
Написано вC
Операционной системе Linux
Тип Безопасность, Модули безопасности Linux (LSM)
Лицензия GNU GPL
Веб-сайтselinuxproject.org, nsa.gov / What-We-Do / Research / SELinux /

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

SELinux - это набор модификаций ядра и инструментов пользовательского пространства, которые были добавлены в различные дистрибутивы Linux. Его архитектура стремится отделить выполнение решений по безопасности от политики безопасности и оптимизирует количество программного обеспечения, связанного с применением политики безопасности. Ключевые концепции, лежащие в основе SELinux, восходят к нескольким более ранним проектам Агентства национальной безопасности США (АНБ).

Содержание
  • 1 Обзор
  • 2 История
  • 3 Пользователи, политики и контексты безопасности
  • 4 Функции
  • 5 Реализации
  • 6 Сценарии использования
    • 6.1 Примеры
  • 7 Сравнение с AppArmor
  • 8 Подобные системы
  • 9 См. также
  • 10 Ссылки
  • 11 Внешние ссылки
Обзор

От группы Linux с усиленной безопасностью NSA:

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

Ядро Linux, интегрирующее SELinux, применяет политики обязательного контроля доступа, которые ограничивают пользовательские программы и системные службы, а также доступ к файлам и сети. Ресурсы. Ограничение привилегий до минимума, необходимого для работы, снижает или исключает возможность этих программ и демонов причинять вред в случае их неисправности или компрометации (например, через переполнение буфера или неправильную конфигурацию). Этот механизм ограничения работает независимо от традиционных механизмов управления доступом Linux (дискреционный ). Он не имеет понятия «root» суперпользователь и не разделяет хорошо известные недостатки традиционных механизмов безопасности Linux, такие как зависимость от setuid / setgid двоичные файлы.

Безопасность «немодифицированной» системы Linux (системы без SELinux) зависит от правильности ядра, всех привилегированных приложений и каждой из их конфигураций. Неисправность в любой из этих областей может привести к компрометации всей системы. Напротив, безопасность «модифицированной» системы (основанной на ядре SELinux) в первую очередь зависит от правильности ядра и его конфигурации политики безопасности. Хотя проблемы с правильностью или конфигурацией приложений могут позволить ограниченную компрометацию отдельных пользовательских программ и системных демонов, они не обязательно представляют угрозу безопасности других пользовательских программ и системных демонов или безопасности системы в целом.

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

История

К самой ранней работе, направленной на стандартизацию подхода, обеспечивающего обязательный и дискреционный контроль доступа (MAC и DAC) в вычислительной среде UNIX (точнее, POSIX), можно отнести в рабочую группу Trusted UNIX (TRUSIX) Агентства национальной безопасности, которая заседала с 1987 по 1991 год и опубликовала одну Rainbow Book (# 020A), и представила формальную модель и соответствующий прототип свидетельства оценки (# 020B), который был в конечном итоге не опубликован.

SELinux был разработан для демонстрации ценности обязательного контроля доступа для сообщества Linux и того, как такие средства контроля могут быть добавлены в Linux. Первоначально патчи, составляющие SELinux, должны были быть явно применены к исходному тексту ядра Linux; SELinux был объединен с основной веткой ядра Linux в серии 2.6 ядра Linux.

АНБ, первоначальный основной разработчик SELinux, 22 декабря 2000 г. выпустило первую версию для сообщества разработчиков с открытым исходным кодом под GNU GPL. Программное обеспечение был объединен с основным ядром Linux 2.6.0-test3, выпущенным 8 августа 2003 года. Другие важные участники включают Red Hat, Network Associates, Secure Computing Corporation, Tresys Technology и Trusted Computer Solutions. Экспериментальные порты реализации FLASK / TE были доступны через проект TrustedBSD для операционных систем FreeBSD и Darwin.

Linux с усиленной безопасностью реализует ядро ​​повышенной безопасности Flux (FLASK). Такое ядро ​​содержит архитектурные компоненты, прототипы которых созданы в. Они обеспечивают общую поддержку для обеспечения соблюдения многих видов политик обязательного контроля доступа, в том числе основанных на концепциях принудительного применения типов, управления доступом на основе ролей и многоуровневой безопасности. FLASK, в свою очередь, был основан на DTOS, производном от Mach, а также на Trusted Mach, исследовательском проекте из Trusted Information Systems, который оказал влияние на разработку и реализацию DTOS.

Пользователи, политики и контексты безопасности

Пользователи и роли SELinux не обязательно должны быть связаны с реальными пользователями и ролями системы. Для каждого текущего пользователя или процесса SELinux назначает трехстрочный контекст, состоящий из имени пользователя, роли и домена (или типа). Эта система более гибкая, чем обычно требуется: как правило, большинство реальных пользователей используют одно и то же имя пользователя SELinux, и весь контроль доступа осуществляется через третий тег - домен. Обстоятельства, при которых процесс разрешен в определенном домене, должны быть настроены в политиках. Команда runconпозволяет запускать процесс в явно заданном контексте (пользователь, роль и домен), но SELinux может отклонить переход, если он не одобрен политикой.

Файлы, сетевые порты и другое оборудование также имеют контекст SELinux, состоящий из имени, роли (используется редко) и типа. В случае файловых систем сопоставление файлов и контекстов безопасности называется маркировкой. Маркировка определяется в файлах политик, но также может быть скорректирована вручную без изменения политик. Типы оборудования довольно подробно описаны, например, bin_t(все файлы в папке / bin) или postgresql_port_t(порт PostgreSQL, 5432). Контекст SELinux для удаленной файловой системы может быть явно указан во время монтирования.

SELinux добавляет переключатель -Zк командам оболочки ls, psи некоторым другим, позволяя видеть контекст безопасности файлов или процесса.

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

Типичная политика состоит из файла отображения (маркировки), файла правил и файла интерфейса, которые определяют переход домена. Эти три файла должны быть скомпилированы вместе с инструментами SELinux для создания единого файла политики. Полученный файл политики можно загрузить в ядро, чтобы сделать его активным. Загрузка и выгрузка политик не требует перезагрузки. Файлы политик либо написаны вручную, либо могут быть созданы с помощью более удобного инструмента управления SELinux. Обычно они сначала тестируются в разрешающем режиме, когда нарушения регистрируются, но разрешены. Инструмент audit2allowможно использовать позже для создания дополнительных правил, расширяющих политику, чтобы разрешить ограничение всех законных действий приложения.

Возможности

Функции SELinux включают:

  • Четкое разделение политики и принудительного применения
  • Четко определенные интерфейсы политик
  • Поддержка приложений, запрашивающих политику и обеспечение контроля доступа (например, crond запускает задания в правильном контексте)
  • Независимость от конкретных политик и языков политик
  • Независимость от конкретных форматов и содержимого меток защиты
  • Индивидуальные метки и элементы управления для объектов и служб ядра
  • Поддержка изменений политики
  • Отдельные меры для защиты целостности системы (тип домена) и конфиденциальности данных (многоуровневая безопасность )
  • Гибкая политика
  • Управление инициализацией и наследованием процессов, а также выполнением программ
  • Управление файловыми системами, каталогами, файлами и открытыми файловыми дескрипторами
  • Управление сокетами, сообщения и сетевые интерфейсы
  • Управление использованием «возможностей»
  • Кэшированная информация о доступе-решении s через политику Access Vector Cache (AVC)
  • Default-deny (запрещается все, что явно не указано в политике)
Реализации

SELinux был реализован в Android начиная с версии 4.3.

Среди бесплатных дистрибутивов GNU / Linux, поддерживаемых сообществом, Fedora была одним из первых, кто начал применять его, включая поддержку по умолчанию, начиная с Fedora Core 2. Другие дистрибутивы включают поддержка для него, например, Debian с версии 9 Stretch и Ubuntu с 8.04 Hardy Heron. Начиная с версии 11.1, openSUSE содержит «базовые возможности» SELinux. SUSE Linux Enterprise 11 предлагает SELinux как «предварительную версию технологии».

SELinux популярен в системах на основе в контейнерах Linux, таких как контейнер CoreOS Linux и rkt. Это полезно в качестве дополнительного элемента управления безопасностью, помогающего дополнительно усилить изоляцию между развернутыми контейнерами и их хостом.

SELinux доступен с 2005 года как часть Red Hat Enterprise Linux (RHEL) версии 4 и всех будущих выпусков. Это присутствие также отражено в соответствующих версиях CentOS и Scientific Linux. Поддерживаемая политика в RHEL4 - это целевая политика, которая нацелена на максимальное удобство использования и, следовательно, не является столь жесткой, как могла бы. Планируется, что в будущих версиях RHEL будет больше целей в целевой политике, что будет означать более строгие политики.

Сценарии использования

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

Утилиты командной строки включают в себя: chcon, restorecon, restorecond, runcon, sec, fixfiles, setfiles, load_policy, booleans, getsebool, setsebool, toggleseboolsetenforce, semodule, postfix-nochroot, check-selinux-installation, semodule_package, checkmodule, selinux-config-enforcing, selinuxenabledи selinux-policy-upgrade

Примеры

Чтобы перевести SELinux в принудительный режим:

$ sudo setenforce 1

Для запроса статуса SELinux:

$ getenforce
Сравнение с AppArmor

SELinux представляет собой один из нескольких возможных подходов к проблеме ограничения действий, которые может выполнять установленное программное обеспечение. Другая популярная альтернатива называется AppArmor и доступна на платформах SUSE Linux Enterprise Server (SLES), openSUSE и на основе Debian. AppArmor был разработан как компонент ныне несуществующей платформы Immunix Linux. Поскольку AppArmor и SELinux радикально отличаются друг от друга, они образуют разные альтернативы для программного управления. В то время как SELinux заново изобретает определенные концепции, чтобы предоставить доступ к более выразительному набору политик, AppArmor был разработан, чтобы быть простым, расширяя ту же административную семантику, что и для DAC, до уровня обязательного контроля доступа.

Есть несколько ключевых отличий:

  • Одно важное отличие состоит в том, что AppArmor идентифицирует объекты файловой системы по имени пути, а не по индексу. Это означает, что, например, недоступный файл может стать доступным в AppArmor, когда на него будет создана жесткая ссылка, а SELinux запретит доступ через вновь созданную жесткую ссылку.
    • В результате можно сказать, что AppArmor не является системой принудительного применения типа, поскольку файлам не назначен тип; вместо этого они просто упоминаются в файле конфигурации.
  • SELinux и AppArmor также значительно различаются по способам администрирования и интеграции в систему.
  • Поскольку они пытаются воссоздать традиционные элементы управления DAC с MAC- На уровне принудительного применения набор операций AppArmor также значительно меньше, чем те, которые доступны в большинстве реализаций SELinux. Например, набор операций AppArmor состоит из: чтения, записи, добавления, выполнения, блокировки и ссылки. Большинство реализаций SELinux будет поддерживать количество операций на порядки больше, чем это. Например, SELinux обычно поддерживает те же самые разрешения, но также включает элементы управления для mknod, привязку к сетевым сокетам, неявное использование возможностей POSIX, загрузку и выгрузку модулей ядра, различные средства доступа к общей памяти и т. Д.
  • В AppArmor нет элементов управления для категориального ограничения возможностей POSIX. Поскольку текущая реализация возможностей не содержит понятия субъекта для операции (только субъект и операция), обычно задача уровня MAC состоит в предотвращении привилегированных операций с файлами за пределами принудительной области управления субъектом (например, «песочница»).). AppArmor может предотвратить изменение своей собственной политики и запретить монтирование / размонтирование файловых систем, но ничего не делает, чтобы помешать пользователям выйти за пределы утвержденных сфер контроля.
    • Например, для сотрудников службы поддержки может быть сочтено выгодным изменить владельца или разрешения на определенные файлы, даже если они им не принадлежат (например, для файлового общего доступа отдела). Очевидно, что вы не хотите давать пользователю (-ам) root на коробке, поэтому вы даете им CAP_FOWNERили CAP_DAC_OVERRIDE. В SELinux вы (или поставщик вашей платформы) можете настроить SELinux так, чтобы запретить все возможности другим пользователям, не имеющим ограничений, а затем создать ограниченные домены, в которые сотрудник сможет перейти после входа в систему, тот, который может использовать эти возможности, но только для файлов соответствующий тип.
  • В AppArmor нет понятия многоуровневой безопасности, поэтому нет жесткого BLP или Biba принуждения.
  • Конфигурация AppArmor выполняется с использованием исключительно обычных плоских файлов. SELinux (по умолчанию в большинстве реализаций) использует комбинацию плоских файлов (используемых администраторами и разработчиками для написания политики, доступной для чтения человеком, до ее компиляции) и расширенных атрибутов.
  • SELinux поддерживает концепцию «удаленного сервера политик». (настраивается через /etc/selinux/semanage.conf) в качестве альтернативного источника для настройки политики. Централизованное управление AppArmor обычно значительно усложняется, поскольку администраторы должны выбирать между инструментами развертывания конфигурации, запускаемыми от имени пользователя root (для разрешения обновлений политик) или настраиваемыми вручную на каждом сервере.
Подобные системы

Также можно изолировать процессы выполняется с помощью таких механизмов, как виртуализация ; проект OLPC, например, в своей первой реализации изолировал отдельные приложения в облегченных Vservers. Кроме того, NSA приняло некоторые концепции SELinux в Security-Enhanced Android.

General Dynamics создает и распространяет PitBull Trusted Operating System, многоуровневую систему безопасности (MLS) для Red Hat Enterprise Linux.

См. Также
Ссылки
Внешние ссылки
Последняя правка сделана 2021-06-07 08:33:53
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте