Гонка вооружений: сравниваем популярные расширения безопасности для ОС Linux

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

Дискреционный и мандатный контроль доступа

Для начала отвлечемся и поразмышляем о том, что есть и зачем нужно еще что-то прикручивать. Одна из задач любой ОС — обеспечить разделение информации, основываясь, в первую очередь, на требованиях конфиденциальности и целостности. Традиционная модель Unix оперирует тремя параметрами — пользователь, группа-пользователь и остальные. Называется она дискреционной (Discretionary Access Control — DAC), то есть добровольной моделью доступа. Пользователь сам определяет права доступа к своим файлам, а выполняющиеся программы имеют те же права, что и запустивший их пользователь. Механизм DAC опирается в своей работе только на тождество пользователя, игнорируя другую информацию, например, о роли пользователя в системе, функции и уровне доверия конкретной программы и необходимости в целостности данных. Каждая учетная запись имеет полную свободу действий в пределах своих полномочий.

Как ты понимаешь, развернуться с DAC особенно негде: все или ничего; винда — и та дает больше возможностей по настройке доступа к объектам. Поэтому сегодня для Linux доступны решения, базирующиеся на совершенно другой модели защиты — MAC (Mandatory Access Control, принудительный контроль доступа). Они позволяют определить политики безопасности над всеми процессами и объектами, решение о доступе принимается на основе большего количества информации об объекте, а не только основываясь на тождестве пользователя. Причем MAC не отменяет, а дополняет DAC, так как сначала проверяются права Unix, и, если они запрещают доступ, то дальнейшая проверка просто не производится. Проверка прав выполняется только в том случае, если стандартные права Unix разрешают доступ к объекту. Любой объект помещается в некую виртуальную песочницу, которая позволяет приложению выполнять только строго регламентированные задачи. Причем при описании доступа к объекту конкретные реализации могут придерживаться разных принципов: очень строгие правила по типу "что не разрешено явно — запрещено" и "минимально необходимые привилегии".

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

В дистрибутивах Linux используются два решения: SELinux в RedHat и клонах, а также AppArmor в Ubuntu. В ядре версии 2.6.30 появился код еще одного проекта — TOMOYO Linux, которому пророчат светлое будущее, но пока по умолчанию он нигде не используется. Давай рассмотрим их особенности, а также плюсы и минусы.

Сверхзащищенный SELinux

Проект SELinux (Security Enhanced Linux, selinuxproject.org) зародился в недрах U.S. NSA (National Security Agency), хмурые неразговорчивые дядьки которого поставили своей целью допилить Linux таким образом, чтобы его можно было спокойно использовать не где-нибудь, а в правительственных системах. Анонсирован общественности в 2000 году, затем разработчики справедливо решили: зачем что-то делать самим, если в интернете есть много желающих? В результате сегодня проект развивается под лицензией GNU GPL и уже включен в состав ядра ветки 2.6.х, также выполнена адаптация для FreeBSD и OpenSolaris.

Реализация MAC требует четкого описания правил, что может привести к образованию большого их количества. Поэтому в SELinux использована концепция роль-основанного контроля доступа Role-Based Access Control (RBAC), в которой определяются роли и доступ пользователей. Механизм защиты в SELinux носит название Type Enforcement (TE) и позволяет закрепить за каждым процессом и файлом, которые необходимо контролировать, некую метку. Если процесс, запущенный от имени администратора, скомпрометирован, то ущерб, который может быть причинен системе, ограничен только тем, к чему он может обращаться, согласуясь с установленными для него правилами (а они описывают поведение очень тонко).

Также в SELinux реализована многоуровневая система обеспечения безопасности (MLS, Multi-Level Security model), но ее задействуют только в особых случаях, например, в правительственных многопользовательских системах, требующих чрезвычайно высокого уровня защиты.

