AppArmor

Данная технология является одной из реализаций мандатного контроля доступа для Linux. Изначально она была разработана компанией Immunix. Впоследствии эта компания была куплена Novell'ом, AppArmor был открыт под лицензией GPL и включен в ядро openSUSE. Кроме того, поддержка AppArmor была включена в дистрибутивы Mandriva и Ubuntu. Однако, некоторое время спустя, основатель и главный разработчик AppArmor Криспин Коуэн перешел на работу в Microsoft, а Novell объявила о начале полноценной поддержки в своих продуктах конкурирующей технологии SELinux, начиная с openSUSE 11.1 (подробнее об этих событиях). Впоследствии разработка AppArmor была возобновлена Джоном Йохансеном, сотрудником Canonical.

AppArmor позволяет контролировать полномочия процессов, определяя списки файлов с соответствующими правами (на чтение, запись, отображение в память и запуск, установку блокировки на файл и т.п.) для каждого приложения. Также AppArmor позволяет на самом общем уровне контролировать доступ к сети (например, запретить использование ICMP) и управлять POSIX capabilities.

Распознавание приложений и, соответственно, определение их полномочий, производится по имени исполняемого файла. Именно этот момент очень часто выступает ключевым в критике AppArmor. Действительно, подменив имя исполняемого файла, злоумышленник может вывести приложение из-под контроля AppArmor. Самый простой пример — создание жесткой ссылки. Более сложный вариант — выполнение mount --bind или pivot_root. Разумеется, последние два подхода должны блокироваться классической (дискреционной) системой контроля доступа, однако мандатный контроль доступа обычно вступает в игру после того, как дискреционный контроль удалось обойти (например, злоумышленник обнаружил уязвимость в suid-программе).

Конкурирующие решения для обеспечения мандатного доступа, SELinux (включен в ядро начиная с 2.6.0) и SMACK (включен в ядро начиная с 2.6.25), не подвержены подобным уязвимостям, так как используют метки безопасности, хранящиеся непосредственно в inode файла. Недостатком такого подхода является необходимость поддержки меток безопасности на уровне файловой системы. Однако в настоящее время такие метки поддерживаются большинством популярных файловых систем Linux, за исключением ReiserFS (версия 3.6 поддерживает Security Labels) и Reiser4. С другой стороны, не стоит забывать, что такие важные для промышленных задач возможности, как многоуровневая защита (MLS) и контроль доступа на основе ролей (RBAC) реализованы пока только в SELinux.

Также стоит отметить другого ключевого конкурента AppArmor — проект TOMOYO, принятый в ядро начиная с 2.6.30. Как и AppArmor, TOMOYO использует для различения программ пути к исполняемым файлам, однако его разработчики уделили гораздо больше внимания возможностям обхода такой защиты. В частности, TOMOYO, в отличие от AppArmor, позволяет контролировать права на операции mount --bind и pivot_root. Кроме того, в TOMOYO существует очень полезная возможность — контроль контекста вызова, например, для файла /bin/bash, запущенного файлом /usr/sbin/sshd, можно задать совсем другие права, нежели для того же файла /bin/bash, но запущенного файлом /bin/login.

Yama

Это простой модуль, разработанный для Ubuntu компанией Canonical и использующий возможности Linux Security Model для блокировки некоторых типов атак, в частности,

• Атак через подстановку символьной ссылки в общедоступном каталоге, например, /tmp. Многие приложения хранят свои временные файлы и символьные ссылки в каталогах, доступных на запись всем пользователям. В некоторых случаях злоумышленник может подставить свою символьную ссылку, обманом заставив приложение открыть совсем не тот файл. Yama позволяет заблокировать такую атаку, разрешив следование по символьным ссылкам в подобных каталогах только в том случае, если UID владельца символьной ссылки совпадает с UID процесса, пытающегося следовать по ссылке.
• Атак с использованием жестких ссылок. Разумеется, если некоторый файл недоступен на чтение либо запись для какого-либо пользователя, жесткая ссылка на данный файл будет иметь те же права и поэтому также будет недоступна этому пользователю. Однако, используя жесткие ссылки, злоумышленник может «подсунуть» такой файл приложению, которое имеет права на доступ к нему. Yama позволяет заблокировать эту атаку, запретив создание жестких ссылок пользователям, не имеющим прав на доступ к исходным файлам.
• Атак с использованием отладочного вызова ptrace. Без использования соответствующей защиты Yama, любой процесс с привилегией CAP_SYS_PTRACE может обращаться к памяти всех процессов с тем же UID'ом. При использовании Yama, можно ограничить область доступа только памятью, принадлежащей потомкам такого процесса.