|
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.
|
, 
