SELinux

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

SELinux входит в официальное ядро Linux начиная с версии 2.6. Система разрабатывается Национальным агентством по безопасности США (NSA, National Security Agency) при сотрудничестве с другими исследовательскими лабораториями и коммерческими дистрибутивами Linux. Исходные тексты проекта доступны под лицензией GPL.

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

Правила имеют следующий вид:

allow httpd_t net_conf_t:file { read getattr lock ioctl };

В этом правиле для домена http-сервера разрешается чтение неких файлов, содержащих сетевую конфигурацию.

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

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

SELinux действует после классической модели безопасности Unix. Иными словами, через SELinux нельзя разрешить то, что запрещено через права доступа пользователей/групп. Политики описываются при помощи специального гибкого языка описания правил доступа. В большинстве случаев правила SELinux "прозрачны" для приложений, и не требуется никакой их модификации. В готовых политиках права могут определяться на основе совпадения типов процесса (субъекта) и файла (объекта) – это основной механизм SELinux. Две других формы контроля доступа – доступ на основе ролей и на основе многоуровневой системы безопасности (например, ДСП, секретно, совершенно секретно).

Самый простой для работы и поддержки с точки зрения ИТ службы предприятия тип политики – так называемая "целевая" политика. В рамках политики описано более 200 процессов, которые могут выполняться. Все, что не описано "целевой" политикой, выполняется в домене (с типом) unconfined_t. Процессы, работающие в этом домене, не защищаются SELinux. Таким образом, все сторонние пользовательские приложения будут без всяких проблем работать в системе с "целевой" политикой в рамках классических разрешений DAC.

Кроме "целевой" политики существует политика с многоуровневой моделью безопасности (с поддержкой модели Белла-Ла Падула).

Третий вариант политики – "строгий", действующий по принципу "что не разрешено, то запрещено". Политика основывается на Reference Policy от компании Tresys.

При попытке создать правила доступа для какой-либо программы можно столкнуться с тем, что она была написана без учёта ограничений SELinux. Например, некоторые приложения под Unix практикуют частый переход от прав суперпользователя к правам простого пользователя и обратно (права суперпользователя фактически используются только там, где это действительно необходимо) – такое поведение в рамках модели безопасности SELinux описать непросто.

Многие проекты (например, сетевой экран IPTables и графическое окружение KDE) полноценно не включены в модель доступа SELinux.

MLS

MLS – это еще одна форма мандатного контроля доступа, доступная при использовании SELinux. Политика с поддержкой MLS является опциональной и для большинства пользователей она будет намного менее полезной, чем принудительный контроль на основе Type Enforcement (TE) – основного механизма, используемого в SELinux.

Политика MLS базируется на формальной модели Bell-LaPadula. В терминах этой модели все субъекты (процессы) и объекты (файлы) имеют свой уровень допуска. Субъект с определенным уровнем допуска имеет право читать и создавать (писать/обновлять) объекты с тем же уровнем допуска. Кроме того, он имеет право читать менее секретные объекты и создавать объекты с более высоким уровнем. Субъект никогда не сможет создавать объекты с уровнем допуска ниже, чем он сам имеет, а также прочесть объект более высокого уровня допуска.

Для поддержки MLS традиционный контекст SELinux, состоящий из трех частей: пользователь, роль и тип, был дополнен уровнем допуска. Уровень допуска состоит из диапазонов чувствительности данных (например, "секретно", "ДСП") и категорий данных ("отдел кадров", "отдел финансовой отчетности").

MCS

Если воспользоваться преимуществами многоуровневой системы безопасности (multilevel security – MLS) можно только при использовании "строгой" (strict) политики SELinux, то поддержка мульти-категорийной безопасности (MCS) доступна в "целевой" (targeted) политике, используемой по умолчанию. Всего доступно 1024 категории и один тип чувствительности данных. В MLS политике (а рассматриваемая мульти-категорийная безопасность – это подмножество MLS) контекст расширен и включает два уровня безопасности (security level):

user:role:type: sensitivity[:category,…][- sensitivity[:category,…]]

Первым указывается обязательный текущий уровень (low или current), затем через символ дефиса – наивысший разрешенный уровень (high или clearance). Каждый из двух возможных уровней безопасности включает в себя обязательную часть – чувствительность (sensitivity) данных и ноль или больше категорий (category). Sensitivity в целевой политике всегда будет s0. Чувствительности данных, отличные от 0, зарезервированы для государственных и военных организаций и используются только в политике MLS ("секретно", "совершенно секретно" и т.п.). Число категорий и чувствительностей данных можно поменять, если пересобрать политику из исходных кодов. Политика SELinux – модульная, и чаще всего приходиться компилировать только отдельные модули.

