Rule Set Based Access Control для Linux

СЕРГЕЙ ЯРЕМЧУК, фрилансер. Автор более 800 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС

Rule Set Based Access Control для Linux

Linux-системы, как многие другие в UNIX-семействе, имеют известный недостаток в управлении доступом. Прежде всего это малое количество контролируемых прав доступа, состоящих в разрешении чтения, записи и возможности выполнения, и права эти можно установить только для владельца файла, членов группы владельца и всех остальных. Иногда очень трудно вместить в предложенные ограничения даже пару десятков человек, при этом требуются более широкие возможности по описанию доступа к конкретному файлу. Дополнительно все программы, работающие от имени пользователя, имеют такие же права, как и сам пользователь, при этом совсем не учитывается важность самого объекта и вообще сама необходимость работы программы с ним. Сам пользователь файла решает, являются ли данные файлы секретными или будут доступными остальным пользователям. Отсюда получается, что запущенная от имени суперпользователя программа имеет неограниченные возможности в системе и доступ к любому объекту (эту модель еще называют одноуровневой). Все хорошо, пока она не скомпрометирована, и тогда такое упрощение становится уже большим недостатком. Такая модель доступа называется Discretionary Access Control (DAC) и позволяет создавать системы, защищенные по классу С1.

Естественно, сложившаяся ситуация не могла остаться нерешенной и было начато несколько различных проектов, в которых предлагался свой вариант решения данной проблемы. Об одном из них я уже писал в статье о SELinux в майском номере журнала. В данной разработке использована Role-Based Access Control (RBAC) модель доступа, позволяющая администратору определить роли и объекты в системе, к которым эти роли могут обращаться. Достаточно сказать, что в новое ядро версии 2.6 данная технология включена по умолчанию. Но данное решение не обладает достаточной гибкостью, и его удобнее все-таки использовать для создания специализированых решений. Второй проект, о котором уже говорилось на страницах журнала, – LIDS, позволяющий ограничить возможности пользователей (в том числе и root), но в некоторых вопросах только глобально, без «индивидуального» подхода.

Сегодня пойдет речь о проекте RSBAC (Rule Set Based Access Control), домашняя страница http://www.rsbac.org, который предлагает свой взгляд на решение проблемы разграничения доступа пользователей.

Архитектура RSBAC

RSBAC представляет собой гибкую, мощную и открытую модель управления доступа для ядра Linux, первая устойчивая версия 1.0.9а появилась на свет в январе 2000 года. Сам проект полностью не зависим от правительств и больших компаний и разрабатывается по лицензии GPL. Базируется RSBAC на архитектуре GFAC (Generalized Framework for Access Control Approach), предложенной Abrams и LaPadula. Основной особенностью предложенной системы была блочная структура, при которой каждый модуль реализует свою собственную модель защиты, что позволяет более гибко их использовать, отключая или включая нужный, и использовать одновременно несколько разных моделей защиты без конфликтов и противоречий между ними. Согласно подходу GFAC, предполагается разделение на три основных функциональных блока: AEF (Access Enforcement Facility) модуль, транслирующий системные вызовы в запросы на доступ, ADF (Access Decision Facility) осуществляет принятие решения и возвращает ответ (или ошибку), который при помощи модуля ACI (Access Control Information) транслируется в системный вызов. Также и в RSBAC система управления доступа ядром разделена на AEF- и ADF-компоненты и модуль ACI, все компоненты при этом жестко связаны в ядре. Сам ADF может состоять из нескольких модулей политик защиты, каждый из которых может подключаться/отключаться динамически, по мере необходимости обеспечивая требуемые задачи и гибкость в конфигурировании. В текущей версии 1.2.2 в комплекте имеется 12 модулей, реализующих восемь политик:

MAC – Mandatory Access Control, разработанная в 1973 году модель Bell La Padula. В системе выделяется множество объектов и множество субьектов, субъекты пытаются получить доступ к объектам, а система позволяет или не позволяет им это. Ее рекомендуется использовать, когда вы нуждаетесь в концептуально доказанной модели для осуществления конфиденциальности, но ее весьма трудно использовать в типичной UNIX-среде, так как придется описывать большое количество правил для каждого пользователя и программы. Возможен упрощенный вариант RSBAC MAC-Light.

FC – Functional Control. Простая роль-основанная модель, которая может использоваться, чтобы ограничить доступ к информации о безопасности. При этом каждому пользователю назначается определенная роль (офицер безопасности, системный администратор, обычный пользователь), а каждому объекту в свою очередь назначается категория (системный, секретный объект). Офицер безопасности определяет, какой роли можно обращаться к какой категории. Сейчас полностью вытеснена RC-моделью, параметры по умолчанию которой очень похожи на FC.

SIM – Security Information Modification. Эта ролевая модель контролирует доступ к данным типа защитная информация. Доступ на запись к этим объектам могут получить только пользователи с ролью офицера безопасности. Сейчас полностью может быть заменена RC-моделью.

PM – Privacy Model. Модель секретности Симон Фишер-Хубнера. Контролируемые данные могут быть защищены, только если они будут объявлены как персональные данные, поэтому может быть использована для хранения и обработки персональных данных, для системных данных должна использоваться другая модель.

MS – Malware Scan. Это не совсем модель контроля доступа, MS представляет собой средство предотвращения заражения инфицированным кодом. Сейчас по причине малого количества вирусов представляет собой демонстрационную модель.

FF – File Flags. Модель определяет некоторые флаги доступа к файлам, которые может изменять лишь пользователь с system_role «security officer». Это execute_only (files), read_only (files и dirs), search_only (dirs), secure_delete (files), no_execute (files), add_inherited (files и dirs), no_rename_or_delete (files и dirs, no inheritance) и append_only (files и dirs).

RC – Role Compatibility. Роль-основанная модель, при которой каждый пользователь имеет заданную по умолчанию роль, которая наследуется всеми его процессами. На основании текущей роли доступ к объектам некоторых типов будет предоставлен или отклонен. Роль может быть изменена со сменой владельца процесса, процессом через системный вызов (только «совместимые» роли) или выполнением специально отмеченной выполнимой программы (использованием initial_role или force_role).

AUTH – Authorization Enforcement. Можно рассматривать как модуль поддержки, который контролирует вызов смены владельцев для процессов (CHANGE_OWNER) и разрешает смену процессам только с разрешенными uid и если при этом процесс имеет установленный флаг auth_may_setuid.

ACL – Access Control Lists. Списки контроля доступа, определяющие, какой субъект (пользователь, роль RC или группа ACL) может иметь доступ к какому объекту и с каким запросом (обычные запросы RSBAC или специальные ACL).

САР – Linux Capabilities. Для всех пользователей и программ можно определять минимальный и максимальный набор возможностей Linux («возможность установки специального права root»). При этом параметры настройки программы отменяют параметры настройки пользователя, и минимальные настройки отменяют максимальные параметры настроек. Это позволяет выполнять программы сервера от имени обычного пользователя или ограничивать права программ с установленным suid. Это единственный модуль RSBAC, который непосредственно сталкивается с существующим управлением доступа Linux.

JAIL – Process Jails. Этот модуль добавляет новый системный вызов rsbac_jail, который делает запрос chroot и добавляет дальнейшие ограничения на процесс запроса и все подпроцессы. Все jail-процессы можно найти в /proc/rsbac-info/jails (при включенном RSBAC proc support).

RES – Linux Resources. Для всех пользователей и программ определяется минимальный и максимальный Linux-набор ресурсов процессов (например, размер памяти, число открытых файлов, число процессов пользователя).

Кроме встроенных моделей, имеется модуль REG (Module Registration), обеспечивающий интерфейс для регистрации вашего собственного модуля решения, который может быть, но необязательно, реализован как модуль ядра Linux. Он допускает регистрацию для всех уместных запросов к коду решения так же, как для запросов обслуживания к выполнению структуры данных. Примеры модуля ядра можно найти в rsbac/adf/reg/adf_sample*.c. Разработчики уверяют, что RSBAC был проверен с многими параметрами конфигурации ядра и другими патчами, хотя стопроцентной гарантии не дают, но поддерживаются такие патчи, направленные на повышение защиты, как FreeS/WAN, OpenWall и GRSecurity. Из приложений поддерживаются практически все, направленные на серверные решения (samba, bind, qmail, postfix), VNC, (Open)SSH и даже X-Window (для поддержки последней необходимо включить опцию X support), что позволяет использовать данную систему на клиентских компьютерах. Независимость реализации от конкректной файловой системы означает нормальную работу в любой из поддерживаемых Linux: minix, ext2/3fs, ReiserFS (без проверки номера inode и secure_delete), xfs и vfat (хотя использовать последнюю и первую по крайней мере несерьезно). Из дополнительных возможностей следует отметить поддержку SMP (что позволяет использовать на мощных серверах), loopback mounts (для шифрования).

Установка

Для работы нам понадобятся:

• дополнительные расширения к ядру: rsbac-*.tar.gz;
• патч к ядру: patch-*.gz;
• утилиты администрирования: rsbac-admin-*.tar.gz.

А также само ядро с ftp.kernel.org, хотя можно обойтись и без самостоятельного наложения патча, а взять уже готовое ядро с ftp://rsbac.cz/mirrors/rsbac.org/kernels. Из уже подготовленных ядер имеются версии ветки 2.2, 2.4 и современные 2.6-test, так что выбирать тоже есть из чего. Мы же будем рассматривать все с самого начала, хотя здесь нет чего-то особенного. Единственное, на что необходимо обратить внимание, – соответствие версий патча версии ядра и версий расширения к ядру и утилиты администрирования, т.е. в обозначении, например, такого патча patch-2.4.22-v1.2.2.gz, первые цифры 2.4.22 означают ядро, а 1.2.2 – версию расширений.

Распаковываем архив с ядром.

# tar xvjf linux-2.4.22.tar.bz2

Переходим в образовавшийся каталог.

# cd linux

Распаковываем остальные архивы и накладываем на ядро патч.

#  tar xvjf ../rsbac-v1.2.2.tar.bz2

Примечание: в старых версиях утилиты (до 1.0.9a) можно найти патчи также и внутри этого архива.

#  gzip -dc ../patch-2.4.22-v1.2.2.gz | patch -p1

Это обязательная программа, т.к. при работе пользователи часто сталкиваются с ошибками, все исправления которых представлены в bugfixes. Поэтому имеет смысл ознакомиться с ними и пропатчить ядро для их устранения.

# wget -c http://www.rsbac.org/bugfixes/rsbac-bugfix-v1.2.1-1.diff

# patch -p1 < rsbac-bugfix-v1.2.1-1.diff

И теперь конфигурируем ядро:

# make menuconfig

При этом в меню появляется еще один пункт, названный «Rule Set Based Access Control», активировав который, можно получить компьютер, защищенный по классу В1. Большинство опций документированы, остановлюсь лишь на интересных. Для изучения незаменимой является опция RSBAC soft mode, позволяющая отключать режим управления доступом при загрузке, передавая параметр ядру rsbac_softmode (просмотреть текущий режим можно, прочитав /proc/rsbac-info/{stats|debug}). При серьезных проблемах, когда нельзя добраться до системы вообще, может понадобиться ядро с включенным параметром «RSBAC maintenance kernel» (CONFIG_RSBAC_MAINT), в котором отключаются все RSBAC-модули (чтобы избежать проблем при обслуживании, лучше отключить поддержку сети в таком ядре). При включенной опции «RSBAC proc support» в каталоге /proc появляется подкаталог rsbac-info, содержащий статистику по работе RSBAC (подробнее в README-proc) и позволяющий читать и записывать параметры некоторых настроек, но после проведения экспериментов все же лучше данный параметр отключить, зачем давать нападающему лишнюю информацию об используемой защите. Опция Inherit as default (CONFIG_RSBAC_DEF_INHERIT) позволяет автоматически наследовать файлам и каталогам дополнительные параметры вроде security_level, data_type. Опция Support secure delete (CONFIG_RSBAC_SECDEL) позволит удалять файлы безвозвратно, в настоящее время безопасное удаление поддерживают только модули FF (файлы, помеченные как ff_flag secure_delete) и PM (для файлов, помеченных как personal data), при этом оставшееся место заполняется нулями, поддерживаются файловые системы ext2, minix, msdos и vfat, включение данной опции несколько замедляет работу файловой системы. RSBAC extra statistics (CONFIG_RSBAC_XSTATS) появляется дополнительная статистическая информация, которую можно прочесть в /proc/rsbac-info/xstats. Log full path позволит заносить полное имя файла в журнал, иначе в нем будет прописано только имя файла, доступ к которому протоколируется. Для работы необязательно включать все модули, оставьте те, которые вам действительно нужны, остальные не трогайте, так как использование RSBAC, естественно, влияет на производительность системы, и чем больше будет проверок, тем больше это будет сказываться на общей производительности. По результатам тестов, которые можно посмотреть на http://www.rsbac.org/benchmark.htm, максимально возможная потеря производительности составляет меньше 10 процентов. Например, я использую модули auth, MAC, RC и ACL. Хотя в некоторых случаях бывает достаточно PM или FF. Для каждого обязательно включите параметр «имя_модуля protection for AUTH module», остальные, как правило, можно и не трогать.

Чтобы получить новое расширение -rsbac вводим:

# touch Makefile

И компилируем ядро:

# make dep bzImage modules modules_install

Копируем получившееся ядро в /boot и конфигурируем загрузчик.

До версии 1.0.9b перед загрузкой с новым ядром необходимо было обязательно установить утилиты администрирования rsbac-admin, при этом создавался каталог /rsbac для каждой примонтированной файловой системы со специальным файлом useraci. Сейчас данный каталог автоматически создается ядром, а при отсутствии файла useraci используются настройки по умолчанию.

Но почему бы не установить утилиты сейчас. Для этого распаковываем их в любой каталог.

# tar xvzf rsbac-admin-v1.2.2.tar.gz.

# cd  rsbac-admin-v1.2.2

# ./configure (если используется ядро, находящееся в каталоге, отличном от /usr/src/linux, его местонахождение указываем

при помощи –with-kerneldir)

# make && make install

Примечание: для работы очень желательна утилита dialog не ниже версии 0.9, ее взять можно тут же на http://www.rsbac.org/dialog/dialog-0.9b-20020814.tar.gz.

И теперь нужно создать две дополнительные учетные записи. Первая – офицер безопасности – secoff (security officer/RC role admin/ACL Supervisor), и в файле /etc/passwd установить его uid равным 400. И если вы будете использовать модуль privacy module (PM), то и офицер защиты информации – dataprot (data protection officer) с uid 401. Которые теперь понадобятся для администрирования – root уже не будет достаточно. При необходимоcти изменить заданные по умолчанию числа uid, это можно сделать в макросах RSBAC_SECOFF_UID и RSBAC_DATAPROT_UID в include/rsbac/types.h. Или при конфигурировании ядра в соответствующих опциях.

Все теперь готово для первой загрузки, при которой система выдаст большое количество сообщений о невозможности запуска тех или иных сервисов. Интересно, что теперь в систему может попасть пока только root, и все потому, что программа входа в систему /bin/login имеет недостаточные права изменить владельца процесса (setuid). Но root в данном случае уже абсолютно бесполезен, он может по-прежнему запускать сервисы, монтировать диски, т.е. заниматься непосредственно администрированием системы, а вот изменить доступ к программам уже не может. Все это теперь возложено на плечи совсем другого пользователя – secoff. Причем сменить root на этого пользователя тоже не удастся.

bash-2.05b# su secoff

Для того чтобы разрешить смену uid, загружаемся с параметром rsbac_auth_enable_login (все остальные параметры описаны в файле README-kernparam). Устанавливать параметры файлов можно при помощи команд (вызванные без параметров, они выдают справку) или, что более наглядно, при помощи меню. Первоначально меню можно сконфигурировать, используя rsbac_settings_menu. Теперь устанавливаем параметры файла /bin/login и незапустившихся демонов, для этого используем команду rsbac_fd_menu имя_программы или rsbac_menu и далее выбираем нужный файл. Обратите внимание, сколько появилось дополнительных параметров у файлов, но работают только те, которые соответствуют запущенным модулям. За сменой uid, как вы помните, следит модуль auth, для того чтобы этот модуль «не замечал» смену uid процессом на любой, у него должен быть установлен параметр auth_may_setuid, установку которого и надо проконтролировать для /bin/login, после чего уже можно загружаться и входить в систему в обычном режиме. Для демонов же лучшим вариантом будет жестко зафиксировать uid, на которые может переходить процесс, запущенный от его имени. Для этой цели воспользуемся параметром auth_capabilities, который позволяет задать список (или диапазон) допустимых uid, на которые может переходить программа. А узнать, какой uid требуется каким процессам, очень просто, открываем под root системные логи (secoff туда не пускают) и ищем подобные сообщения:

