Часть 2.1. SELinux. MLS и MCS: что с чем едят. MLS.

Продолжаем разговор, начатый постом «Часть 1. SELinux. Максимальный уровень защиты – бесплатно».

Вслед за сообщениями о сертификации Red Hat Enterprise Linux 5 по Common Criteria EAL4+ (c расширениями LSPP, RBACPP и CAPP) на серверах HP и IBM, компания HP объявила о начале предоставления услуги поддержки конфигурации RHEL с включенной многоуровневой системой безопасности (multilevel security -MLS).

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

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

Уффф… Надеюсь, я вас не запутал. По-английски это формулируется намного короче:
«write up, read down» и «no write down, no read up».

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

Переходим к техническим деталям реализации, а вернее – к эксперименту с их использованием. Как опциональная, политика MLS доступна начиная с Fedora Core 5. Именно тогда разработчики перешли с использования оригинальной Example Policy на Reference Policy от Tresys. MLS нельзя установить интерактивно через Anaconda (но можно установить при использовании kickstart-файла). На установленной системе даем команду

yum –y install selinux-policy-mls

Тем самым мы устанавливаем базовый модуль MLS, появившийся в RHEL третьим после «целевой» (targeted) и «строгой» (strict) политики. Собственно, этот третий вариант политики и появился в RHEL для соответствия сертификации EAL4+ LSPP. Данная политика поддерживает принудительный контроль доступа TE, RBAC, и, естественно, модель Bell-LaPadula. Далее нам нужно поправить /etc/sysconfig/selinux, сказав, что теперь используется наша новая политика MLS. Меняем policy=targeted на policy=mls. Теперь, поскольку все файлы на существующей ФС создавались во время работы «целевой» (targeted) политики, нам необходимо обновить SELinux-контексты для всех файлов. Самый простейший/правильный способ – команды

touch /.autorelabel; init 6

Когда появиться меню загрузчика GRUB, нажмите «a», и в конец строки, определяющей параметры загрузки ядра, добавьте enforcing=0. Это (естественно, только на время до перезагрузки) переведет SELinux в «разрешительный» режим, когда правила отрабатываются и файлы создаются с правильным контекстом безопасности, но ограничения, налагаемые политикой SELinux, не применяются. Нам это нужно для того, чтобы ничто не помешало обновить контекст безопасности файлов. Ваша система загрузиться так, если бы SELinux был отключен, и все контексты будут обновлены (если вы не ошиблись при наборе touch /.autorelabel) . Теперь настало время снова перезагрузится, но уже без параметра enforcing=0. Перед перезагрузкой убедитесь, что работает демон sshd. В принципе можно обойтись и без перезагрузки, зайдя в текстовую консоль как пользователь root и отдав команду


setenforce 1

Кстати, выбор политики и необходимость обновления контекста безопасности файлов во время перезагрузки можно произвести из GUI, используя system-config-selinux.



После перезагрузки зайдите на машину по ssh. Дает ли доступ к привилегиям команда su? А sudo? А получится ли перевести SELinux в «разрешительный» режим или вообще выключить? Нет. Попробуйте создать файл из-под учетной записи root, а потом простым пользователем посмотреть его метаданные командой ls. «Вместо строчки – только точки».
Также после перезагрузки вы уже не сможете работать с X Window (как не запустится и ряд других служб). Хотя бы из-за того, что будет существовать возможность скопировать информацию из окна терминала с высоким уровнем допуска в терминал с низким.

Привести свою тестовую (подчеркиваю, тестовую!) систему в исходное состояние вы сможете снова перегрузившись с параметром ядра enforcing=0 и выбрав «целевую» политику.

Написание «строгой» MLS политики весьма сложная и комплексная задача. И от версии к версии политика становиться более гибкой, охватывая большее число служб. Для простого пользователя многоуровневая безопасность – излишество. Для большинства задач достаточно того уровня безопасности, который достигается при использовании включенной по умолчанию «целевой» политики SELinux. Однако, и в рамках «целевой» политики можно использовать реализацию мульти-категорийной безопасности (MCS), о чем мы и поговорим в продолжении этого поста «Часть 2.2. SELinux. MLS и MCS: что с чем едят. MCS». А пока ждем выхода Fedora 8! ;)


Кстати, благодаря Dan Walsh, там уже должны появиться некоторые из моих переводов руководств по SELinux на русском.