Когда в процессе работы системы субъект пытается оказать некое действие на объект, SELinux принимает решение о допустимости указанного действия, основываясь на контекстах безопасности объекта и субъекта. Субъект — это процессы, выполняемые от имени запустившего их пользователя. Объект — элементы файловой системы (файлы, каталоги, ссылки, сокеты и пр.) или другие процессы, над которыми выполняются действия. И теперь самое важное, что отличает SELinux от других решений, описанных далее — все важные защитные атрибуты сохраняются в контекстах безопасности. Поэтому файловая система должна уметь хранить дополнительные атрибуты, и сами атрибуты нужно как-то задать. Современные ядра все обеспечивают, но при самостоятельной пересборке ядра не забудь активировать параметр "Extended attributes" в выбранной файловой системе.

Атрибуты устанавливаются при инициализации системы. Отсюда делаем вывод, что объект уже должен существовать на момент установки атрибутов. Сам атрибут включает идентификатор владельца, роль и тип объекта. Причем идентификатор SELinux (создается командой semanage), хотя и может совпадать в номере с UID пользователя Linux (uid), но это две разные вещи. Не забываем еще об одном важном отличии — SELinux оперирует ролями, поэтому несколько учетных записей Linux могут иметь одну и ту же учетную запись SELinux. И главное — выполнение команды

Проверить это легко:

$ id –Z
user_u:user_t:unconfined_t

Получаем привилегии суперпользователя и проверяем снова:

$ su
# id –Z
user_u:user_t:unconfined_t

Если зайти сразу под рутом, то роль другая:

# id -Z
root:system_r:unconfined_t:SystemLow-SystemHigh

Изменить роль можно при помощи команды newrole. При использовании SELinux штатные команды выводят и контекст. Чтобы  просмотреть контекст файлов и процессов, набираем:

# ls -l –context /
# ps -ax -Z

Кроме того, контекст можно считать прямо из /proc:

# ps aux | grep syslogd
root 2729 0.0 0.0 5908 624 ? Ss 07:30 0:00 syslogd -m 0
# cat /proc/2729/attr/current
system_u:system_r:syslogd_t:s0

Предусмотрена работа SELinux в трех режимах — disable (отключен), enforcing (политики выполняются, все, что не соответствует — блокируется), permissive (политики анализируются, все нарушения заносятся в журнал "avc: denied", но блокировки не производятся). Узнать текущий режим просто, как, впрочем, и некоторые другие настройки, достаточно прочитать данные из псевдофайловой системы /selinux:

$ cat /selinux/enforce

Если получим 1, значит, SELinux активирован. Чтобы изменить режим работы на лету, просто записываем в этот файл 0 или 1:

# echo 0 > /selinux/enforce

Также можно воспользоваться утилитой "setenforce [ Enforcing | Permissive | 1 | 0 ]".

Собственно настройки производятся в конфигурационных файлах, размещенных в каталоге /etc. В дистрибутивах, базирующихся на RedHat, доступен графический SELinux Administration Tool (system-configselinux, пакет policycoreutils-gui). Так, режим работы устанавливается в файле /etc/sysconfig/selinux (на самом деле это ссылка на /etc/selinux/config). В частности, режим работы определяет параметр SELINUX:

SELINUX=enforcing|permissive|disabled

По умолчанию в большинстве дистрибутивов SELinux защищает не все демоны, а только строго определенные: dhcpd, httpd, named, nscd, ntpd, portmap, snmpd, squid и syslogd. Для остальных политика не определена — unconfined_t. Чтобы защитить всю систему, необходимо изменить значение SELINUXTYPE на strict:

SELINUXTYPE=targeted|strict

В каталоге /etc/selinux/targeted/contexts находим описание контекстов.

Например, для root контекст описывается так:

# cat /etc/selinux/targeted/contexts/users/root
system_r:unconfined_t:s0 system_r:unconfined_t:s0
system_r:initrc_t:s0 system_r:unconfined_t:s0

Чтобы просмотреть все контексты, связанные с httpd, введи такую команду:

# grep -iR httpd /etc/selinux/targeted/contexts