По умолчанию возможности MCS доступны, но не используются в целевой политике. Все файлы имеют чувствительность s0 и не имеют назначенных категорий. Поэтому если в выводе команды ls –Z нет уровня безопасности, это значит, что он равен s0.

Категории обозначаются как с0, с1,… c1024.

RSBAC

Проект RSBAC реализует мандатный и ролевой механизмы доступа. RSBAC – это среда для создания и использования различных моделей доступа. В её рамках уже разработаны несколько модулей – мандатный и ролевой механизмы и простое расширение списков доступа. С теоретической точки зрения эта работа основывается на публикации Абрамса и Ла Падула Обобщённая среда для управления доступом (GFAC, Generalized Framework for Access Control).

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

RSBAC распространяется под лицензией GPL и представляет собой набор патчей к текущему ядру Linux. В отличие от SELinux, в основную ветку ядра Linux RSBAC не входит.

Функционально RSBAC состоит из нескольких модулей, а центральный компонент принимает комплексное решение, основываясь на результатах, возвращаемых каждым из активных в данный момент модулей (какие модули задействовать и в каком объеме определяется на этапе настройки системы). Начиная с версии 1.1.0, в RSBAC включены следующие модули, реализующие различные функции и модели управления доступом:

· MAC (Mandatory Access Control). Модуль MAC обеспечивает принудительное управление доступом на основе модели Белла-Лападулы.

· FC (Functional Control). Данный модуль реализует простую ролевую модель, в которой доступ к системной информации разрешен только администраторам системы, а доступ к информации, связанной с безопасностью, разрешен только офицерам безопасности.

· SIM (Security Information Modification). Модуль SIM обеспечивает возможность модификации данных, помеченных как "security information", только администраторами безопасности.

· PM (Privacy Model). Данный модуль реализует модель безопасности, направленную на обеспечение приватности личных данных. Основная идея состоит в том, чтобы пользователь мог получить доступ к персональным данным только, если они ему необходимы для выполнения текущей задачи и если он авторизован на ее выполнение. Кроме того, цели выполнения текущей задачи должны совпадать с целями, для которых эти данные собраны, либо должно быть получено согласие субъекта этих данных.

· MS (Malware Scan). Этот модуль обеспечивает сканирование всех файлов на наличие вредоносного кода. Дополнительно, данный модуль может контролировать все запросы на чтение файлов и соединений TCP/UDP. В текущей версии модуль умеет обнаруживать вирусы Bliss.A, Bliss.B, VHP-648, Israeli, Eddie2, Dark Avenger и 1704C.

· FF (File Flags). Модуль FF предоставляет механизм установки и проверки флагов на файлы и каталоги. Причем, модифицировать флаги разрешено только офицерам безопасности системы. Пока поддерживаются флаги execute_only (для файлов), read_only (для файлов и каталогов), search_only (для каталогов), secure_delete (для файлов), no_execute (для файлов) и add_inherited (для файлов и каталогов).

· RC (Role Compatibility). Данный модуль определяет 64 роли и 64 типа для каждого вида объекта. Виды объектов: file, dir, dev, ipc (interprocess communication), scd (system control data), process. Для каждой роли отношение к различным типам и другим ролям настраивается индивидуально, в зависимости от вида запроса. Используя данный модуль, можно настроить разделение обязанностей между администраторами, избежав при этом назначения избыточных прав.

· AUTH (Authorization Enforcement). Задача этого модуля – контролировать запросы процессов на смену текущего идентификатора пользователя. Под контролем данного модуля программе недостаточно просто иметь установленный бит suid, ей необходим специальный атрибут, разрешающий такое действие. Причем, он может быть, как глобальным (uid может быть сменен на любой), так и списочным (процесс может сменить свой uid только на определенные).

· ACL (Access Control List). Этот модуль определяет, какие субъекты могут получать доступ к данному объекту, и какие типы запросов им разрешены. Субъектом доступа может быть как простой пользователь, так и роль RC и/или группа ACL. Объекты группируются по видам, но каждый имеет собственный список ACL. Если права доступа к объекту не заданы явно, они наследуются от родительского объекта с учетом маски наследования прав. Эффективные права доступа субъекта к объекту складываются из прав, полученных непосредственно, и прав, полученных через назначение на роль или членство в группе ACL.

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

RSBAC дает возможность избавить систему от общих недостатков Unix. Появление должности "офицер безопасности" (security officer, security administrator) решает проблему неподконтрольности основного администратора системы, а категории "офицер по защите данных" (data protection officer) децентрализует администрирование, позволяя практически реализовать принцип разделения привилегий, в соответствии с которым все критичные операции не должны производиться в одиночку.

Поиск по сайту: