Правила AppArmor

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

Кратко:
* AppArmor реализует мандатный контроль доступа на основе принципа «запрещено все, что не разрешено явно»;
* AppArmor контролирует только те программы, для которых существует и активен профиль в режиме enforce;
* для AppArmor важен абсолютный путь к контролируемой программе – именно он отличает одно приложение от другого;
* AppArmor разрешает только те действия, которые перечислены в правилах профиля программы, запрещая все остальные;
* Существуют два режима контроля: тестовый режим complain (режим обучения), при котором действия не запрещаются, но в лог-файл записывается сообщение о нарушении правил профиля программы, и enforce – рабочий режим, при котором доступные программе действия ограничиваются согласно профилю;

На каком-то этапе я осознал крутость AppArmor в плане дополнительной защиты к существующим правам доступа (легендарные rwxr--r--) и прочитав отличные статьи на ibm.com:профили:

• Безопасный Linux : Часть первая. AppArmor – песочница для приложений.
• Безопасный Linux : Часть вторая. AppArmor – разработка профилей.

ринулся их создавать.

Прочитав статьи, в которых создание профиля AppArmor показывалось на примере программы passwd, у меня сложилось ложное мнение, что создание профиля программы в AppArmor это "раз, два и готово". Взявшись сразу создавать профиль для Adobe Reader, как весьма уязвимого приложения, я огрёб сразу кучу проблем и вопросов.

Создание профиля Adobe Reader в AppArmor

Первая моя неправильная мысль была такая:
1) Перейдите в каталог с профилями AppArmor (в Ubuntu это каталог /etc/apparmor.d/). Создадим заготовку профиля приложения в AppArmor. Это можно сделать командой aa-autodep /путь/к/программе.

2) По умолчанию профиль создается в обучающем режиме complain, поэтому, чтобы бы мы не делали (даже не правильно), программа будет запускаться и ничто ей не будет мешать, AppArmor будет только журналировать ошибки. В нашем примере, профиль для Adobe Reader будет вначале пустой и не содержит наших разрешений (помните философию «запрещено все, что не разрешено явно», что забудете разрешить, то будет запрещено приложению).

3) Возьмём команду tail -f /var/log/syslog и будем отлавливать строки вида
apparmor="ALLOWED" operation="open" parent=16703 profile="/opt/Adobe/Reader9/bin/acroread//null-7b2" name="/etc/ld.so.cache" pid=16707 comm="pwd" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
apparmor="ALLOWED" operation="file_mmap" parent=17350 profile="/opt/Adobe/Reader9/bin/acroread//null-7ea" name="/lib/libc-2.12.1.so" pid=17352 comm="cut" requested_mask="mr" denied_mask="mr" fsuid=1000 ouid=0

В них, на первый взгляд, есть всё что нужно! Пустой профиль в обучающем режиме complain как бы не позволяет программе
/opt/Adobe/Reader9/bin/acroread получить доступ requested_mask="r" denied_mask="r" в файлу name="/etc/ld.so.cache".

4) Я было ринулся ваять скрипт, который выдирал и причёсывал нужные мне данные из лога и помогал бы мне в составлении правил для AppArmor, НО ПРОБЛЕМА в том, что в логах СРАЗУ что необходимо приложению вы НЕ НАЙДЕТЕ! Вы будете вынуждены создать ЧАСТЬ правил, описать их в профиле приложения, снова повторить запуск программы, получить новую порцию данных и так снова и снова.
Представив масштаб трагедии, я приуныл. Идея по частям ловить в логах сообщения AppArmor НЕВЕРНАЯ!

Потом пришла вторая ПРАВИЛЬНАЯ мысль, нужно запустить программу под strace (трассировщик системных вызовов), который доложит нам, к каким файлам обращалась программа во время своей работы.

Для этого:
1) Перейдите в каталог с профилями AppArmor (в Ubuntu это каталог /etc/apparmor.d/). Сделаем заготовку профиля приложения в AppArmor. Взяв в качестве примера Adobe Reader, выполните команду aa-autodep /usr/bin/acroread. Должен создаться профиль Adobe Reader под названием opt.Adobe.Reader9.bin.acroread. Если вы спросите, а почему файл не называется usr.bin.acroread? Ответ: /usr/bin/acroread это shell скрипт, который после различных проверок всё равно запускает /opt/Adobe/Reader9/bin/acroread

2) Создайте скрипт 0strace_program и подправьте его под вашу программу, который запустит strace с нужными параметрами.

