Security-Enhanced Linux ( SELinux ) - это модуль безопасности ядра Linux, который предоставляет механизм для поддержки политик безопасности контроля доступа , включая обязательный контроль доступа (MAC).
Автор (ы) оригинала | АНБ и Red Hat |
---|---|
Разработчики) | Красная шляпа |
Первый выпуск | 22 декабря 2000 г . [1] |
Стабильный выпуск | 3.2 / 4 марта 2021 г . [2] |
Репозиторий | |
Написано в | C |
Операционная система | Linux |
Тип | Безопасность, Модули безопасности Linux (LSM) |
Лицензия | GNU GPL |
Веб-сайт | selinuxproject |
SELinux - это набор модификаций ядра и инструментов пользовательского пространства, которые были добавлены в различные дистрибутивы Linux . Его архитектура стремится отделить выполнение решений по безопасности от политики безопасности и оптимизирует объем программного обеспечения, задействованного в обеспечении соблюдения политики безопасности. [3] [4] Ключевые концепции, лежащие в основе SELinux, восходят к нескольким более ранним проектам Агентства национальной безопасности США (АНБ).
Обзор
Команда Linux с усиленной безопасностью NSA описывает SELinux NSA как [5]
набор исправлений для ядра Linux и утилит для обеспечения сильной, гибкой архитектуры обязательного контроля доступа (MAC) к основным подсистемам ядра. Он предоставляет расширенный механизм для принудительного разделения информации на основе требований конфиденциальности и целостности, который позволяет устранять угрозы взлома и обхода механизмов безопасности приложений и позволяет ограничить ущерб, который может быть причинен вредоносными или некорректными приложениями. Он включает набор образцов файлов конфигурации политики безопасности, разработанных для достижения общих целей безопасности.
Ядро Linux, интегрирующее SELinux, обеспечивает принудительные политики контроля доступа, которые ограничивают пользовательские программы и системные службы, а также доступ к файлам и сетевым ресурсам. Ограничение привилегий до минимума, необходимого для работы, снижает или исключает возможность этих программ и демонов причинять вред в случае неисправности или компрометации (например, через переполнение буфера или неправильную конфигурацию). Этот механизм ограничения работает независимо от традиционных ( дискреционных ) механизмов контроля доступа Linux . Он не имеет понятия «корневой» суперпользователь и не разделяет хорошо известные недостатки традиционных механизмов безопасности 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, выпустило первую версию для сообщества разработчиков с открытым исходным кодом под GNU GPL 22 декабря 2000 года. [6] Программное обеспечение было объединено с основным ядром 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). Такое ядро содержит архитектурные компоненты, прототипы которых реализованы в операционной системе Fluke . Они обеспечивают общую поддержку для применения многих видов политик обязательного контроля доступа, в том числе основанных на концепциях принудительного применения типов , ролевого контроля доступа и многоуровневой безопасности . 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 запускает задания в правильном контексте)
- Независимость от конкретных политик и языков политик
- Независимость от конкретных форматов и содержимого защитных этикеток
- Индивидуальные метки и элементы управления для объектов и служб ядра
- Поддержка изменений политики
- Раздельные меры защиты целостности системы (доменного типа) и конфиденциальности данных ( многоуровневая безопасность )
- Гибкая политика
- Контроль инициализации и наследования процессов, а также выполнения программы.
- Управление файловыми системами, каталогами, файлами и дескрипторами открытых файлов.
- Управление сокетами, сообщениями и сетевыми интерфейсами
- Контроль за использованием «возможностей»
- Кэшированная информация о решениях доступа через Access Vector Cache (AVC) [7]
- Политика отказа по умолчанию (все, что явно не указано в политике, запрещено) [8] [9] [10]
Реализации
SELinux реализован в Android с версии 4.3. [11]
Среди бесплатных дистрибутивов GNU / Linux, поддерживаемых сообществом, Fedora была одним из первых, кто его внедрил, включая поддержку по умолчанию, начиная с Fedora Core 2. Другие дистрибутивы включают поддержку, например Debian в версии 9 Stretch release [12] и Ubuntu в качестве из 8.04 Харди Херон. [13] Начиная с версии 11.1 openSUSE содержит «базовые возможности» SELinux. [14] SUSE Linux Enterprise 11 включает SELinux как «предварительную версию технологии». [15]
SELinux популярен в системах, основанных на контейнерах Linux , таких как CoreOS Container Linux и rkt. [16] Это полезно как дополнительный элемент управления безопасностью, помогающий в дальнейшем усилить изоляцию между развернутыми контейнерами и их хостом.
SELinux доступен с 2005 года как часть Red Hat Enterprise Linux (RHEL) версии 4 и всех будущих выпусков. Это присутствие также отражено в соответствующих версиях CentOS и Scientific Linux . Поддерживаемая политика в RHEL4 - это целевая политика, которая нацелена на максимальное удобство использования и, следовательно, не является столь жесткой, как могло бы быть. Планируется, что в будущих версиях RHEL будет больше целей в целевой политике, что будет означать более строгие политики.
Сценарии использования
SELinux потенциально может контролировать, какие действия система разрешает каждому пользователю, процессу и демону, с очень точными спецификациями. Он используется для ограничения демонов, таких как движки баз данных или веб-серверы, у которых есть четко определенные права доступа к данным и действия. Это ограничивает потенциальный вред от ограниченного демона, который становится скомпрометированным.
Утилиты командной строки включают: [17]chcon
, [18]restorecon
, [19]restorecond
, [20]runcon
, [21]secon
, [22]fixfiles
, [23]setfiles
, [24]load_policy
, [25]booleans
, [26]getsebool
, [27]setsebool
, [28] togglesebool
[29]setenforce
, semodule
, postfix-nochroot
, check-selinux-installation
, semodule_package
, checkmodule
, selinux-config-enforcing
, [30]selinuxenabled
, [31] и selinux-policy-upgrade
[32]
Примеры
Чтобы перевести 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 также существенно различаются по способу администрирования и интеграции в систему. [33]
- Поскольку AppArmor пытается воссоздать традиционные элементы управления DAC с применением уровня MAC, набор операций AppArmor также значительно меньше, чем те, которые доступны в большинстве реализаций SELinux. Например, набор операций AppArmor состоит из: чтения, записи, добавления, выполнения, блокировки и ссылки. [34] Большинство реализаций SELinux поддерживают количество операций на порядки больше, чем это. Например, SELinux обычно поддерживает те же разрешения, но также включает элементы управления для mknod, привязку к сетевым сокетам, неявное использование возможностей POSIX, загрузку и выгрузку модулей ядра, различные средства доступа к общей памяти и т. Д.
- В AppArmor нет элементов управления для категориального ограничения возможностей POSIX. Поскольку текущая реализация возможностей не содержит понятия субъекта для операции (только субъект и операция), обычно задача уровня MAC состоит в предотвращении привилегированных операций с файлами за пределами принудительной области управления субъектом (например, «песочница»). ). AppArmor может предотвратить изменение своей собственной политики и запретить монтирование / размонтирование файловых систем, но ничего не делает, чтобы помешать пользователям выйти за пределы утвержденных ими сфер контроля.
- Например, для сотрудников службы поддержки может быть сочтено выгодным изменить владельца или права доступа к определенным файлам, даже если они им не принадлежат (например, в общей папке отдела). Очевидно, что вы не хотите давать пользователю (-ам) root права, поэтому вы даете им
CAP_FOWNER
илиCAP_DAC_OVERRIDE
. В SELinux вы (или поставщик вашей платформы) можете настроить SELinux так, чтобы запретить все возможности другим неограниченным пользователям, а затем создать закрытые домены, в которые сотрудник сможет перейти после входа в систему, тот, который может использовать эти возможности, но только для файлов соответствующий тип. [ необходима цитата ]
- Например, для сотрудников службы поддержки может быть сочтено выгодным изменить владельца или права доступа к определенным файлам, даже если они им не принадлежат (например, в общей папке отдела). Очевидно, что вы не хотите давать пользователю (-ам) root права, поэтому вы даете им
- В AppArmor нет понятия многоуровневой безопасности, поэтому отсутствует жесткое принудительное применение BLP или Biba . [ необходима цитата ] .
- Конфигурация AppArmor выполняется с использованием исключительно обычных плоских файлов. SELinux (по умолчанию в большинстве реализаций) использует комбинацию плоских файлов (используемых администраторами и разработчиками для написания политики, удобочитаемой человеком, перед ее компиляцией) и расширенных атрибутов.
- SELinux поддерживает концепцию «удаленного сервера политик» (настраиваемого через /etc/selinux/semanage.conf) в качестве альтернативного источника для настройки политик. Централизованное управление AppArmor обычно значительно усложняется, поскольку администраторы должны выбирать между инструментами развертывания конфигурации, запускаемыми от имени пользователя root (для разрешения обновлений политики) или настраиваемыми вручную на каждом сервере.
Подобные системы
Изоляция процессов также может быть достигнута с помощью таких механизмов, как виртуализация ; OLPC проект, например, в первом варианте осуществлении [35] песочница отдельных приложений в легких Vservers . Кроме того, АНБ приняло некоторые концепции SELinux в Android с повышенной безопасностью . [36]
General Dynamics создает и распространяет PitBull Trusted операционной системы, [37] с многоуровневой безопасности усиления (MLS) для Red Hat Enterprise Linux .
Смотрите также
- Безопасность Unix
- AppArmor
- Управление доступом на основе набора правил (RSBAC)
- Упрощенное ядро обязательного контроля доступа
- Надежные расширения Solaris
- Томойо
- TrustedBSD
- Qubes OS
Рекомендации
- ^ "Linux с повышенной безопасностью доступен на сайте NSA - MARC" . MARC . Проверено 24 декабря 2018 года .
- ^ "Пользовательское пространство SELinux версии 20210304 / 3.2" . Проект SELinux. 2021-03-04 . Проверено 21 апреля 2021 .
- ^ «Часто задаваемые вопросы по SELinux (FAQ) - NSA / CSS» . Агентство национальной безопасности . Проверено 6 февраля 2013 .
- ^ Лоскокко, Питер; Смолли, Стивен (февраль 2001 г.). «Интеграция гибкой поддержки политик безопасности в операционную систему Linux» (PDF) .
- ^ «Linux с повышенной безопасностью - NSA / CSS» . Национальное Агенство Безопасности. 2009-01-15. Архивировано из оригинала на 2020-10-22 . Проверено 21 апреля 2021 .
- ^ Сравнить «Агентство национальной безопасности делится усовершенствованиями безопасности для Linux» . Пресс-релиз АНБ . Форт Джордж Г. Мид, Мэриленд: Центральная служба безопасности Агентства национальной безопасности. 2001-01-02. Архивировано из оригинала на 2018-09-18 . Проверено 21 апреля 2021 .
АНБ рада сообщить, что оно разработало и делает общедоступным прототип версии операционной системы Linux с повышенной безопасностью.
- ^ Проект документации Fedora (2010 г.). Fedora 13: Руководство пользователя Linux с усиленной безопасностью . Fultus Corporation. п. 18. ISBN 978-1-59682-215-3. Проверено 22 февраля 2012 .
Решения SELinux, такие как разрешение или запрет доступа, кэшируются. Этот кеш известен как кэш вектора доступа (AVC). Решения о кэшировании уменьшают частоту проверки правил SELinux, что увеличивает производительность.
- ^ «SELinux / Краткое введение - Gentoo Wiki» . wiki.gentoo.org .
- ^ «Начало работы с SELinux» . Руководства и учебные пособия по Linode .
- ^ «Обзор NB - SELinux Wiki» . selinuxproject.org .
- ^ «Linux с повышенной безопасностью в Android» . Проект с открытым исходным кодом Android . Проверено 31 января 2016 .
- ^ «SELinux» . debian.org .
- ^ «Как установить SELinux на Ubuntu 8.04« Hardy Heron » » . Учебники по Ubuntu .
- ^ "Новости openSUSE" . Новости openSUSE .
- ^ «Примечания к выпуску для SUSE Linux Enterprise Desktop 11» . Novell . Проверено 6 февраля 2013 .
- ^ «SELinux на CoreOS» . Документы CoreOS .
- ^ «SELinux / Команды - FedoraProject» . Проверено 25 ноября 2015 .
- ^ "чкон" . Linuxcommand.org. Архивировано из оригинала на 2004-10-24 . Проверено 6 февраля 2013 .
- ^ "restorecon (8) - справочная страница Linux" . Linux.die.net . Проверено 6 февраля 2013 .
- ^ "restorecond (8) - справочная страница Linux" . Linux.die.net . Проверено 6 февраля 2013 .
- ^ "runcon (1) - справочная страница Linux" . Linux.die.net . Проверено 6 февраля 2013 .
- ^ "second (1) - справочная страница Linux" . Linux.die.net . Проверено 6 февраля 2013 .
- ^ «fixfiles (8): исправить контексты безопасности SELinux файла - справочная страница Linux» . Linux.die.net . Проверено 6 февраля 2013 .
- ^ "setfiles (8): установить контексты безопасности SELinux файла - справочная страница Linux" . Linux.die.net . Проверено 6 февраля 2013 .
- ^ "load_policy (8) - справочная страница Linux" . Linux.die.net . Проверено 6 февраля 2013 .
- ^ "booleans (8) - справочная страница Linux" . Linux.die.net . Проверено 6 февраля 2013 .
- ^ "getsebool (8): логическое значение SELinux - справочная страница Linux" . Linux.die.net . Проверено 6 февраля 2013 .
- ^ "setsebool (8): установить логическое значение SELinux - справочная страница Linux" . Linux.die.net . Проверено 6 февраля 2013 .
- ^ «togglesebool (8) - справочная страница Linux» . Linux.die.net . Проверено 6 февраля 2013 .
- ^ «Ubuntu Manpage: selinux-config-enforcing - измените / etc / selinux / config, чтобы установить принудительное исполнение» . Canonical Ltd . Архивировано из оригинала на 2012-12-20 . Проверено 6 февраля 2013 .
- ^ «Ubuntu Manpage: selinuxenabled - инструмент, который будет использоваться в сценариях оболочки, чтобы определить, если» . Canonical Ltd . Архивировано из оригинала на 2013-02-09 . Проверено 6 февраля 2013 .
- ^ «Ubuntu Manpage: selinux-policy-upgrade - обновить модули в политике SE Linux» . Canonical Ltd . Архивировано из оригинала на 2012-04-04 . Проверено 6 февраля 2013 .
- ^ "Фоны SELinux" . SELinux . Руководство по безопасности. SUSE.
- ^ «apparmor.d - синтаксис профилей безопасности для AppArmor» . Архивировано из оригинала на 2013-10-17.
- ^ «Радуга» . laptop.org .
- ^ «Работа, связанная с SELinux» . NSA.gov .
- ^ Общая динамика. «Надежная операционная система PitBull» .
Внешние ссылки
- Официальный веб-сайт
- АНБ:
- SELinux часто задаваемые вопросы
- Linux с повышенной безопасностью в АНБ
- Список рассылки
- «АНБ делится усовершенствованиями безопасности Linux» . Пресс-релиз . 2 января 2001 г.
- SELinux на GitHub
- Уолш, Дэниел Дж (13 ноября 2013 г.). «Наглядное руководство по применению политик SELinux» . Opensource.com.