Безопасный Linux : Часть третья. Архитектура безопасности

Евгений Ивашко, Сотрудник Института РАН, Институт прикладных математических исследований Карельского научного центра РАН.

Описание: Третья статья серии «Безопасный Linux» посвящена некоторым особенностям архитектуры AppArmor. Она будет полезна программистам и администраторам, которые хотят внести свой вклад в развитие продукта, а также более полно использовать в своих приложениях возможности этой системы обеспечения безопасности.

1. Введение

Перед вами третья часть серии «Безопасный Linux», которая завершает обзор системы AppArmor – следующие материалы будут посвящены уже другим технологиям обеспечения безопасности.

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

Одна из основных целей, которую ставили перед собой создатели программы – разработка простого и понятного обычному пользователю средства обеспечения мандатного контроля доступа. AppArmor, как и его «визави» SELinux, отделяет от системы каждое запущенное приложение подобием межсетевого экрана, защищая пользователя от вероятных уязвимостей и «брешей» в безопасности. Однако в пику SELinux (о котором подробно будет рассказано в следующих статьях серии «Безопасный Linux»), AppArmor создавался под лозунгом: «Ввод в действие политики безопасности за часы, а не за дни!». Потому что худшая система безопасности та, которая не была внедрена из-за своей чрезмерной сложности.

Еще одна важная особенность рассматриваемого продукта заключается в том, что он не может снизить безопасность в целом. Даже если вы настроили AppArmor с грубейшими ошибками, ваша операционная система не станет более уязвимой, чем была до его установки. На первый взгляд это может показаться неважным, однако является существенным свойством при оценке гарантированного уровня безопасности (см. врезку).

Следует отметить также, что AppArmor является абсолютно «прозрачным» для контролируемых приложений – ни установка, ни удаление системы безопасности не требуют от разработчиков программ никаких дополнительных действий. Приложение будет работать одинаково как под контролем системы безопасности (конечно, при правильно настроенном профиле), так и при отсутствии AppArmor в системе.

Какими средствами достигается такой эффект? Какие минусы есть у AppArmor? Ответам на эти вопросы и посвящена данная статья.

2. Архитектура AppArmor

С архитектурной точки зрения, AppArmor представляет собой прослойку между пользовательскими приложениями и ядром операционной системы. Играя роль посредника, программа «пропускает» через себя разрешаемые профилем действия (обращения к файлам и вызовы POSIX), блокируя все остальные. При этом выбор профиля для приложения делается на этапе вызова функции exec().

Высокоуровневая архитектура AppArmor представлена на рисунке 1.

Рисунок 1. Архитектура системы AppArmor

Все приложения (включая компоненты операционной системы, серверные и пользовательские программы), которым необходим доступ к ресурсам ядра, работают с ними через посредника – AppArmor. Система безопасности сопоставляет запросы программ с имеющимися профилями и, в зависимости от наличия и настроек профиля, разрешает или запрещает доступ к ресурсам. Для эффективного (т.е. с защитой от «обхода» средств безопасности и минимальными издержками производительности) выполнения своих задач AppArmor использует Linux Security Module, речь о котором пойдет ниже.

Наблюдаемые события (например, обращения приложений к ресурсам ядра или действия самой системы безопасности) AppArmor фиксирует в виде сообщений. В случае наличия соответствующих средств взаимодействия с пользователем, эта информация сообщается ему непосредственно, в противном случае – просто фиксируется в логах. В вариантах SUSE Linux настройку AppArmor (создание профилей и управление ими, а также системой в целом) можно производить с помощью Yast.

3. Обеспечение безопасности посредством Linux Security Modules

Для обеспечения безопасности посредством методов, используемых AppArmor, необходимо, чтобы механизмы контроля находились внутри ядра операционной системы. Изначально продукт поставлялся в виде исправления ядра, но это влекло за собой чрезмерные проблемы с его распространением и развертыванием. Впоследствии компания Immunix Inc., создавшая AppArmor, разработала для GNU/Linux 2.6 технологию, которая называется LSM: Linux Security Modules interface (интерфейс модулей безопасности Linux). Этот компонент предоставляет API ядра для модулей, что позволяет загружаемым модулям эффективно посредничать в управлении доступом. Список других разработчиков LSM включает в себя как сообщества, сформировавшиеся вокруг SELinux, открытых проектов IBM, так и множество отдельных разработчиков сообщества Open Source.

