понеділок, 27 грудня 2010 р.

Правила 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
# способ 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
Защита сервера

Немає коментарів:

Дописати коментар

HyperComments for Blogger

comments powered by HyperComments