Simplicity is the soul of security…

SELinux seems to have been designed to meet the NSA’s

desire for arbitrarily complex policy at the expense of usability…

AppArmor was designed to meet the needs of most Linux users.

Crispin Cowan, основатель Immunix Inc.

Проблема ограниченных возможностей традиционной модели разграничения доступа в Linux волновала не только угрюмых исследователей Дворца Загадок; и FLASK, разрабатываемый под очень специфичные требования TCSEC, был не единственной разработкой. Безопасный Linux хотели не только NSA и компания, но и народ попроще – бизнесы, сисадмины и даже обычные пользователи, разглядывающие котят.

AppArmor не может похвастаться такой же богатой историей, как SELinux, однако на качестве конечного продукта это никак не отразилось. Просто он получился немного проще.

Неизвестно, о ком больше думали Криспин Коуэн (Crispin Cowan) и команда его разработчиков – о котятах, пользователях или бизнесах, когда в конце девяностых годов прошлого века приступили к реализации проекта «Grand». Задачи, в общем-то, были те же, что и у NSA – разработать инструменты, которые способны дополнить традиционный DAC и предоставить гибкий механизм разграничения прав доступа. И, как не странно, у ребят кое-что получилось – на свет появились StackGuard (защита от атак переполнения буфера (buffer overflow)), FormatGuard (защита от атак на функции форматирования строк(format string attack)) и SubDomain (механизм, ограничивающий приложения). Для успешного продвижения всех этих фич в 1998 году Криспин Коуэн основывает компанию WireX. Главным продуктом компании стал коммерческий rhel-based дистрибутив Immunix, в котором и были реализованы все вышеперечисленные разработки. Однако успешного продвижения новоиспеченной ОС не получилось — дистрибутив как-то не пошел, а там еще и NSA бесплатно (sic!) стало предлагать свой SELinux. Поэтому в 2004 году все работы по разработке собственного защищенного дистрибутива сворачиваются, компанию переименовывают в Immunix Inc., а SubDomain переписывают под LSM и включают его поддержку в SUSELinux.

В 2005 году IT-гигант Novell покупает Immunix Inc, переименовывает SubDomain в AppArmor и публикует исходники под лицензией GNU GPL. Специалисты компании начинают вычищать и частично переписывать код для его включения в mainstream-ветку Linux kernel. В период с 2005 по 2007 годы AppArmor активно развивается, специалисты Novell выпускают несколько версий.

Интересное событие произошло в октябре 2007 года — Novell увольняет большую часть команды разработчиков AppArmor. Доподлинно неизвестно, что послужило поводом, но можно предположить, что руководство компании просто-напросто засомневалось в способности AppArmor составить достойную конкуренцию SELinux. Косвенно эту версию подтверждает тот факт, что в 2008 году в OpenSUSE появляется поддержка Security Enhanced Linux. Такое событие не оставили без внимания и разработчики конкурирующей технологии. Так Рассел Кокер (Russell Coker), подлил масла в огонь, заявив, что появление поддержки SELinux в OpenSUSE фактически означает смерть AppArmor.

После увольнения сотрудников Nowell выпустит еще одну версию AppArmor, однако на этом мутуализм Novell и AppArmor закончится.

В 2009 году, видимо посчитав, что недостаток конкуренции — это плохо для рынка, а единообразие — плохо для безопасности, Canonical «подбирает», брошенный Nowell’ом AppArmor. Под их началом полуживой инструмент вновь начинает совершенствоваться и развиваться. И всего лишь через год, в 2010 году, AppArmor вошел в состав Linux kernel 2.6.36.

Под теплым крылышком Canonical AppArmor развивается и по сей день.

Прежде чем приступить к дальнейшему знакомству с AppArmor, очень советую не полениться и ознакомиться со статьей «Знакомимся с SELINUX и пытаемся понять, почему Дэн Уолш плачет».

Фишка AppArmor в том, что он разрабатывался для простых пользователей.

