Apparmor

Enabling profiles

Debian packages that install profiles to /etc/apparmor.d/ automatically enable them (complain mode). Other profiles need to be copied to this directory and manually set to complain or enforce mode.

For example to install an «extra» profile from the /usr/share/apparmor/extra-profiles/ directory provided by apparmor-profiles and set it to complain mode:

# list available profiles
$ ls /usr/share/apparmor/extra-profiles/

# install the profile
$ sudo cp /usr/share/apparmor/extra-profiles/usr.bin.example /etc/apparmor.d/

# set the profile to complain mode
sudo aa-complain /etc/apparmor.d/usr.bin.example

To set a profile to enforce mode, use aa-enforce instead of aa-complain. Beware though: many profiles are not up-to-date and will break functionality in enforce mode, be ready to !

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

Для начала отвлечемся и поразмышляем о том, что есть и зачем нужно еще что-то
прикручивать. Одна из задач любой ОС — обеспечить разделение информации,
основываясь, в первую очередь, на требованиях конфиденциальности и целостности.
Традиционная модель 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, которому
пророчат светлое будущее, но пока по умолчанию он нигде не используется. Давай
рассмотрим их особенности, а также плюсы и минусы.

3.2. Добавление профилей

Документация

Для получения более подробной технической информации читайте man apparmor. Чтобы узнать все детали синтаксиса файлов профилей, читайте man apparmor.d. Техническая документация на AppArmor в OpenSUSE содержится в файле , устанавливаемом вместе с пакетом apparmor-docs.

Загляните в каталог в Kubuntu или в OpenSUSE. Здесь вы найдете большое число дополнительных профилей как серверных процессов, так и «десктопных» (включая всеми любимую команду man). В этом же каталоге можно найти, в том числе, и профиль для Firefox и Opera – под контролем AppArmor ваш браузер станет еще более безопасным! В имени каждого из профилей закодировано контролируемое приложение: файл usr.bin.skype предназначен для программы skype, которая находится в каталоге /usr/bin/skype (первый слеш отбрасывается, остальные заменяются точкой).

Добавим эту программу к уже запущенным под контролем AppArmor. Для этого скопируем файл профиля в нужный каталог и перезапустим демон AppArmor:

в Kubuntu:

в OpenSUSE:

Теперь перезапустим демон и проверим, что приложение перешло под контроль AppArmor:

root: rcapparmor reload
Reloading AppArmor profiles : done.
root: rcapparmor status
...
13 profiles are in complain mode.
   /usr/sbin/identd
...
   /usr/bin/skype
...

Debug

AppArmor logs can be found in the systemd journal, in /var/log/syslog and /var/log/kern.log (and /var/log/audit.log when auditd is installed).

Diagnose if a bug might have been caused by AppArmor

Look in these logs for:

• ALLOWED (logged when a profile in complain mode violates the policy)

• DENIED (logged when a profile in enforce mode actually blocks an operation)

The full log message should provide more information on what exact access has been denied. You can use this to before turning them on in enforce mode.

Sometimes, it’s useful to disable a profile and to test again if the bug persists:

# disable a profile temporarily
$ sudo aa-disable /etc/apparmor.d/usr.bin.example
# after testing, re-enable it in complain mode
$ sudo aa-complain /etc/apparmor.d/usr.bin.example
# or in enforce mode
$ sudo aa-enforce /etc/apparmor.d/usr.bin.example

Desktop notifications

The apparmor-notify package provides desktop notifications (through aa-notify) when a policy violation occurs. The program should start automatically when you login.

• If auditd is not installed, your user should be a member of the adm Group

• If auditd is installed, /etc/xdg/autostart/apparmor-notify.desktop should be modified as Exec=sudo aa-notify -p -f /var/log/audit/audit.log

Disable AppArmor

AppArmor is a security mechanism and disabling it is not recommended. If you really need to disable AppArmor on your system:

$ sudo mkdir -p /etc/default/grub.d
$ echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=0"' \
  | sudo tee /etc/default/grub.d/apparmor.cfg
$ sudo update-grub
$ sudo reboot

Что имеем?

В процессе работы любого приложения могут возникать различные отклонения, приводящие в итоге к его аномальному выполнению. Это могут быть как системные сбои, ошибки в программировании, так и искусственно вызванные ситуации. И последнее далеко не редкость. Хакер, обнаружив, что при определенных условиях можно повлиять на выполнение программы, естественно, попытается этим воспользоваться.

