Правата в Linux отговарят на въпроса „кой може да прочете този файл“. AppArmor задава друг: „какво изобщо може да прави тази програма“. Разликата се проявява при пробив. Уеб обвивката се изпълнява с правата на потребителя на уеб сървъра и наследява всичките му права — тоест четене на добра половина от системата. Профилът на AppArmor ограничава процеса до списъка с това, което му е нужно за работа, а опитът да се прочете /etc/shadow или да се стартира /bin/bash завършва с отказ, независимо от правата на потребителя.

Какво вече е включено

sudo aa-status

Изходът отговаря на три въпроса: колко профила са заредени, колко от тях работят в режим enforce и complain и кои процеси работят изобщо без профил. В типичен Ubuntu профилите ще са няколко десетки, но почти всички за помощни програми от рода на man и tcpdump. Ключовите услуги — nginx, Apache, PHP-FPM — обикновено липсват в списъка на ограничените.

Три режима, които трябва да се различават:

  • enforce — правилата действат, всичко излишно е забранено;
  • complain — нарушенията само се записват, нищо не се блокира. Режим за настройка;
  • unconfined — профил няма, програмата работи без ограничения.

Най-полезната част от изхода на aa-status е последната: процесите, които слушат в мрежата и не са ограничени от нищо. Точно с този списък си струва да се започне.

Инструментите

sudo apt install apparmor-utils

Без този пакет командите aa-complain, aa-enforce и aa-logprof ги няма в системата, макар самият AppArmor да работи.

Как да включите профил и да не спрете услугата

Редът има принципно значение. Профил, включен веднага в enforce, с голяма вероятност ще забрани на услугата нещо нужно и тя ще спре да работи — обикновено не веднага, а при рядка операция като изпращане на файл или на поща.

Правилният ред:

sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

Седмица работа в този режим, включително всички нетипични сценарии: правене на резервно копие, обновяване, изпращане на големи файлове. После преглед на натрупаното:

sudo aa-logprof

Командата минава през записаните нарушения и при всяко пита дали да се разреши. Тук е нужно внимание: разрешавайте това, което наистина принадлежи на работата на услугата, а не всичко подред — иначе ще се получи профил, разрешаващ всичко, и смисълът ще изчезне.

И едва после:

sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

Къде се гледат отказите

Всички нарушения отиват в журнала на ядрото:

sudo journalctl -k | grep -i apparmor
sudo grep 'apparmor="DENIED"' /var/log/audit/audit.log

Вторият файл съществува, ако е инсталиран auditd — и тогава записите са значително по-богати. В записа за отказ се виждат името на профила, поисканата операция и пътят, до който се е посягало; това стига, за да се реши дали профилът да се поправи, или да се радвате, че е сработил.

Отделно запомнете симптома: услугата се държи странно — не чете конфигурацията, не пише в директория, не отваря сокет — а в собствените си журнали има грешка „отказан достъп“ при напълно правилни права. Това почти винаги е AppArmor и първото нещо е да се погледне в журнала на ядрото.

Практическа мярка, а не теоретична

Профил за PHP-FPM или nginx се изплаща по конкретен начин. При ограничен процес уеб обвивката, попаднала на сайта, не може нито да чете системни файлове, нито да стартира обвивка, нито да записва каквото и да било извън разрешените директории. Пробивът в сайта си остава пробив в сайта, вместо да се превърне в достъп до цялата машина — а точно този преход представлява съществената част от щетата.

Разумен ред на внедряване: първо профил за това, което гледа към интернет (уеб сървърът, PHP-FPM), после за базите данни, по-нататък според нуждите. Не е нужно всичко да се включва наведнъж, а универсален готов набор няма: профилът зависи от това къде лежат вашите файлове.

Какво да се проверява редовно

Профилите се връщат в неограничен режим по-често, отколкото изглежда: обновяване на пакет може да подмени файла на профила, ръчното отстраняване на проблем оставя услугата в complain, а нова услуга идва изобщо без профил. Полезни са две числа: колко профила са в enforce и колко мрежови процеса работят без ограничения. Промяната на което и да е от тях заслужава внимание. Как изглежда това, събрано на една страница, показва демонстрацията по-долу.