Как было сказано ранее — задачи у AppArmor и SELinux в общем-то схожи. Однако, SELinux изначально разрабатывался как механизм разграничения доступа, предоставляющий ультимативную безопасность, абсолютный контроль над всей системой и возможность использования гибких политик под разнообразные задачи. У разработчиков не стояло задачи реализовать всё это и еще «чтоб как-нибудь попроще настраивалось и администрировалось». Нет, ни в коем случае! Только безопасность «изо всех сил», только хардкор! И надо сказать, разработчики SELinux достигли поставленных целей, но цена всему этому – сложность реализации, настройки и сопровождения. Это сейчас SELinux уже не такой страшный, но всё же, если есть желание разобраться во всех тонкостях его работы, то готовьтесь подзалипануть над его документацией на неопределенное время.

Перед AppArmor (SubDomain) никогда не стояло подобных задач. Он изначально разрабатывался для удовлетворения требований большинства пользователей. Идея разработчиков заключалась в том, чтобы создать простой, но гибкий механизм, который не доставлял бы больших неудобств при работе с системой. Благодаря ориентации на программы, а не на всю систему, AppArmor получился относительно небольшим и простым в реализации. Плюс небольших реализаций в том, что они оставляют меньше возможностей допустить ошибки в коде, требуют значительно меньших затрат производительности и, пожалуй, самый главный плюс – просты в настройке и сопровождении.

AppArmor проще потому, что он ориентирован ТОЛЬКО на процессы.

Защита AppArmor основана на профилях (profiles). Профиль приложения — обычный конфигурационный файл со своим синтаксисом. Используя профиль, AppArmor ограничивает процесс и предоставляют ему только минимально необходимые для работы возможности и привилегии. И если в SELinux могут использоваться еще и пользователи, роли, типы, уровни и категории, то в AppArmor — один только профиль.  Контроль пользователей оставили на откуп традиционному DAC — решили, что этого будет достаточно.

Вместо маркирования всех субъектов и объектов системы, в профилях AppArmor применен pathname-based подход. Его сущность заключается в том, что в профиле приложения определяются записи путей и записи разрешений. Записи путей (path entries) определяют, к каким объектам файловой системы приложение может получить доступ. Записи разрешений (capability entries POSIX.1e) устанавливают, какие разрешения ограничиваемый процесс может получить.

Кстати! Поначалу для SELinux приоритетной являлась «Stict Policy». Но эта политика была настолько строгой, что для большинства обычных пользователей понятия «нормальная работа» и «SELinux» стали несовместимы. Как это все отразилось на репутации SELinux’а и на психическом состоянии Дэна Уолша – все мы прекрасно знаем. :) Что сделали разработчики? Быстренько выбрали приоритетной «Targerted Policy», которая характеризуется тем, что ограничивает только выбранные приложения и при этом практически не использует ни пользователей, ни ролей. Вы не находите такое поведение схожим с моделью, на которую сделали ставку разработчики AppArmor? ;)

Pathname-based проще в реализации, так как не требует маркирования всех объектов ОС и не зависит от файловой системы. С другой стороны, это менее секьюрно. AppArmor работает с абстракцией вида /full/path/to/file, в то время как SELinux использует индексные дескрипторы (inodes) и расширенные атрибуты файловой системы. Как известно, объекты ФС могут иметь несколько pathnames и, следовательно, один и тот же объект может управляться различными профилями по-разному.

Лирическое отступление. Также как и в случае с Type Enforcement, возникает вопрос, можно ли считать такой вот pathbased-подход настоящим Mandatory Access Control про который пишут в «Оранжевой книге»? Зануда внутри меня уверенно отвечает: «Нет!» Но мы снова позволим себе маленькую слабость и будем считать AppArmor «одной из форм» MAC. Но имейте ввиду: ребята в погонах такой MAC точно не оценят!

И архитектура AppArmor тоже немного проще.

Изначально продукт поставлялся в виде патчей для ядра, но впоследствии был переписан под LSM. К слову, именно Криспин Коуэн предложил использовать LSM для подключаемых модулей безопасности, а компания Immunix внесла значительный вклад в разработку LSM.

Так как AppArmor работает через LSM, алгоритм перехвата запросов на доступ ни чем не отличается от такового у SELinux. После проверки DAC-прав, LSM перехватывает каждое обращение и переспрашивает у загруженного модуля AppArmor: «Это обращение разрешено?». Модуль LSM рассматривает ситуацию и принимает решение по управлению доступом, посылая ядру ответ «Да» или «Нет»:

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