Предсказать поведение программы во внештатном режиме практически нереально. Примером тому являются антивирусы, которые все время работают в «догоняющем» ритме, не обеспечивая защиту от 0-day атак. А вот нормальное поведение программы можно описать с помощью относительно простых правил. В результате появилось несколько проектов, реализующих концепцию упреждающей защиты. Среди них LIDS, GRSecurity, AppArmor и SELinux. Но большей известностью пользуются последние два.

SELinux (Security Enhanced Linux) появился в недрах U.S. National Security Agency (NSA) и стал доступен общественности под лицензией GPL в 2000 году. В нем использован ролевой контроль доступа (Role-based Access Control, RBAC), многоуровневая безопасность и принудительное присвоение типов (type enforcement). Код SELinux включен в ядро версии 2.6 (начиная с 2.6.0-test), для версий 2.4 и 2.2 имеются патчи. Кроме того, SELinux портирован под BSD и Darwin, а код оптимизирован для компьютеров, имеющих 32 и более процессора. Каждому файлу назначается контекст безопасности, который и определяет, какие процессы (пользователи) могут с ним работать. Несмотря на очень высокий уровень защиты и
поддержку в дистрибутивах RedHat, эта система так и не смогла приобрести широкую популярность из-за очень сложной процедуры настройки. Разработчики AppArmor резонно считают, что безопасность не должна идти в ущерб простоте, ведь чем сложнее система, тем больше вероятность, что она будет неверно настроена.

Обзор

AppArmor — это система безопасности Linux, основанная на мандатном управлении доступом. AppArmor ограничивает отдельные программы набором файлов, возможностями, доступом к сети. Такие ограничения называются политикой AppArmor для программы или просто профилем. AppArmor дополняет дискреционную модель доступа Unix: если доступ был разрешен системой, окончательное решение остается за AppArmor, который сверяет разрешения со своей политикой управления и доступа.
AppArmor поддерживает режим обучения профиля, который помогает пользователям писать и обновлять политики безопасности. Режим обучения позволяет создать и настроить профиль на примере запущенной программы. После полного обучения происходит переход в режим принудительного исполнения. Хотя результат создания такого профиля может быть более «мякгим», чем полностью ручная настройка для конкретного окружения и приложения, режим обучения требует значительно меньше усилий и знаний, необходимых для использования AppArmor.

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.

Чтобы просмотреть список загруженных профилей, достаточно считать файл /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.

调试除错

要查看AppArmor的运行日志，可以使用 systemd journal程序, 或者 /var/log/syslog 或者 /var/log/kern.log (或者 /var/log/audit.log 需要安装auditd 软件包).

当出现问题时，诊断是否是由AppArmor所引起的

在日志中找:

• ALLOWED （在complain模式下,违反策略时会记录到日志）

• DENIED (在enforce强制模式下实际阻止操作时会进行记录)

The full log message should provide more information on what exact access has been denied. You can use this to before turning them on in enforce mode. 完整的日志消息会提供的更多信息。你可以在进入enforce模式之前， 参考这些日志信息。

有时，可以禁用配置文件，以便测试问题是否仍然存在:

# 禁用一个配置文件
$ sudo aa-disable /etc/apparmor.d/usr.bin.example
# 测试之后，重新开启`complain`模式
$ sudo aa-complain /etc/apparmor.d/usr.bin.example
# 或者开启`enforce`模式
$ sudo aa-enforce /etc/apparmor.d/usr.bin.example

桌面通知

发生策略违规时，apparmor-notify 软件包可以使用aa-notify程序发送桌面通知，该程序您登录时自动启动。

• 如果软件包 auditd 没有安装, 则桌面用户应该作为 adm Group 组的成员。

• 如果软件包 auditd 已经安装 ,则应将 /etc/xdg/autostart/apparmor-notify.desktop 修改为 Exec=sudo aa-notify -p -f /var/log/audit/audit.log

禁用 AppArmor

AppArmor是一种安全机制，不建议禁用它。如果您确实需要在系统上禁用AppArmor，请执行以下操作：

$ sudo mkdir -p /etc/default/grub.d
$ echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=0"' \
  | sudo tee /etc/default/grub.d/apparmor.cfg
$ sudo update-grub
$ sudo reboot