AppArmor — расширение ядра, предназначенное для ограничения программ определенным набором ресурсов.
ОПИСАНИЕ
AppArmor — это расширение ядра, предназначенное для ограничения программ определенным набором ресурсов. Уникальная модель безопасности AppArmor заключается в том, что контроль доступа привязывается к программам, а не к пользователям.
Ограничение AppArmor обеспечивается посредством профилей, загружаемых в ядро через apparmor_parser(8), обычно через системный юнит apparmor.service, который используется следующим образом:
# systemctl start apparmor
# systemctl reload apparmor
AppArmor может работать в двух режимах: принудительном и режиме «complain» (сообщения):
принудительный режим — профили, загруженные в принудительном режиме, приводят к применению политики, определенной в профиле, а также к отправке сообщений о попытках нарушения политики в syslogd.
режим «complain» — профили, загруженные в режиме «complain», не применяют политику. Вместо этого они сообщают о попытках нарушения политики. Этот режим удобен для разработки профилей. Для управления режимом «complain» для отдельных профилей можно использовать утилиты aa-complain(8) и aa-enforce(8). Эти утилиты принимают имя программы в качестве аргумента.
Профили традиционно хранятся в файлах в каталоге /etc/apparmor.d/, с использованием соглашения о замене символа / в путях на . (за исключением корневого каталога /), чтобы профили было легче управлять (например, профиль /usr/sbin/nscd будет иметь имя usr.sbin.nscd).
Профили применяются к процессу во время выполнения exec(3) (как видно из системного вызова execve(2)): после загрузки профиля для программы эта программа будет ограничена при следующем выполнении exec(3). Если процесс уже выполняется с примененным профилем, при замене этого профиля в ядре обновленный профиль немедленно применяется к этому процессу. С другой стороны, процесс, который уже выполняется без ограничений, не может быть ограничен.
AppArmor поддерживает файловую систему securityfs в ядре Linux и предоставляет список профилей, в настоящее время загруженных; для монтирования файловой системы:
# mount -tsecurityfs securityfs /sys/kernel/security
$ cat /sys/kernel/security/apparmor/profiles
/usr/bin/mutt
/usr/bin/gpg
...
Обычно init-скрипт монтирует securityfs, если он еще не был смонтирован.
AppArmor также ограничивает привилегированные операции, которые может выполнять ограниченный процесс, даже если процесс выполняется от имени пользователя root. Ограниченный процесс не может вызывать следующие системные вызовы:
create_module(2) delete_module(2) init_module(2) ioperm(2)
iopl(2) ptrace(2) reboot(2) setdomainname(2) sethostname(2) swapoff(2) swapon(2) sysctl(2)
Режим «complain»
Вместо того, чтобы запрещать доступ к ресурсам, для которых в профиле отсутствует правило, AppArmor может «разрешить» доступ и зарегистрировать сообщение об операции, которая его вызвала. Это называется режим «complain». Важно отметить, что правила, которые присутствуют в профиле, по-прежнему применяются, поэтому правила разрешения по-прежнему будут подавлять или принудительно создавать сообщения аудита, а правила запрета по-прежнему будут приводить к запретам и подавлению сообщений о запретах (см. Отключите подавление сообщений аудита при запретах, если это вызывает проблемы).
Режим «complain» можно использовать для постепенной разработки профилей по мере выполнения приложения. Зарегистрированные доступы можно добавлять в профиль, а затем можно выполнять приложение дальше, чтобы определить, какие дополнительные элементы необходимы. Поскольку AppArmor разрешает доступ, приложение будет вести себя так, как если бы AppArmor не ограничивал его.
Внимание: режим «complain» не обеспечивает никакой безопасности, только аудит, пока он включен. Его не следует использовать в недружественной среде, поскольку нежелательное поведение может быть зарегистрировано и добавлено в профиль, как если бы это был доступ к ресурсам, который следует использовать в приложении.
Обратите внимание, что режим «complain» может быть очень шумным для новых или пустых профилей, но с разработанными профилями он может вообще ничего не регистрировать, если профиль хорошо охватывает поведение приложения. См. Ограничение частоты аудита, если режим «complain» генерирует слишком много сообщений в журнале.
Чтобы установить профиль и любые дочерние профили или профили-шапки, которые могут содержаться в профиле, в режим «complain», используйте:
aa-complain /etc/apparmor.d/<имя_приложения>
Чтобы вручную установить определенный профиль в режим «complain», добавьте флаг «complain», а затем вручную перезагрузите профиль:
profile foo flags=(complain) { ... }
Обратите внимание, что флаг «complain» также должен быть добавлен вручную в любые профили-шапки или дочерние профили данного профиля, иначе они будут продолжать использовать предыдущий режим.
Чтобы включить режим «complain» глобально, выполните:
echo -n complain > /sys/module/apparmor/parameters/mode
или для установки при загрузке добавьте:
apparmor.mode=complain
в качестве параметра загрузки ядра.
Внимание: установка режима «complain» глобально отключает всю защиту AppArmor. Это может быть полезно при отладке или разработке профиля, но более безопасно устанавливать его выборочно для каждого профиля.
При попытке ограниченного процесса получить доступ к файлу, к которому у него нет разрешения, ядро сгенерирует сообщение через audit, подобное следующему:
audit(1386511672.612:238): apparmor="DENIED" operation="exec"
parent=7589 profile="/tmp/sh" name="/bin/uname" pid=7605
comm="sh" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
audit(1386511672.613:239): apparmor="DENIED" operation="open"
parent=7589 profile="/tmp/sh" name="/bin/uname" pid=7605
comm="sh" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
audit(1386511772.804:246): apparmor="DENIED" operation="capable"
parent=7246 profile="/tmp/sh" pid=7589 comm="sh" pid=7589
comm="sh" capability=2 capname="dac_override"
Разрешения, запрашиваемые процессом, описываются в operation= и denied_mask=. (Для
файлов, а также для возможностей (capabilities), используется немного иной формат журнала). В журнале сообщается "name" и идентификатор процесса (PID) выполняемой программы, а также имя профиля, включая любой "hat", который может быть активен, разделенные двойной косой чертой ("//"). ("Name" заключено в кавычки, потому что имя процесса ограничено 15 байтами; оно такое же, как и сообщается через Berkeley process accounting).
Для ограниченных процессов, работающих под профилем, который был загружен в режиме отладки (complain mode), принудительное применение правил не будет осуществляться, и сообщения, отправляемые в audit, будут иметь следующий вид:
audit(1386512577.017:275): apparmor="ALLOWED" operation="open"
parent=8012 profile="/usr/bin/du" name="/etc/apparmor.d/tunables/"
pid=8049 comm="du" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
audit(1386512577.017:276): apparmor="ALLOWED" operation="open"
parent=8012 profile="/usr/bin/du" name="/etc/apparmor.d/tunables/"
pid=8049 comm="du" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Если пользовательский демон auditd не запущен, ядро будет отправлять события audit в klogd; klogd будет отправлять сообщения в syslog, который будет регистрировать сообщения с использованием уровня KERN. Таким образом, сообщения REJECTING и PERMITTING могут быть отправлены либо в /var/log/audit/audit.log, либо в /var/log/messages, в зависимости от локальной конфигурации.
ОТЛАДКА
AppArmor предоставляет несколько возможностей для ведения подробных журналов, что может помочь в отладке профилей.
Включение режима отладки
При включении режима отладки AppArmor записывает дополнительные сообщения в dmesg (не через подсистему аудита). Например, в журналах будет указано, применялась ли фильтрация переменных окружения.
Чтобы включить режим отладки, выполните:
echo 1 > /sys/module/apparmor/parameters/debug
или, чтобы установить его при загрузке, добавьте:
apparmor.debug=1
в качестве параметра загрузки ядра.
Отключение подавления аудита для запрещенных операций
По умолчанию операции, которые приводят к срабатыванию правил "deny", не регистрируются. Это называется подавлением аудита для запрещенных операций.
Чтобы отключить подавление аудита для запрещенных операций, выполните:
echo -n noquiet > /sys/module/apparmor/parameters/audit
или, чтобы установить его при загрузке, добавьте:
apparmor.audit=noquiet
в качестве параметра загрузки ядра.
Принудительный режим аудита
AppArmor может регистрировать сообщение для каждой операции, которая приводит к срабатыванию правила, настроенного в политике. Это называется принудительным режимом аудита.
Внимание! Принудительный режим аудита может быть чрезвычайно шумным, даже для одного профиля, не говоря уже о том, когда он включен глобально.
Чтобы установить для определенного профиля принудительный режим аудита, добавьте флаг "audit":
profile foo flags=(audit) { ... }
Чтобы включить принудительный режим аудита глобально, выполните:
echo -n all > /sys/module/apparmor/parameters/audit
или, чтобы установить его при загрузке, добавьте:
apparmor.audit=all
в качестве параметра загрузки ядра.
Ограничение частоты аудита
Если auditd не запущен, чтобы избежать потери слишком большого количества дополнительных сообщений журнала, вам, вероятно, потребуется отключить ограничение частоты, выполнив:
echo 0 > /proc/sys/kernel/printk_ratelimit
Но даже в этом случае буфер ядра может переполниться, и вы можете потерять сообщения.
В противном случае, если auditd запущен, обратитесь к auditd(8) и auditd.conf(5).
ФАЙЛЫ
/etc/apparmor.d/
/var/cache/apparmor/
/var/log/audit/audit.log
/var/log/messages
СМОТРИТЕ ТАКЖЕ
apparmor_parser(8), aa_change_hat(2), apparmor.d(5), aa-autodep(1), clean(1), auditd(8).