В которых говорится, что процесс с именем sendmail безуспешно пытался сменить (CHANGE_OWNER) свой текущий uid с 0 на value 15 и получил от ворот поворот от AUTH. Теперь осталось добавить uid 15 в список auth_capabilities для программы sendmail, после чего проблем с его запуском уже не будет.

Теперь для полноценной работы давайте познакомимся с возможностями некоторых модулей поподробнее.

Модуль FF

Нравится мне своей простотой и возможностями одновременно. Его удобно использовать, когда необходимо просто добавить некоторые дополнительные флаги для файлов, каталогов и каналов FIFO, глобально для всех пользователей, не сильно утруждая себя работой с более сложными моделями. При включении данного модуля появляется возможность установить еще деcять дополнительных параметров:

• execute_only – (для FILE, FIFO, SYMLINK) возможно только исполнение;
• search_only – (DIR) обеспечивается полное закрытие каталога от проникновения;
• read_only – (FILE, FIFO, SYMLINK, DIR) возможно только чтение;
• write_only – (FILE, FIFO, SYMLINK) возможна только запись (но не чтение), применив данный флаг к каталогу /var/log, в котором находятся файлы журналов, при наследовании (см. ниже) мы не сможем их прочесть;
• secure_delete – (FILE) безопасное урезание и удаление, при котором освобожденное место заполняется нулями (только для ext2, ext3, msdos/vfat, minix);
• no_execute – (FILE) возможно что угодно, только не выполнение, назначив этот флаг на пользовательский каталог /home, мы лишим их возможности запуска своих программ;
• no_delete_or_rename – (FILE, FIFO, SYMLINK, DIR) нельзя удалять или переименовывать отмеченные таким образом файлы и каталоги;
• append_only – (FILE, FIFO, SYMLINK) доступ на запись ограничен только APPEND_OPEN и WRITE, на чтение доступ разрешен, установив данный флаг на каталог с файлами журналов, вы сможете дописывать в них информацию и читать;
• add_inherited – (FILE, FIFO, SYMLINK, DIR) если установлен, то к собственным флагам объекта будут добавлены и флаги родительского каталога, при этом он включен по умолчанию для всех, кроме флагов no_delete_or_rename и add_inherited, которые всегда должны быть установлены явно;
• no_mount – запрещает монтировать устройство.

Эти флажки проверяются при каждом доступе к данным целевым типам, и только пользователи в sys-tem_role «security officer» могут изменять флажки. Атрибуты независимы друг от друга и разграничены, т.е. все атрибуты, которые установлены, будут применены, например, execute_only и no_execute вместе (или read_only и write_only) не ведут ни к какому доступу. Или, установив на каталоге флаги search_only и execute_only, вы можете производить поиск файлов (не чтение) в каталоге и запускать файлы на выполнение, и больше ничего. Имеет смысл установить для каталогов /sbin, /bin, /usr/sbin, /usr/bin и других, содержащих исполняемые файлы, флаги search_only и read_only, позволим тем самым обращаться к файлам, зная полный путь и запретив изменять находящиеся внутри файлы, или, имея только двоичные файлы, установить для них флаг execute_only, позволив лишь только запуск на исполнение и ничего более и защитив их от подделки. По-моему, по сравнению со стандартной моделью у сисадминов появилось больше возможности контролировать доступ. Но, например, если необходимо контролировать доступ с точностью до миллиметра, этого будет явно недостаточно, в этом случае в самый раз придется следующий модуль.

Модуль ACL