Посредничество на уровнях, отличных от уровня ядра, т.е. посредством библиотек, оставляет возможность обхода средства безопасности: атакующий может спровоцировать выполнение произвольного кода в скомпрометированном приложении (например, используя переполнение буфера), чтобы напрямую обратиться к ядру, обойдя таким образом библиотеку посредника. Безопасное посредничество может быть также выполнено заменой таблицы системных вызовов (как это делает Systrace – см. врезку), но это приводит к появлению трех значительных проблем:
Дублируемость кода. Ядро имеет богатую инфраструктуру для разрешения, например, запроса на открытие файла с именем "foo" в конкретный индексный дескриптор с помощью просмотра текущего каталога и т.д. Эта информация недоступна в момент осуществления системного вызова, поэтому программа-посредник должна дублировать код перевода имени в дескриптор до принятия решения о разрешении/запрещении доступа к файлу "foo". В худшем случае разрешение имени будет выполнено дважды, отрицательно сказываясь на общей производительности.
Безопасность SMP. Имя запрашиваемого файла находится в доступной для пользовательских процессов памяти, поэтому существует потенциальная уязвимость в период между разрешением доступа модулем безопасности посредника и разрешением доступа ядром. Модуль-посредник может дать разрешение на доступ к файлу "foo", после чего запрашивающее приложение изменяет свой запрос на "../bar". Этой атаке особенно подвержены компьютеры с симметричной многопроцессорностью (Symmetric multiprocessing – SMP), т.е. большинство компьютеров на основе многоядерных микропроцессоров.
Новые подходы в разработке ядра. По некоторым причинам (включая лицензирование по GPL) разработчики ядра, во главе с Линусом Торвальдсом, решили удалить возможность перезагрузки таблицы системных вызовов из ядра Linux 2.6, поэтому вмешательство в системные вызовы без реализации соответствующих исправлений проблематично на современных ядрах.

Учитывая указанные серьезные проблемы, вместо того чтобы становиться посредником при обращении к системным вызовам, LSM перехватывает эти вызовы глубоко в ядре. Когда процесс пользовательского уровня обращается к важным структурам ядра, таким как индексные дескрипторы (inodes), LSM перехватывает каждое обращение и переспрашивает у загруженного модуля LSM: "Это обращение разрешено?". Модуль LSM рассматривает ситуацию и принимает решение по управлению доступом, посылая ядру ответ «Да» или «Нет», что приводит либо к разрешению доступа, либо к запрещению и отсылке сообщения об ошибке запрашивавшему процессу. Такая технология контроля доступа позволяет приложениям типа SELinux и AppArmor выполнять свою работу без необходимости постоянной поддержки исправлений ядра.

4. Интеграция приложений с AppArmor

Если вы участвуете в разработке какого-нибудь приложения, особенно серверного или приложения корпоративного уровня, то для вас наверняка будут интересны возможности усиления безопасности с помощью AppArmor. Так, если ваше приложение не несет угроз операционной системе (а значит, и пользовательским данным, и другим приложениям) даже при наличии ошибок, то это может оказаться решающим конкурентным преимуществом по сравнению с альтернативными программами.

Первый и наиболее очевидный способ обеспечения такой защиты – создание профиля. Кто, как не разработчик, лучше всех знает, какие ресурсы необходимы программе! Однако возможностей простого профиля может быть недостаточно, если какой-то из подсистем приложения необходимы бóльшие права, чем остальной части программы. Для этого случая разработчики AppArmor предусмотрели интерфейс смены «шляпы» – профиля программы. Технология «смены шляпы» следующая: при возникновении необходимости перехода на другой профиль, в программе вызывается функция change_hat с именем нового профиля и идентификатором возврата в качестве параметров. Когда нужно будет вернуться на исходный профиль, функция change_hat вызывается с параметрами NULL и значением идентификатора, указанным ранее при переходе на новый профиль. Не так уж сложно, правда? Чтобы получить более подробные пояснения с примером исходного кода, наберите команду man change_hat. Функцию change_hat используют, например, пакеты apache2-mod_apparmor и tomcat_apparmor для обеспечения контроля подпроцесса Web-сервера Apache и контейнера сервлета Tomcat соответственно.

Если ваша программа вызывает какую-то внешнюю утилиту, то необходимости во встраивании поддержки AppArmor в приложение нет. Достаточно в профиле программы указать параметры защиты дочернего процесса: выполнить дочерний процесс со своим профилем (режим доступа px), выполнение с тем же профилем, что и родительский процесс (режим доступа ix) или выполнение без каких-либо ограничений (режим доступа ux). Параметр px обычно используется для широко распространенных программ, профили для которых поставляются в комплекте с AppArmor; разрешения родительского процесса (параметр ix) даются для небольших утилит, работающих с теми же файлами, что и вызвавшая их программа. Параметр ux разработчики не рекомендуют использовать, так как он полностью выводит дочерний процесс из-под контроля системы безопасности.

------------------------------------------------------

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

------------------------------------------------------

6. Достоинства и недостатки AppArmor

