18-10-2023
SELinux (англ. Security-Enhanced Linux — Linux с улучшенной безопасностью) — реализация системы принудительного контроля доступа, которая может работать параллельно с классической дискреционной системой контроля доступа. Входит в стандартное ядро Linux. Также для функционирования SELinux требуются модифицированные версии некоторых утилит (ps, ls, и тд), которые обеспечивают поддержку новых функций ядра, и поддержка со стороны файловой системы.
Оставаясь в рамках дискреционной системы контроля доступа, ОС имеет фундаментальное ограничение в плане разделения доступа процессов к ресурсам — доступ к ресурсам основывается на правах доступа пользователя. Это классические права rwx на трех уровнях — владелец, группа-владелец и остальные.
В SELinux права доступа определяются самой системой при помощи специально определенных политик. Политики работают на уровне системных вызовов и применяются самим ядром (но можно реализовать и на уровне приложения). SELinux действует после классической модели безопасности Linux. Иными словами, через SELinux нельзя разрешить то, что запрещено через права доступа пользователей/групп. Политики описываются при помощи специального гибкого языка описания правил доступа. В большинстве случаев правила SELinux «прозрачны» для приложений, и не требуется никакой их модификации. В состав некоторых дистрибутивов входят готовые политики, в которых права могут определяться на основе совпадения типов процесса (субъекта) и файла (объекта) — это основной механизм SELinux. Две других формы контроля доступа — доступ на основе ролей и на основе многоуровневой системы безопасности (например, ДСП (для служебного пользования), секретно, совершенно секретно, ОВ (особой важности)).
Самый простой для работы и поддержки с точки зрения поддержки тип политики — так называемая «целевая» политика, разработанная в рамках проекта Fedora. В рамках политики описано более 200 процессов, которые могут выполняться в операционной системе. Все, что не описано «целевой» политикой, выполняется в домене (с типом) unconfined_t. Процессы, работающие в этом домене, не защищаются SELinux. Таким образом, все сторонние пользовательские приложения будут без всяких проблем работать в системе с «целевой» политикой в рамках классических разрешений дискреционной системы контроля доступа.
Кроме «целевой» политики, в состав некоторых дистрибутивов входит политика с многоуровневой моделью безопасности (с поддержкой модели Bell LaPadula).
Третий вариант политики — «строгий». Тут действует принцип «что не разрешено, то запрещено» (принцип наименьших прав). Политика основывается на Reference Policy от компании Tresys.
SELinux был разработан Агентством национальной безопасности США, и затем его исходные коды были представлены для скачивания.
Оригинальный текст (англ.)From NSA Security-enhanced Linux Team:
«NSA Security-enhanced Linux is a set of patches to the Linux kernel and some utilities to incorporate a strong, flexible mandatory access control (MAC) architecture into the major subsystems of the kernel. It provides a mechanism to enforce the separation of information based on confidentiality and integrity requirements, which allows threats of tampering and bypassing of application security mechanisms to be addressed and enables the confinement of damage that can be caused by malicious or flawed applications. It includes a set of sample security policy configuration files designed to meet common, general-purpose security goals.»
SELinux включён в состав ядра (начиная с версии 2.6).
Содержание |
LSM (англ. Linux Security Modules — модули безопасности Linux) представляют собой реализацию в виде подгружаемых модулей ядра. В первую очередь, LSM применяются для поддержки контроля доступа. Сами по себе LSM не обеспечивают систему какой-то дополнительной безопасностью, а лишь являются неким интерфейсом для её поддержки. Система LSM обеспечивает реализацию функций перехватчиков, которые хранятся в структуре политик безопасности, охватывающей основные операции, защиту которых необходимо обеспечить. Контроль доступа в систему осуществляется благодаря настроенным политикам.
Большинство операционных систем обладают средствами и методами управления доступом, которые в свою очередь определяют, может ли некий объект на уровне ОС (пользователь или программа) получить доступ к определенному ресурсу. Используются следующие методы управления доступом:
В самом начале своего появления SELinux была реализована в виде патча. В данном случае было непросто настраивать политику безопасности. С появление механизмов LSM, настройка и управление безопасностью значительно упростились (политика и механизмы усиления безопасности были разделены), SELinux была реализована в виде подгружаемых модулей ядра. Перед доступом к внутренним объектам ОС производится изменение кода ядра. Это реализуется при помощи специальных функций (перехватчиков системных вызовов), так называемых функций «крючков» (англ. hook functions). Функции перехватчики хранятся в некоторой структуре данных, их целью является выполнение определенных действий по обеспечению безопасности, основанных на заранее установленной политике. Сам модуль включает в себя шесть главных компонентов: сервер безопасности; кэш вектора доступа (англ. Access Vector Cache, AVC); таблицы сетевых интерфейсов; код сигнала сетевого уведомления; свою виртуальную файловую систему (selinuxfs) и реализацию функций перехватчиков.
SELinux доступен с коммерческой поддержкой, как часть Red Hat Enterprise Linux начиная с версии 4.
В сообществе поддерживаемые дистрибутивы Linux:
SELinux представляет один из нескольких возможных подходов к ограничению действий, выполняемых установленным ПО.
Система AppArmor делает примерно то же самое, что и SELinux. Одно важное различие между этими системами — способ идентификации объектов файловой системы: AppArmor использует полный путь, а SELinux — индексный дескриптор. Это значит, что, например, недоступный файл может быть доступен с AppArmor через жёсткую ссылку. С SELinux доступ через эту же жёсткую ссылку будет запрещён. С другой стороны, недоступные данные могут стать доступными, когда приложение обновляет файл, перезаписывая его (это метод используется довольно часто). AppArmor в этом случае будет продолжать отказывать в доступе к данным, так как полный путь к файлу остаётся неизменным. В обоих случаях политика по умолчанию «no access» позволяет избежать этих проблем.
SELinux.
