AppArmor — программный инструмент упреждающей защиты, основанный на политиках безопасности (известных также как профили (англ. profiles)), которые определяют, к каким системным ресурсам и с какими привилегиями может получить доступ то или иное приложение. В AppArmor включён набор стандартных профилей, а также инструменты статического анализа и инструменты, основанные на обучении, позволяющее ускорить и упростить построение новых профилей.
Кратко:- AppArmor реализует мандатный контроль доступа на основе принципа «запрещено все, что не разрешено явно»;
- AppArmor контролирует только те программы, для которых существует и активен профиль в режиме enforce;
- для AppArmor важен абсолютный путь к контролируемой программе – именно он отличает одно приложение от другого;
- AppArmor разрешает только те действия, которые перечислены в правилах профиля программы, запрещая все остальные;
- Существуют два режима контроля: тестовый режим complain (режим обучения), при котором действия не запрещаются, но в лог-файл записывается сообщение о нарушении правил профиля программы, и enforce – рабочий режим, при котором доступные программе действия ограничиваются согласно профилю;
- Безопасный 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/acroread2) Создайте скрипт 0strace_program и подправьте его под вашу программу, который запустит strace с нужными параметрами.
#!/bin/bash # способ 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
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.
Режим доступа | Опция | Описание |
Чтение | r | Разрешение на чтение файла. |
Запись | w | Разрешение на запись файла. |
Дописывание файла | a | Ограниченное разрешение на запись файла – процесс может только дописывать информацию в файл (полезно для лог-файлов!). |
Выполнение под профилем | px | Новый процесс запускается под своим профилем. Если профиля нет, то запуск процесса запрещен. |
Выполнение под профилем с очисткой окружения | Px | Новый процесс запускается под своим профилем, при этом AppArmor очищает переменные окружения. Если профиля нет, то запуск процесса запрещен. |
Наследование режима выполнения | ix | Новый процесс будет запущен под профилем текущего. |
Отображение исполняемого файла в память | m | Разрешение отображения файла в память и его запуска. |
Создание ссылки | l | AppArmor разрешает программе создание символической ссылки на файл и запуск. Разрешения файла те же, что и у исходного. |
Блокировка | k | Разрешение выполнения блокировки файла. |
Неконтролируемое выполнение | ux | Новый процесс никак не контролируется AppArmor. |
Неконтролируемое выполнение с очисткой окружения | Ux | Новый процесс никак не контролируется, но AppArmor очищает переменные окружения. |
Шаблон | Подстановка |
* | Любое количество любых знаков, за исключением символа каталога (/) |
** | Любое количество любых знаков, включая символ каталога (/) |
? | Любой одиночный знак, за исключением символа каталога (/) |
[ ade ] | Один из знаков: a, d или e |
[ a-c ] | Один из знаков: a, b или c |
{ ab, cd } | Либо ab, либо cd |
Продемонстрируем их на примере:
/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/brovko_rs/.gtk-2.0/2.10.0/engines/libqtcurve.la", F_OK) "/home/brovko_rs/.icons/redglass/cursors/fleur", O_RDONLY) "/home/brovko_rs/.kde/share/apps/Opera/toolbar/Opera.png", R_OK) "/home/brovko_rs/.local/share/icons/hicolor/", R_OK) "/home/brovko_rs/.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
Защита сервера
Немає коментарів:
Дописати коментар