Заходим в пункт меню «ACL Menu: Go to ACL menu», где переходим к «Change Mask». А теперь для каждого файла можно выбрать еще 25 параметров, причем можно отдельным пунктом включить сразу все относящиеся к security или системным параметрам:

• APPEND_OPEN – открывать для добавления;
• CHANGE_OWNER – сменить владельца;
• CHDIR – сменить рабочий каталог;
• CLOSE – запрос на закрытие;
• CREATE – запрос на создание;
• DELETE – запрос на удаление;
• EXECUTE – запрос на запуск;
• GET_PERMISIONS_DATA – прочитать права UNIX (mode);
• GET_STATUS_DATA – получить информацию о файле (stat() и пр.);
• LINK_HARD – создать жесткую ссылку;
• MODIFY_ACCESS_DATA – изменить информацию о времени доступа; время, дата (utimes ());
• MODIFY_ATTRIBUTE – изменить атрибуты RSBAC;
• MODIFY_PERMISSIONS_DATA – изменить права UNIX;
• MOUNT – монтирование файловой системы;
• READ – чтение;
• READ_ATTRIBUTE – чтение атрибутов RSBAC;
• READ_WRITE_OPEN – открыть для чтения и записи;
• READ_OPEN – открыть для чтения;
• RENAME – переименование;
• SEARCH – поиск;
• TRUNCATE – усечение файла;
• UMOUNT – размонтирование файловой системы;
• WRITE – разрешена запись;
• WRITE_OPEN – разрешено открытие файла для записи;
• MAP_EXEC – выполнение.

Это для обычных файлов и каталогов, для процессов и сетевых устройств есть и специфические параметры:

• ADD_TO_KERNEL – добавлять модуль в ядро;
• ALTER – изменить контрольную информацию для IPC;
• CHANGE_GROUP – сменить группу;
• CLONE – клонировать процесс (fork/clone);
• REMOVE_FROM_KERNEL – удалить модуль из ядра ;
• MODIFY_SYSTEM_DATA – изменить системные данные;
• SEND_SIGNAL – послать сигнал;
• SHUTDOWN – остановка или перезагрузка системы;
• SWITCH_LOG – изменять параметры протоколирования RSBAC;
• SWITCH_MODULE – включать и выключать модули;
• TERMINATE – запрос на окончание процесса (exit());
• TRACE – трассировка процесса (ptrace());
• BIND – связать сетевой адрес и порт с локальным сокетом или сетевым устройством;
• LISTEN – слушать локальный сокет listen();
• ACCEPT – прием подключения от сети accept();
• CONNECT – соединение с удаленной сетью connect();
• SEND – посылка сообщения удаленной сети send();
• RECEIVE – получение сообщения от удаленной сети recv();
• NET_SHUTDOWN – остановка локального socket.

Теперь, выбрав какой-нибудь каталог, устанавливаем на него необходимые атрибуты. Эти атрибуты будут действовать на всех пользователей. А для того чтобы предоставить исключительные права на созданный каталог или файл отдельному пользователю или группе пользователей, выбираем пункт «Add ACL Entry:Add group, role or user entry», где выбираем пользователя из списка (или создаем отдельную ACL group), и для него появляется свой список атрибутов для данного объекта. Таким образом можно установить параметры с любой точностью.

Остальные модули разбирать, пожалуй, сейчас не будем. Но из всего рассказанного должно быть понятно, что технология RSBAC позволяет избавиться от традиционных недостатков UNIX-систем, тем самым существенно поднять уровень защиты и задавать индивидуальные параметры для каждого пользователя и объекта доступа. На данный момент технология RSBAC применяется в четырех дистрибутивах: ALTLinux Castle (http://castle.altlinux.ru), Kaladix (http://www.kaladix.org), Trusted Debian (http://www.trusteddebian.org) и базирующийся на Debian LiveCD, который можно найти на сайте (http://livecd.rsbac.org). Последний позволяет познакомиться с данной технологией, не устанавливая все на жесткий диск. Кроме множества документации, имеющейся на www.rsbac.org, по-русски можно прочитать в статье одного из разработчиков RSBAC Станислава Иевлева «RSBAC для начинающих» (http://linux.ru.net/~inger/RSBAC-DOC.html).

Комментарии могут оставлять только зарегистрированные пользователи