Как да конфигурирате AppArmor за PostgreSQL и TimescaleDB

Сигурността е задължителна за всички системи, за да защитят вашите данни колкото е възможно повече. Дори когато винаги има риск от хакване, следването на контролен списък за сигурност ще намали значително този риск. Основният контролен списък за сигурност включва конфигурация на защитната стена, криптиране на данни, политика за удостоверяване и т.н. Друг важен инструмент за защита на вашите данни в Debian-базирани операционни системи е AppArmor. В този блог ще видим какво представлява и как да го конфигурираме за бази данни PostgreSQL и TimescaleDB.

Какво е AppArmor?

AppArmor, включен по подразбиране в операционните системи Ubuntu и Debian (наред с други), е система за задължителен контрол на достъпа (MAC) за ограничаване на програмите до ограничен набор от ресурси. Работи с помощта на профили, заредени в ядрото. Тези профили могат да бъдат конфигурирани в два режима:

Прилагане:Профилите, заредени в този режим, ще наложат правилата, дефинирани в профила, както и ще докладват за нарушение на правилата опити.
Оплакване:Профилите в този режим няма да налагат правила, а вместо това докладват за опити за нарушаване на правилата.

Освен това, AppArmor позволява смесването на профили за прилагане и режим на оплакване.

Как да конфигурирате AppArmor

Профилите на AppArmor са в /etc/apparmor.d/. Можете да създадете свои собствени профили и да ги преместите там или да проверите хранилището на AppArmor. Нека да видим как да създадем нов профил в AppArmor.

Първо, нека инсталираме необходимите пакети, за да се справим с това:

$ apt install apparmor-profiles apparmor-utils

И вижте дали AppArmor е активиран:

$ systemctl status apparmor.service

или

$ aa-status
apparmor module is loaded.
31 profiles are loaded.
29 profiles are in enforce mode.
   /snap/snapd/11588/usr/lib/snapd/snap-confine
   /snap/snapd/11588/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
  ...

Ако проверите споменатия път /etc/apparmor.d/, ще видите някои основни профили като usr.sbin.tcpdump или usr.sbin.traceroute. Сега нека създадем нов профил за PostgreSQL или TimescaleDB. За това можете да използвате този профил като пример. Въз основа на този профил ще заменим версията на PostgreSQL, за да бъдем по-конкретни. В този случай ще използваме PostgreSQL 13.

# Author: Felix Geyer <[email protected]>
#include <tunables/global>
/usr/lib/postgresql/13/bin/postgres {
  #include <abstractions/base>
  #include <abstractions/nameservice>
  #include <abstractions/ssl_keys>
  /etc/postgresql/** r,
  /usr/share/postgresql/** r,
  /var/lib/postgresql/** rwl,
  /{,var/}run/postgresql/** rw,
  owner @{PROC}/13/oom_adj rw,
}

Съхранете го в /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres. След това заредете новия профил, като използвате apparmor_parser -a:

$ cat /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres | sudo apparmor_parser -a

Ако искате да промените нещо в този профил, ще трябва да го презаредите:

$ apparmor_parser -r /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres

Можете да зададете режим на оплакване към профила, като използвате следната команда:

$ aa-complain /usr/lib/postgresql/13/bin/postgres

След това можете да проверите syslog файла в /var/log, за да видите дали конфигурацията на AppArmor е правилна или трябва да промените нещо. Когато е безопасно, можете да промените режима на Enforce, като изпълните:

$ aa-enforce /usr/lib/postgresql/13/bin/postgres

Можете да филтрирате дневника, търсейки РАЗРЕШЕНИ или ОТКАЗВАНИ действия:

Jun 25 19:48:02 ip-172-31-18-94 kernel: [ 5160.111028] audit: type=1400 audit(1624650482.537:103): apparmor="ALLOWED" operation="open" profile="/usr/lib/postgresql/13/bin/postgres" name="/proc/17405/oom_score_adj" pid=17405 comm="postgres" requested_mask="w" denied_mask="w" fsuid=113 ouid=113

Jun 25 19:48:02 ip-172-31-18-94 kernel: [ 5160.112524] audit: type=1400 audit(1624650482.541:104): apparmor="ALLOWED" operation="open" profile="/usr/lib/postgresql/13/bin/postgres" name="/proc/17404/oom_score_adj" pid=17404 comm="postgres" requested_mask="w" denied_mask="w" fsuid=113 ouid=113

Jun 25 19:50:02 ip-172-31-18-94 kernel: [ 5280.141262] audit: type=1400 audit(1624650602.569:112): apparmor="DENIED" operation="open" profile="/usr/lib/postgresql/13/bin/postgres" name="/proc/17518/oom_score_adj" pid=17518 comm="postgres" requested_mask="w" denied_mask="w" fsuid=113 ouid=113

Можете също да деактивирате профилите по този начин:

$ aa-disable /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres

И ще трябва да презаредите услугата:

$ systemctl reload apparmor.service

В случай, че предпочитате да деактивирате AppArmor, можете да изпълните:

$ systemctl stop apparmor
$ systemctl disable apparmor

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

Как да използвате PostgreSQL и TimescaleDB с ClusterControl и AppArmor

ClusterControl не управлява никакви модули за сигурност на ядрото на Linux като AppArmor. Когато разгръщате PostgreSQL или TimescaleDB клъстер с помощта на ClusterControl, можете да посочите дали искате ClusterControl да деактивира AppArmor вместо вас по време на процеса на внедряване, за да намали риска от грешки:

Ако не искате да го деактивирате, което се препоръчва за производство среди, можете да използвате режима на оплакване и да наблюдавате журнала във вашите сървъри, за да сте сигурни, че имате правилната конфигурация на AppArmor. След това можете да го промените на Enforce, като следвате инструкциите, споменати по-горе.

Можете да намерите повече информация за конфигурацията на AppArmor на официалния сайт на Ubuntu.