#!/bin/bash
# Новая версия статьи и скрипта расположена по адресу vasilisc.com/rules_apparmor
# способ 1
strace -f -e trace=open,access,execve -o 0strace.log /usr/bin/acroread
# способ 2
#sudo strace -f -e trace=open,access,execve -o 0strace.log -p $(pidof -s google-chrome)
exit 0


Под strace запустится программа, в данном случае /usr/bin/acroread и начнётся журналирование в файл 0strace.log. На этом этапе необходимо как можно полнее пользоваться программой - открывать всевозможные окна, нажимать кнопки. Обязательно открыть пункты связанные с печатью, шрифтами, пробежаться в окне настроек программы, открывать и сохранять файлы. Возможно, вы увидите некоторые настройки программы, которые захотите отключить в целях безопасности (я отключил в настройках Adobe Reader - Java и доступ в Интернет). Чем полнее вы исследуете программу, тем меньше работы дальше. Закройте исследуемую программу, в данном случае Adobe Reader.

3) Посмотрите получившийся отчёт от strace в файле 0strace.log, он большой и содержит строки вида:
17353 open("/dev/null", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
17353 execve("/bin/pwd", ["/bin/pwd"], [/* 46 vars */]) = 0
17349 access("/etc/ld.so.preload", R_OK) = -1

В них мы видим какие и как вызывались сторонние команды (execve("/bin/pwd") и к каким файлам происходило обращение
(access("/etc/ld.so.preload", R_OK)).

4) Нужно большой файл 0strace.log чуток причесать и отсортировать строки. В помощь создадим скрипт 1clearlog. Запустите его и скрипт создаст файл 1strace_clear.log

#!/bin/bash
# Новая версия статьи и скрипта расположена по адресу vasilisc.com/rules_apparmor
cat 0strace.log | cut -d"=" -f1 | cut -d"(" -f2 | sort -u > 1strace_clear.log
exit 0


5) Теперь открываем 1strace_clear.log и файл профиль opt.Adobe.Reader9.bin.acroread (см. пп 1). В помощь возьмём таблицу режимов доступа, используемых в профилях AppArmor.

Так же пригодится таблица используемых шаблонов.

При использовании шаблонов * и ** возникают некоторые нюансы, которые могут оказаться полезными на практике.
Продемонстрируем их на примере:
/tmp/* – все файлы в каталоге /tmp
/tmp/*/ – все каталоги в каталоге /tmp
/tmp/** – все файлы и каталоги по иерархии ниже каталога /tmp
/tmp/**/ – все каталоги по иерархии ниже каталога /tmp

6) Пользуясь советами, начинаем формировать правила для Adobe Reader в файле opt.Adobe.Reader9.bin.acroread

a) AppArmor активно использует понятие шаблонов профилей, которые находятся в каталоге /etc/apparmor.d/abstractions/. Например, часто программы используют в своей работе шрифты и, естественно, к ним обращаются, например, читают файлы в /etc/fonts/. Чтобы не создавать каждый раз правила разрешающие использовать шрифты, лучше подключить шаблон профиля шрифтов, в котором уже находятся нужные правила. Подключение шаблона профиля шрифтов осуществляется директивой #include <abstractions/fonts> в файле opt.Adobe.Reader9.bin.acroread. Приведу еще пример, если вы видите в файле 1strace_clear.log, что иследуемая программа использует файлы Gnome, то проще не мучаться с составлением своих правил, а
подключить #include <abstractions/gnome>.

b) Если вы видите строки вида
"/bin/cat", ["cat", "/opt/Adobe/Reader9/Reader/AcroVe"...], [/* 47 vars */])
"/bin/ls", ["/bin/ls", "-l", "acroread"], [/* 47 vars */])
то это говорит о том, что исследуемая программа вызывала их и нужно разрешить выполнение данных программ. Поэтому в файл
opt.Adobe.Reader9.bin.acroread добавляем разрешающие правила /bin/cat rmix, /bin/ls rmix,

Что такое rmix? Смотрим таблицу режимов доступа - даём право прочесть файл (r), даём право отобразить исполняемый файл в память (m), из всех прав запуска выбираем "Новый процесс будет запущен под профилем текущего" (ix). И получаем rmix.