Ты увидишь, что для разных ситуаций контекст будет отличаться. Теперь получим список всех параметров SELinux: "getsebool -a". Для установки используй команду setsebool (с ключом '-P' для сохранения значения после перезагрузки) или графическую утилиту system-configsecuritylevel. Вывод "sestatus -v" покажет все текущие установки. Не забываем и о журналах:

# dmesg | grep -i selinux
SELinux: Initializing.
SELinux: Starting in permissive mode
# grep -iR selinux /var/log/messages

Все вспомогательные утилиты SELinux собраны в нескольких пакетах: setools или policycoreutils, policycoreutils-newrole. Первый, как правило, уже установлен в системе, остальных нет. Например, newrole, дающая возможность пользователю сменить роль, доступна именно в policycoreutils. После установки в системе присутствуют только наборы политик для targened, остальные наборы политик скачиваются в пакетах selinux-policy*. Сорцы политик для их самостоятельной сборки вынесены в selinux-policy-devel.

Разобраться в более чем 200 файлах, имеющих несколько тысяч строк, врукопашную очень трудно. Автоматизировать эту задачу призван питоновый скрипт audit2allow (в policycoreutils), он генерирует новые политики на основе анализа журналов и блокировок SELinux.

Проекты LIDS, GRSecurity и RSBAC

Кроме проектов, описанных в статье, в настоящее время развиваются и другие, позволяющие повысить защиту Linux-систем — LIDS (Linux Intrusion Detection System), GRSecurity и RSBAC (Rule Set Based Access Control). Кратко о них.

Проект LIDS реализует MAC, админ может четко указать разрешения для файлов и каталогов. Помимо этого механизмы TPE (Trusted Path Execution) и TDE (Trusted Domain Enforcement) позволяют убедиться, что программа работает так, как предназначено. Сайт проекта некоторое время был заброшен, хотя инструменты развиваются. Управление производится при помощи утилит и чем-то напоминает настройку правил файера.

# lidsconf -A -o /sbin -j READONLY

GRSecurity — разработка, охватывающая несколько технологий укрепления безопасности — MAC/ACL, улучшенный chroot, рандомизация TCP ISN и PID, ролевая система контроля доступа RBAC, функции аудита, защита адресного пространства и стека PaX (доступен и отдельно). Большинство параметров указывается на этапе сборки ядра, затем при помощи утилиты gradm настраиваются ACL.

Проект RSBAC, реализующий мандатный и ролевой механизмы доступа, уже в 2000 году вовсю использовался в защищенных дистрибутивах. По сути, это среда, позволяющая создать различные модели доступа. Идея основана на публикации Маршала Абрамса и Ла Падула "Обобщенная среда для управления доступом" (GFAC, Generalized Framework for Access Control). Кроме root в ОС появляется учетка администратора безопасности, который и управляет доступом к информации. Реализовано много интересных функций: отключение Linux DAC, сокрытие процессов, JAIL, поддержка PaX, антивирусный интерфейс Dazuko, контроль ресурсов Linux и многое другое. Например, можно организовать доступ к файлу в определенные часы.

AppArmor

Технология Application Armor изначально разработана Immunix Inc. После того, как софтверный гигант Novell приобрел эту компанию, код открыли под лицензией GNU GPL, а затем включили в состав openSUSE. Позднее AppArmor стал доступен и в других дистрибутивах. Но когда команда Immunix покинула Novell, дальнейшее развитие проекта остановилось. И хотя в том же openSUSE поддержка AppArmor была сохранена, в дистрибутив интегрировали SELinux. В итоге начали разноситься слухи а-ля "AppArmor is dead", что у одних вызвало радость, так как теперь все усилия можно бросить на развитие одной системы защиты, у других критику — отсутствие конкуренции еще ни к чему хорошему не приводило. Сегодня апологетом этой технологии является Canonical, разработчики которого не смотря ни на что продолжают развитие AppArmor. Так, в последних версиях добавлен механизм кэширования правил, что позволило ускорить их загрузку. Для этих же целей, и чтобы защитить сетевые сервисы на раннем этапе загрузки, часть профилей вынесли в initramfs. И главное — в Ubuntu AppArmor прикрутили к LSM (Linux Security Modules), задействовав security_path вместо vfs.