Для принятия решения о предоставлении или запрете доступа AppArmor использует данные профиля приложения. Разработчики позаботились о том, чтобы при каждом обращении AppArmor не нагружал файловую систему во время поиска нужного файла профиля. Вместо этого используется специализированный кэш (AVC, привет!) – при запуске AppArmor, имеющиеся текстовые профили парсятся в определенную структуру данных и загружаются в оперативную память. При необходимости они всегда доступны модулю AppArmor, что очень положительно сказывается на производительности.

А еще AppArmor проще в настройке и понимании

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

AppArmor предлагает два режима контроля приложений. Enforce mode — в котором AppArmor ограничивает выполнение процесса в соответствии с его профилем, а все отказы регистрирует в log-файле. Complain Mode – AppArmor не ограничивает приложение, однако система регистрирует все отказы к предоставлению доступа, как это было бы в Enforce mode. Этот режим полезен для тестирования и разработки новых профилей.

Так же как в SELinux, в AppArmor есть аналог permissive domains. Часть приложений могут выполнятся в Enforce Mode, другая часть — в Complain Mode.

Работа с профилями приложений не должна доставить много проблем. Помимо того, что множество профилей уже создано сообществом, можно воспользоваться утилитами из комплекта apparmor-utils, которые позволяют создавать профиль в полуавтоматическом режиме подобно утилите audit2allow. Но, как и в случае с SELinux, с утилитами aa-genprof и aa-logprof нужно быть крайне осторожным и если уж использовать их, то только для генерации шаблона. Если же Вы не готовы доверить генерацию профилей машине, то точно оцените понятный и user-friendly синтаксис написания профилей, освоить который сможет практически любой пользователь.

Без сомнения, правильно сконфигурированный SELinux способен предоставить системе гораздо более высокий уровень защиты. А политикам MLS/MCS AppArmor не может противопоставить ровным счетом ничего.  Да и разработчики не зря свои деньги получают – с каждым релизом политики SELinux поддерживают всё больше и больше приложений, а большинство проблем решаются тривиальными способами. Но при всех этих достоинствах у SELinux есть существенный недостаток – все его политики предлагаются конечному пользователю с посылом «товарищ, доверься нам – мы ведь профессионалы». И я, конечно, не вижу объективных причин не доверять разработчикам. Однако, понимание механизмов работы системы крайне важно, особенно, когда дело касается безопасности. В случае с AppArmor практически любой пользователь сможет не только самостоятельно написать (сгенерировать) профиль для любого приложения, но и понять, как это работает. А это очень важное преимущество. Для понимания SELinux придется на месяц-другой погрузиться в его увлекательный мир, и совсем не факт, что этого будет достаточно.

Для подтверждения вышесказанного, предлагаю ознакомиться со слайдом из презентации Криспина Коуэна:

SEL_APP_comparation

Хм, получается, что AppArmor во всем попроще.

Да, это действительно так. Но важно понимать, что проще – не синоним слова хуже. Как мы с вами выяснили ранее, продвинутые возможности SELinux нужны далеко не всем. Для большинства пользователей достаточными являются политики targeted. Напомню, что в таком режиме SELinux, также как и AppArmor, ограничивает только потенциально уязвимые приложения. А при таком сценарии использования и AppArmor и SELinux готовы предоставить пользователю сопоставимый и самое главное достаточный уровень безопасности.

И что же выбрать?

Если Вы еще не поняли, что оба инструмента заслуживают внимания, то можете дополнительно ознакомиться с мнениями разработчиков и простых пользователей:

С.Сowan — Securing Linux Systems with AppArmor — отличная презентация, в которой есть примеры использования AppArmor в бою.

Novell and Red Hat security experts face off on AppArmor and SELinux  — ведущие разработчики Novell и RHEL рассуждают о достоинствах и недостатках AppArmor и SELinux.

InsanityBit. Why I like AppArmor more than SELinux — мнение простого смертного (для нас оно тоже очень важно!)

SUSE.COM. AppArmor and SELinux Comparison — наглядное сравнение двух конкурентов.

И мое мнение, не претендующее на истинность: не стоит зацикливаться на каком-то одном из них — начинайте уже использовать то, что предлагает Ваш дистрибутив! :)

Товарищи! У нас ничья. Расходимся.