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

Linux с повышенной безопасностью
SELinux logo.svg
SELinux administrator GUI in Fedora 8
Графический интерфейс администратора SELinux в Fedora 8
Оригинальный автор (ы)АНБ и Красная шляпа
Разработчики)Красная шляпа
изначальный выпуск22 декабря 2000 г.; 19 лет назад (2000-12-22)[1]
Стабильный выпуск
3.0 / 4 декабря 2019; Год назад (2019-12-04)[2]
Репозиторий
Отредактируйте это в Викиданных
Написано вC
Операционная системаLinux
ТипБезопасность, Модули безопасности Linux (LSM)
ЛицензияGNU GPL
Интернет сайтselinuxproject.org, NSA.gov/Что мы делаем/Исследование/ SELinux/

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

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

Обзор

От команды NSA по обеспечению безопасности Linux:[5]

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

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

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

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

История

Самая ранняя работа, направленная на стандартизацию подхода, обеспечивающего обязательный и дискреционный контроль доступа (MAC и DAC) в вычислительной среде UNIX (точнее, POSIX), может быть отнесена к Рабочей группе Trusted UNIX (TRUSIX) Агентства национальной безопасности, которая заседала с 1987 года. до 1991 г. и опубликовал один Радужная книга (# 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 года. Среди других значительных участников - Красная шляпа, Сетевые партнеры, Корпорация Secure Computing, Tresys Technology и Trusted Computer Solutions. Экспериментальные порты Колба Реализация / TE стала доступна через TrustedBSD Проект для FreeBSD и Дарвин операционные системы.

Linux с повышенной безопасностью реализует Ядро повышенной безопасности Flux (КОЛБА). Такое ядро ​​содержит архитектурные компоненты, прототипы которых Операционная система Fluke. Они обеспечивают общую поддержку для применения многих видов политик обязательного контроля доступа, в том числе основанных на концепциях исполнение типа, управление доступом на основе ролей, и многоуровневая безопасность. FLASK, в свою очередь, был основан на DTOS, производном от Маха. Распределенная доверенная операционная система, а также о Trusted Mach, исследовательском проекте от Надежные информационные системы это оказало влияние на разработку и реализацию DTOS.

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

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

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

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

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

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

Функции

Возможности SELinux включают:

  • Четкое разделение политики и принуждения
  • Четко определенные интерфейсы политик
  • Поддержка приложений, запрашивающих политику и обеспечивающих контроль доступа (например, crond выполнение заданий в правильном контексте)
  • Независимость от конкретных политик и языков политик
  • Независимость от конкретных форматов и содержимого защитных этикеток
  • Индивидуальные метки и элементы управления для объектов и служб ядра
  • Поддержка изменений политики
  • Раздельные меры защиты целостности системы (доменного типа) и конфиденциальности данных (многоуровневая безопасность )
  • Гибкая политика
  • Контроль инициализации и наследования процессов, а также выполнения программы.
  • Контроль файловых систем, каталогов, файлов и открытия файловые дескрипторы
  • Контроль сокетов, сообщений и сетевых интерфейсов
  • Контроль за использованием «возможностей»
  • Кэшированная информация о решениях доступа через Доступ к векторному кэшу (AVC)[7]
  • По умолчанию отказать политика (все, что явно не указано в политике, запрещено)[8][9][10]

Реализации

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

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

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

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

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

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

Утилиты командной строки включают:[17]chcon,[18]восстановление,[19]второй,[20]Runcon,[21]второй,[22]fixfiles,[23]setfiles,[24]load_policy,[25]булевы,[26]Getsebool,[27]Setsebool,[28]togglesebool[29]сила,semodule,постфикс-нокорень,проверка-установка-selinux,semodule_package,контрольный модуль,selinux-config-принудительное исполнение,[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 был разработан таким образом, чтобы быть простым путем расширения той же административной семантики, которая использовалась для ЦАП до уровня обязательного контроля доступа.

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

  • Одно из важных отличий заключается в том, что 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 так, чтобы запретить все возможности другим пользователям, не имеющим ограничений, а затем создать ограниченные домены, в которые сотрудник сможет перейти после входа в систему, тот, который может использовать эти возможности, но только для файлов соответствующий тип.[нужна цитата ]
  • В AppArmor нет понятия многоуровневой безопасности, поэтому нет сложных BLP или же Биба доступное исполнение.[нужна цитата ].
  • Конфигурация AppArmor выполняется с использованием исключительно обычных плоских файлов. SELinux (по умолчанию в большинстве реализаций) использует комбинацию плоских файлов (используемых администраторами и разработчиками для написания политики, удобочитаемой человеком, перед ее компиляцией) и расширенных атрибутов.
  • SELinux поддерживает концепцию «удаленного сервера политик» (настраиваемого через /etc/selinux/semanage.conf) в качестве альтернативного источника для настройки политики. Централизованное управление AppArmor обычно значительно усложняется, поскольку администраторы должны выбирать между инструментами развертывания конфигурации, запускаемыми от имени пользователя root (для разрешения обновлений политики) или настраиваемыми вручную на каждом сервере.

Подобные системы

Смотрите также: Samsung Knox

Изоляция процессов также может быть достигнута с помощью таких механизмов, как виртуализация; то OLPC проект, например, в его первой реализации[35] в песочнице отдельные приложения в легком Всерверы. Так же АНБ принял некоторые концепции SELinux в Security-Enhanced Android.[36]

Общая динамика создает и распространяет надежную операционную систему PitBull,[37] а многоуровневая безопасность (MLS) улучшение для Red Hat Enterprise Linux.

Смотрите также

Рекомендации

  1. ^ «Linux с повышенной безопасностью доступен на сайте АНБ - MARC». MARC. Получено 24 декабря 2018.
  2. ^ "Версия пользовательского пространства SELinux 20191204 / 3.0". Проект SELinux. 2019-12-04. Получено 2019-12-05.
  3. ^ «Часто задаваемые вопросы по SELinux (FAQ) - NSA / CSS». Национальное Агенство Безопасности. Получено 2013-02-06.
  4. ^ Лоскокко, Питер; Смолли, Стивен (февраль 2001 г.). «Интеграция гибкой поддержки политик безопасности в операционную систему Linux» (PDF).
  5. ^ «Linux с усиленной безопасностью - NSA / CSS». Национальное Агенство Безопасности. 2009-01-15. Получено 2013-02-06.
  6. ^ Сравнивать «Агентство национальной безопасности делится улучшениями безопасности для Linux». Пресс-релиз АНБ. Форт Джордж Г. Мид, Мэриленд: Центральная служба безопасности Агентства национальной безопасности. 2001-01-02. Получено 2011-11-17. АНБ рада объявить, что оно разработало и делает общедоступным прототип версии операционной системы Linux с повышенной безопасностью.
  7. ^ Проект документации Fedora (2010 г.). Fedora 13: Руководство пользователя Linux с повышенной безопасностью. Fultus Corporation. п. 18. ISBN  978-1-59682-215-3. Получено 2012-02-22. Решения SELinux, такие как разрешение или запрет доступа, кэшируются. Этот кеш известен как кэш вектора доступа (AVC). Решения о кэшировании уменьшают частоту проверки правил SELinux, что увеличивает производительность.
  8. ^ "SELinux / Краткое введение - Gentoo Wiki". wiki.gentoo.org.
  9. ^ «Начало работы с SELinux». Руководства и учебные пособия по Linode.
  10. ^ «Обзор NB - SELinux Wiki». selinuxproject.org.
  11. ^ "Linux с повышенной безопасностью в Android". Проект с открытым исходным кодом Android. Получено 2016-01-31.
  12. ^ «SELinux». debian.org.
  13. ^ «Как установить SELinux на Ubuntu 8.04» Харди Херон"". Учебники Ubuntu.
  14. ^ "Новости openSUSE". Новости openSUSE.
  15. ^ «Примечания к выпуску для SUSE Linux Enterprise Desktop 11». Novell. Получено 2013-02-06.
  16. ^ «SELinux на CoreOS». Документы CoreOS.
  17. ^ «SELinux / Команды - FedoraProject». Получено 2015-11-25.
  18. ^ "чкон". Linuxcommand.org. Архивировано из оригинал на 2004-10-24. Получено 2013-02-06.
  19. ^ "restorecon (8) - справочная страница Linux". Linux.die.net. Получено 2013-02-06.
  20. ^ "restorecond (8) - справочная страница Linux". Linux.die.net. Получено 2013-02-06.
  21. ^ "runcon (1) - справочная страница Linux". Linux.die.net. Получено 2013-02-06.
  22. ^ "second (1) - справочная страница Linux". Linux.die.net. Получено 2013-02-06.
  23. ^ "fixfiles (8): исправить контексты безопасности SELinux файла - справочная страница Linux". Linux.die.net. Получено 2013-02-06.
  24. ^ "setfiles (8): установить контексты безопасности SELinux файла - справочная страница Linux". Linux.die.net. Получено 2013-02-06.
  25. ^ "load_policy (8) - страница руководства Linux". Linux.die.net. Получено 2013-02-06.
  26. ^ "booleans (8) - справочная страница Linux". Linux.die.net. Получено 2013-02-06.
  27. ^ "getsebool (8): логическое значение SELinux - страница руководства Linux". Linux.die.net. Получено 2013-02-06.
  28. ^ "setsebool (8): установить логическое значение SELinux - справочная страница Linux". Linux.die.net. Получено 2013-02-06.
  29. ^ "togglesebool (8) - справочная страница Linux". Linux.die.net. Получено 2013-02-06.
  30. ^ "Ubuntu Manpage: selinux-config-enforcing - измените / etc / selinux / config, чтобы установить принудительное исполнение". Canonical Ltd. Архивировано из оригинал на 2012-12-20. Получено 2013-02-06.
  31. ^ "Ubuntu Manpage: selinuxenabled - инструмент, который будет использоваться в сценариях оболочки, чтобы определить, есть ли". Canonical Ltd. Архивировано из оригинал на 2013-02-09. Получено 2013-02-06.
  32. ^ "Ubuntu Manpage: selinux-policy-upgrade - обновить модули в политике SE Linux". Canonical Ltd. Архивировано из оригинал на 2012-04-04. Получено 2013-02-06.
  33. ^ "Фоны SELinux". SELinux. Руководство по безопасности. SUSE.
  34. ^ "apparmor.d - синтаксис профилей безопасности для AppArmor". Архивировано из оригинал на 2013-10-17.
  35. ^ "Радуга". laptop.org.
  36. ^ «Работа, связанная с SELinux». NSA.gov.
  37. ^ Общая динамика. «Надежная операционная система PitBull».

внешняя ссылка