Основная идея AppArmor состоит в том, что система защиты не должна быть сложной и не должна мешать. В отличие от SELinux, AppArmor не использует расширенные атрибуты и не зависит от файловой системы. Доступ к ресурсам определяется на основе профилей (profiles), которые привязаны к пути файла или каталога, причем самого файла может и не быть на момент активации профиля. Профиль разрабатывается индивидуально под каждое приложение. Хотя в этом есть и недостаток: при переносе файла в SELinux за ним полностью сохраняется контекст безопасности, в AppArmor — нет, но этого от него и не требовали. Хотя, если файл имеет два имени, и профиль блокирует доступ к одному из них, есть возможность работать с другим. Это следует учитывать. Также, если средствами SELinux можно предусмотреть несколько уровней доступа к объекту для разных субъектов, то AppArmor этого не умеет. В настоящее время созданы профили для большинства популярных серверов и приложений, поэтому наличие активного AppArmor обычно незаметно, он не создает проблем. Кроме того, в комплекте поставки идут два скрипта aa-genprof и aa-logprof, которые помогут быстро создать профиль для новой программы. Управление AppArmor производится при помощи init-скрипта, который запускает модуль ядра, инициализирует профили и монтирует псевдофайловую систему securityfs.

$ sudo /etc/init.d/apparmor start

Чтобы просмотреть список загруженных профилей, достаточно считать файл /sys/kernel/security/apparmor/profiles (или запустить /etc/init.d/apparmor status); в зависимости от варианта дистрибутива Server/Desktop количество активных профилей будет различно. Сами профили хранятся в файлах (отдельно для каждого приложения) в каталоге /etc/apparmor.d и внутри содержат описание каталогов и отдельных файлов, с указанием прав доступа. Также указывается работа в сети и совместимость с другими профилями. Для упрощения задачи используются регулярные выражения. По умолчанию профили AppArmor работают в принудительном enforce-режиме. Когда сервис не может выйти за рамки установок, все попытки блокируются и фиксируются в журнале. При необходимости его можно перевести в щадящий режим complain, когда нарушения лишь фиксируются. Причем, в отличие от SELinux, где режим обучения активируется глобально, в AppArmor его можно включить для отдельного профиля. Перевести профиль в щадящий режим можно тремя способами:

• указать в файле профиля flags=(complain);
• использовать команду complain название_программы (вернуть командой enforce);
• или глобально командой "echo 1 > /sys/kernel/security/apparmor/control/complain".

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

Дополнительные профили можно найти в репозитории дистрибутива (apt-cache search apparmor), кроме того, есть онлайн-банк профилей — apparmor.opensuse.org.

К слову, для ядер 2.4/2.6 существовала разработка Trustees, реализующая ACL a-ля Novell Netware, которая в удобной форме расписывала доступ к каталогам вплоть до указания отдельных групп и пользователей и не зависела от файловой системы. К сожалению, проект заглох, а это была бы золотая середина между SELinux и AppArmor.

Сбиваем спесь со Skype

Наверное, больше всего претензий с точки зрения безопасности у пользователя вызывает Skype. Куда только не лезет эта прога (см. статью Криса "Skype: скрытая угроза"). Описываемые технологии как раз и позволяют обезопасить себя. Забегая вперед, скажу, что пользователи уже давно нагенерировали профили для большинства популярных прог, и скайп здесь не исключение. Смотри, например, здесь: www.cynapses.org/tmp/apparmor/usr.bin.skype. Некоторые профили собраны в отдельном пакете — apparmor-profiles. Но профиль легко создать и самому. Для этого в комплекте идет утилита aa-genprof (или просто genprof). Запускаем ее с указанием исполняемого файла в качестве параметра:

$ sudo aa-genprof /usr/bin/skype

Далее работаем как обычно: звоним, отсылаем сообщения, принимаем файлы, добавляем и удаляем учетки. По окончании прерываем работу в каталоге /etc/apparmor.d/usr.bin.skype. Затем перезапускаем AppArmor или просто активируем профиль в enforce-режиме:

$ sudo aa-enforce skype

Все проблемы и замечания по работе профилей AppArmor ищи в логах.

TOMOYO Linux

Проект TOMOYO Linux начат в 2003 году японской компанией NTT DATA CORPORATION как легкая реализация MAC для Linuх-ядра. Через два года лицензию изменили на GNU GPL и выложили код на SF.net. Некоторое время проект предоставлял патчи и готовые сборки ядер для разных дистрибутивов. Но начиная с версии ядра 2.6.30, код TOMOYO Linux включен в основную ветку разработки, что уже само по себе — Событие для любого подобного проекта.

В настоящее время существует две версии TOMOYO Linux. Первая версия использует оригинальные хуки, она доступна только в виде патчей и может использоваться в ядрах 2.4 и 2.6. Вторая (которая уже в ядре) адаптирована под LSM, но по функциональным возможностям уступает версии 1.х: нет поддержки сетевых функций, обработки атрибутов, POSIX-возможностей (на сайте представлена сравнительная таблица). В настоящее время соответствующие пакеты имеются в репозиториях многих дистрибутивов, но фактически поддержка заявлена пока только в Mandriva. К слову, в этом дистрибутиве предлагается и графический интерфейс Tomoyo GUI, позволяющий запустить и настроить политики приложений. Доступность в репозиториях пакетов для большинства дистрибутивов позволяет буквально в считанные минуты перевести ОС на новую систему безопасности. Например, Ubuntu 10.04:

$ sudo echo 'deb http://osdn.dl.sourceforge.jp/tomoyo/47128/ ./' >> /etc/apt/sources.list
$ sudo apt-get update
$ sudo apt-get install linux-ccs ccs-tools

Если ядро собирается самостоятельно, активируй параметр "Enable different security models" и "TOMOYO Linux Support" в секции Security options.

При беглом взгляде TOMOYO очень похож на AppArmor. Обе системы контролируют путь (pathname based), а правила имеют сходный синтаксис. Но есть и отличия. Так, в TOMOYO можно указать поведение программы в зависимости от того, как она запущена. Например, оболочка, запущенная через SSH, может иметь больше ограничений, чем запущенная с локальной системы. Предусмотрена проверка дополнительных параметров, с которыми включена программа, а также привилегий (UID/GUD). Приложения в терминологии TOMOYO называются доменами (domains). Конфигурационные файлы TOMOYO находятся в каталоге /etc/tomoyo, после запуска системы настройки имеют свое отражение в /proc/tomoyo, где их можно редактировать на лету. Параметры работы TOMOYO хранятся в /etc/tomoyo/profile.conf и доступны в /proc/tomoyo/profile. Именно здесь определяются режимы работы TOMOYO — disable, permissive, enforsing и learning (обучаясь, система сама строит правила). Есть и другие файлы:

• manager.conf (/proc/tomoyo/manager) — программы, которые могут изменить политику в /proc/tomoyo;
• exception_policy.conf (/proc/tomoyo/exception_policy) — исключения для политик домена;
• domain_policy.conf (/proc/tomoyo/domain_policy) — политики домена;
• meminfo.conf (/proc/tomoyo/meminfo) — настройка использования памяти и квот.

После установки пакета ccs-tools необходимо провести инициализацию TOMOYO, выполнив скрипт /usr/lib/ccs/tomoyo_init_police.sh, который и создаст нужные конфиги. Далее потребуется перезагрузка системы. Затем можно запускать редактор политик:

# /usr/lib/ccs/editpolicy /etc/tomoyo/

Еще одна немаловажная черта — TOMOYO может работать параллельно с SELinux и AppArmor.