Рекомендую для бинарных программ, которые располагаются в каталогах /bin/, /usr/bin/ использовать права доступа rmix. Многие зададутся вопросом: А может не расписывать для каждого вызванного бинарника из /bin/ правила, а сделать одно правило /bin/* rmix и тем самым разрешить вызвать любой бинарник. Ответ один: это ваш профиль вашей программы, будет ли он строгим (более безопасным) или чуток вольготным (менее безопасным) - решать вам и только вам!

c) Как вы знаете программы в Linux хранят свои настройки в домашней директории пользователя, поэтому неудивительно, если вы встретите в файле 1strace_clear.log строки вида
"/home/ваш_профиль/.adobe/Acrobat/9.0/Collab/OfflineDocs", O_RDONLY)
"/home/ваш_профиль/.adobe/Acrobat/9.0/Preferences/mozilla/prefs.js", O_WRONLY|O_CREAT|O_EXCL, 0644)
Эти две строки прямо дают понять что часть файлов нужна на чтение. Взгляните на слово O_RDONLY - это же открытие файла на только-на-чтение ReaD ONLY. А часть файлов открывается на запись - об этом намекает параметр O_WRONLY и права доступа 0644.

В данном случае руки чешутся написать правило в файле opt.Adobe.Reader9.bin.acroread дающее полное право использовать каталог с
настройками программы:
/home/ваш_профиль/.adobe/** rwk,
Разрешаем в своем домашнем каталоге (/home/ваш_профиль/) в подкаталоге .adobe использовать любые каталоги и файлы (**) и даёте права читать (r), писать (w) и ставить блокировку на файл (k) и того суммарные права rwk.
Смущает только слово ваш_профиль, так как правило становится из-за него не универсальным. Догадливый скажет, что нужно правило написать так
/home/*/.adobe/** rwk,
Это отчасти верно, но AppArmor предлагает еще вариант с использованием своих переменных.
Подключите директивой #include <tunables/global> файл с переменными и можете написать правило в виде:
owner @{HOME}/.adobe/** rwk,
Как лучше описать правило решать вам!

7) Объединяя мощь шаблонов профилей (см пп. 6а), и, прописывая правила доступа к файлам и каталогам, мы создаем черновик профиля opt.Adobe.Reader9.bin.acroread. Время проверить наши правила! Так как мы вручную правим файл профиля opt.Adobe.Reader9.bin.acroread, то нужно перезапустить AppArmor и начать ловить в журнале сообщения, если мы что-то упустили.
sudo /etc/init.d/apparmor reload && tail -f /var/log/syslog
После перезапуска AppArmor будьте внимательны к выводимым им сообщениям. Запустите исследуемую программу, в данном случае Adobe Reader и следите за появляющимися сообщениями от команды tail -f /var/log/syslog. Если вы верно и полно создали правила, то строк вида apparmor="ALLOWED" profile="/opt/Adobe/Reader9/bin/acroread"
больше не должно появляться. Если строки все же появляются, то пользуясь этой информацией, уточните правила и снова
sudo /etc/init.d/apparmor reload && tail -f /var/log/syslog.

8) Поработайте в complain режиме с программой некоторое время. Отслеживайте программой tail -f /var/log/syslog сообщения. Через
некоторое время можно решиться перейти из обучающего complain режима в рабочий enforce режим. Перейдите в каталог с профилями AppArmor (в Ubuntu это каталог /etc/apparmor.d/) и скомандуйте enforce opt.Adobe.Reader9.bin.acroread

9) Поздравляю! Создано правило для хронически уязвимой программы и профиль используется в рабочем режиме. Теперь AppArmor держит программу в жестком каркасе из которого "ни влево, ни вправо, прыжок на месте - расстрел".

Создание профиля браузера Opera в AppArmor

Выше мы описали этапы создания профиля Adobe Reader в AppArmor, но Adobe Reader хоть и имеет хронические проблемы с безопасностью, но не является сетевой. А с помощью AppArmor желательно защищать как раз сетевые программы, ведь через них, чаще всего, возможно проникновение на ваш компьютер. Вот на примере браузера Opera мы снова поучимся создавать профиль AppArmor. А почему скажете к браузеру Опера? Ну во-первых, для браузеров Firefox и Chromium уже есть готовые профили в Ubuntu, к Google Chrome профиля нет, но Chromium это тот же Chrome и можно взять его профиль и допилить.

1) Перейдите в каталог с профилями AppArmor (в Ubuntu это каталог /etc/apparmor.d/). Сделаем заготовку профиля Opera в AppArmor командой aa-autodep /usr/bin/opera. Создастся профиль usr.bin.opera в обучающем режиме complain.

2) Нам снова понадобится скрипт 0strace_program, подправьте его под запуск Opera /usr/bin/opera. Запустите скриптом Opera через strace и, как уже писалось выше, исследуйте Opera вдоль и поперёк. Чем тщательнее будете исследовать Opera, тем проще будет потом составить разрешающие правила.

3) Скриптом 1clearlog очистите вывод strace и получите файл 1strace_clear.log.

4) Откройте 1strace_clear.log и полупустой профиль Opera usr.bin.opera. Начнём формировать правила:

а) Строки вида
"/dev/null", O_WRONLY|O_CREAT|O_TRUNC, 0666)
"/dev/urandom", O_RDONLY)
превращаем в правила
/dev/null rwk,
/dev/urandom rk,
Так как "/dev/null", O_WRONLY|O_CREAT|O_TRUNC, 0666) намекает на необходимость чтения-записи - вот и даём права читать (r), писать (w), ставить блокировку (k). А строка "/dev/urandom", O_RDONLY говорит, что нужно только чтение (r) и блокировка (k).

б) Строки вида
"/bin/vim", X_OK)
"/bin/xemacs", X_OK)
говорят, что соответствующие программы были запущены для работы. Даём права rmix - читать и блокировать (rk), отображать в память (m), запускаться (ix):
/bin/vim rkmix,
/bin/xemacs rkmix,
/usr/bin/opera rkmix,

в) Когда видим /etc/fonts/, /var/cache/fontconfig/, то лучше не писать конструкций вида /etc/fonts/** r, а применить шаблон #include <abstractions/fonts>, который содержит нужные разрешающие правила для шрифтов.

г) Увидев, что Opera использует различные подкаталоги в вашем домашнем каталоге:
"/home/vasilisc/.gtk-2.0/2.10.0/engines/libqtcurve.la", F_OK)
"/home/vasilisc/.icons/redglass/cursors/fleur", O_RDONLY)
"/home/vasilisc/.kde/share/apps/Opera/toolbar/Opera.png", R_OK)
"/home/vasilisc/.local/share/icons/hicolor/", R_OK)
"/home/vasilisc/.opera/autoupdate.ini", O_RDONLY)
Я принял решение дать полный доступ rwk на мой домашний каталог, так как право читать (r) всё равно нужно дать - ведь я хочу открывать Оперой сохраненные страницы, а права записи тоже нужны, но на определенные каталоги. Вы можете написать свои более строгие правила и разрешить только на необходимые подкаталоги. Решая дать полный доступ в домашний каталог, пишу в профиле конструкцию:
owner @{HOME}/** rwk,
owner @{HOME} r,

д) Любая программа использует библиотеки и, естественно, будут использоваться каталоги и файлы вида
/lib/libc.so.6
/lib32/libpng12.so.0
/usr/lib/locale/locale-archive

Применяем шаблон #include <abstractions/base>, который содержит нужные разрешающие правила для библиотек.

е) Программа создает временные файлы в каталогах
/var/tmp/
/tmp/
и нужно дать возможность создавать и удалять файлы во временных каталогах. Применяем шаблон #include <abstractions/user-tmp>, который содержит нужные разрешающие правила для временных каталогов.

ж) Для Gnome и KDE нужно добавить шаблоны

#include <abstractions/gnome>
#include <abstractions/kde>

Это добавит разрешаюшие правила для таких каталогов как /usr/share/icons/

з) Упоминание о /proc/, заставляет добавить нас правила
/proc/** r,
/proc/ r,

и) Браузер Opera должен иметь доступ с сетевой подсистеме. Добавим следующие строки в профиль:
network inet stream,
network inet6 stream,
@{PROC}/[0-9]*/net/if_inet6 r,
@{PROC}/[0-9]*/net/ipv6_route r,