Основной недостаток и принципиальное отличие AppArmor от SELinux – это метод работы с приложениями, находящимися «под прицелом» системы безопасности. Так как о SELinux будет рассказано в следующих статьях серии «Безопасный Linux», то поговорим лишь о методе работы с приложениями, используемом в AppArmor.

AppArmor контролирует только те исполняемые файлы, путь к которым указан в профиле. Фактически, эта система безопасности отличает файлы не по выполняемым действиям или принадлежности к какому-нибудь приложению (группе приложений), а по расположению исполняемого файла. Недостаток такого подхода заключается в том, что при создании жесткой символической ссылки приложение «уходит» из-под контроля системы безопасности.

Другая проблема, также связанная с путями к файлам, заключается в контроле временных файлов. Многие программы в процессе работы создают файлы в каталоге /tmp. Если имя для создаваемого файла выбирается случайным образом, то в профиле приложения приходится давать программе доступ на запись/чтение для всего каталога /tmp. В результате потенциально уязвимое приложение может получить доступ ко временным файлам других программ.

Эти две проблемы берут свое начало из архитектурных основ AppArmor – такова расплата за возможность простого и быстрого развертывания системы безопасности.

7. Планы развития

AppArmor жив! Это одна из немногих хороших новостей проекта. К сожалению, развивается программа очень медленно. Компания Novell больше не ведет активной работы в рамках проекта – это значит, что хотя ресурсы на развитие AppArmor и выделяются, но их слишком мало для работы целой команды программистов. Это, безусловно, напрямую отражается на самом проекте – списки рассылки, посвященные AppArmor, не «пухнут» от сообщений, страница графика разработки (Roadmap) до сих пор не заполнена, а svn не обновляется неделями. Тем не менее оставшиеся разработчики продолжают трудиться над развитием системы – была проделана огромная работа, результатом которой стал выпуск AppArmor версии 2.3 (список изменений можно найти по ссылке 3 раздела «Ссылки»), в планах выпуск версии 3.0 (пункт 4 раздела «Ссылки»), но возможен и выпуск промежуточной версии 2.4 с исправлениями обнаруженных ошибок.

Основные идеи, двигающие вперед разработку и лежащие в основе новых возможностей, следующие:
конечно же, прежде всего – обратная совместимость с версией 2.3;
основная задача – оставить AppArmor как можно более простым для использования;
расширение возможностей профилей приложений;
обеспечение большей градации возможностей контроля там, где это необходимо;
предоставление возможностей контроля использования приложениями сетевых ресурсов и IPC (interprocess communication – взаимодействия между процессами).

Конечно же, наличие активных программистов приблизит выпуск новой версии и увеличит число нововведений. Вот что рекомендовал новичкам ведущий разработчик AppArmor Джон Йохансен (John Johansen) в списке рассылки:

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

Я бы посоветовал начать с документации, описывающей архитектуру, а затем принять участие в обсуждении разработки версии 2.4. Если вам больше интересно высокоуровневое программирование, я бы рекомендовал поискать для начала что-нибудь простое и изолированное. Например, обновление апплетов gnome или kde.

Если вы больше интересуетесь вещами, связанными с ядром, начните просто с просмотра кода модуля и задайте возникшие вопросы. Затем попробуйте улучшить функциональность, например самодиагностику apparmorfs – возможность просмотра каждого загружаемого модуля и хэширования его содержимого была бы чрезвычайно полезной. Если это вам не подходит, есть другие задачи, связанные с сетевой подсистемой, ipc и т.д.

Если вам больше интересна разработка инструментов, вы можете взглянуть на каталог utils, особенно файл SubDomain.pm, который является интерфейсом для logprof и genprof. Здесь есть очень много работы, начиная от улучшения взаимодействия, заканчивая профилировкой и улучшением производительности».

------------------------------------------------------

Критерии оценки доверенных компьютерных систем министерства обороны («Оранжевая книга» Министерства обороны США)
Systrace – это утилита обеспечения безопасности компьютера, ограничивающая доступ приложений к ресурсам операционной системы с применением политики безопасности к системным вызовам. В частности, Systrace защищает от уязвимостей, связанных с переполнением буфера, а также полезна при запуске приложений, полученных из недостоверных источников. Утилита была разработана Нилсом Провосом (Niel Provos) и работает под управлением различных UNIX-подобных операционных систем.

------------------------------------------------------

8. Заключение

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

Эта статья заканчивает тему AppArmor. В следующих выпусках серии «Безопасный Linux» будет рассказано о конкуренте AppArmor – восходящей звезде, включенной в ядро Linux 2.6.30 и новейшие дистрибутивы – системе TOMOYO Linux. Также в фокус нашего внимания попадет давний визави AppArmor – система SELinux, разработка Национального агентства безопасности США.

http://www.ibm.com/developerworks/ru/library/l-apparmor-3/

Обновлено: 13.03.2015