к) AppArmor способен контролировать другие возможности, не касающиеся прав чтения-записи-исполнения файловых объектов. В правилах профиля можно указывать разрешения на использование указанных в стандарте POSIX возможностей (например, изменение приоритетов выполнения процессов). Каждая такая возможность записывается за ключевым словом capability, а полный список доступных POSIX-возможностей можно увидеть, выполнив команду man capabilities (не забудьте при создании правила убрать «CAP_»
из названия возможности). Например, в примере профиля sbin.syslog-ng программе даются возможности chown (POSIX-возможность CAP_CHOWN) – произвольное изменение UID и GID файла; dac_override (по стандарту – CAP_DAC_OVERRIDE) разрешает программам, запускаемым привилегированным пользователем, не принимать во внимание режимы доступа к файлам и так далее.
Поэтому встретив строки
apparmor="ALLOWED" operation="capable" capname="sys_ptrace"
в выводе команды tail -f /var/log/syslog
добавляйте в профиль Оперы
capability sys_ptrace,

Удалить AppArmor

Если вы всё таки решили не мучаться с правилами, которые позволят улучшить безопасность и понимаете что делаете, то можно удалить AppArmor. Помните! Правила AppArmor - это дополнительный карсет для программ и просто одних прав доступа бывает не достаточно.
Но контролируя ситуацию, скрепя сердце вводите
sudo apt-get purge apparmor
И перезагрузка.

Дополнительная информация:
Безопасность Ubuntu
Защита сервера