Как да конфигурирате AppArmor за системи, базирани на MySQL (MySQL/MariaDB репликация + Galera)

Миналата седмица обсъдихме как да конфигурираме AppArmor за MongoDB Replica Sets, който по същество има същите концепции, приложими при конфигурирането на това за вашите базирани на MySQL системи. Наистина сигурността е много важна, защото трябва да се уверите, че вашите данни са много добре защитени и капсулирани срещу нежелано събиране на данни на информация от вашия бизнес домейн.

Малко история за AppArmor

AppArmor е използван за първи път в Immunix Linux 1998–2003. По това време AppArmor беше известен като SubDomain, препратка към възможността за профил за сигурност за конкретна програма да бъде сегментиран в различни домейни, между които програмата може да превключва динамично. AppArmor за първи път беше достъпен в SLES и openSUSE и за първи път беше активиран по подразбиране в SLES 10 и в openSUSE 10.1.

През май 2005 г. Novell придоби Immunix и ребрандира SubDomain като AppArmor и започна почистване и пренаписване на код за включване в ядрото на Linux. От 2005 г. до септември 2007 г. AppArmor се поддържа от Novell. Novell беше поет от SUSE, които сега са законни собственици на запазеното име AppArmor.

AppArmor за първи път беше успешно пренесен/пакетиран за Ubuntu през април 2007 г. AppArmor стана пакет по подразбиране, започвайки от Ubuntu 7.10, и дойде като част от изданието на Ubuntu 8.04, защитавайки само CUPS по подразбиране. От Ubuntu 9.04 повече елементи като MySQL имат инсталирани профили. Втвърдяването на AppArmor продължи да се подобрява в Ubuntu 9.10, тъй като се доставя с профили за гост сесията, виртуални машини libvirt, инструмента за преглед на документи Evince и допълнителен профил за Firefox.

Защо имаме нужда от AppArmor?

В предишния ни блог се заехме малко с това какво е използването на AppArmor. Това е система за задължителен контрол на достъпа (MAC), внедрена върху модулите за сигурност на Linux (LSM). Използва се и се активира предимно по подразбиране в системи като Ubuntu, Debian (от Buster), SUSE и други дистрибуции. Той е сравним с RHEL/CentOS SELinux, който изисква добра интеграция на потребителското пространство, за да работи правилно. SELinux прикрепя етикети към всички файлове, процеси и обекти и следователно е много гъвкав. Въпреки това, конфигурирането на SELinux се счита за много сложно и изисква поддържана файлова система. AppArmor, от друга страна, работи с файлови пътища и конфигурацията му може лесно да се адаптира.

AppArmor, подобно на повечето други LSM, допълва, а не замества дискреционния контрол на достъпа по подразбиране (DAC). Като такъв е невъзможно да се предоставят на процес повече привилегии, отколкото е имал на първо място.

AppArmor проактивно защитава операционната система и приложенията от външни или вътрешни заплахи и дори атаки с нулев ден, като налага специфичен набор от правила за всяко приложение. Политиките за сигурност напълно определят до какви системни ресурси имат достъп отделните приложения и с какви привилегии. Достъпът е отказан по подразбиране, ако нито един профил не казва друго. Няколко правила по подразбиране са включени в AppArmor и с помощта на комбинация от усъвършенстван статичен анализ и базирани на обучение инструменти, правилата на AppArmor дори за много сложни приложения могат да бъдат внедрени успешно за броени часове.

Всяко нарушение на правилата задейства съобщение в системния регистър и AppArmor може да бъде конфигуриран да уведомява потребителите с предупреждения за нарушения в реално време.

AppArmor за MySQL

Настроих клъстер, базиран на MySQL репликация, използвайки ClusterControl към моята целева база данни, работещи в Ubuntu Bionic. Можете допълнително да следвате този блог за това как да го внедрите или да следвате този видеоурок. Обърнете внимание, че ClusterControl проверява или деактивира AppArmor по време на внедряването. Може да се наложи да премахнете отметката от това според настройките си, както по-долу:

ClusterControl просто ще издаде предупреждение, че не докосва текущата ви конфигурация на AppArmor . Вижте по-долу:

Управление на вашите AppArmor профили

Стандартната инсталация на вашия AppArmor в Ubuntu няма да включва помощни програми, които биха помогнали за ефективно управление на профилите. Така че нека инсталираме тези пакети така:

$ apt install apparmor-profiles apparmor-utils

След като бъде инсталиран, проверете състоянието на вашия AppArmor в системата, като изпълните командата aa-status. В възела, който използвам, имам следния изход без инсталиран MySQL 8.

$ aa-status

apparmor module is loaded.

15 profiles are loaded.

15 profiles are in enforce mode.

   /sbin/dhclient

   /usr/bin/lxc-start

   /usr/bin/man

   /usr/lib/NetworkManager/nm-dhcp-client.action

   /usr/lib/NetworkManager/nm-dhcp-helper

   /usr/lib/connman/scripts/dhclient-script

   /usr/lib/snapd/snap-confine

   /usr/lib/snapd/snap-confine//mount-namespace-capture-helper

   /usr/sbin/tcpdump

   lxc-container-default

   lxc-container-default-cgns

   lxc-container-default-with-mounting

   lxc-container-default-with-nesting

   man_filter

   man_groff

0 profiles are in complain mode.

0 processes have profiles defined.

0 processes are in enforce mode.

0 processes are in complain mode.

0 processes are unconfined but have a profile defined.

Тъй като използвам ClusterControl за разгръщане на моя базиран на MySQL клъстер с AppArmor (т.е. ClusterControl няма да докосва текущата ми конфигурация на AppArmor), внедряването ще има MySQL профил на място и това се показва в списъкът с aa-status.

$ aa-status

apparmor module is loaded.

56 profiles are loaded.

19 profiles are in enforce mode.

   ...

   /usr/sbin/mysqld

   ...

37 profiles are in complain mode.

   ...

1 processes have profiles defined.

1 processes are in enforce mode.

   /usr/sbin/mysqld (31501)

0 processes are in complain mode.

0 processes are unconfined but have a profile defined.

Заслужава да се отбележи, че профилът е в един от следните режими:

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

• Оплакване – На приложенията е разрешено да предприемат ограничени действия и действията се записват.

• Деактивирано – на приложенията е разрешено да извършват ограничени действия и действията не се записват.

Можете също да смесвате профили за налагане и оплаквания във вашия сървър.

Въз основа на изхода по-горе,  нека разгледаме по-подробно оплакването от потребителския профил. AppArmor ще му позволи да изпълнява (почти тъй като състоянието на режим на оплакване ще продължи да налага всички изрични правила за отказ в профила) всички задачи без ограничения, но ще ги регистрира в регистрационния файл за одит като събития. Това е полезно, когато се опитвате да създадете профил за приложение, но не сте сигурни до какви неща има нужда от достъп. Докато неограниченият статус, от друга страна, ще позволи на програмата да изпълнява всяка задача и няма да я регистрира. Това обикновено се случва, ако профилът е зареден след стартиране на приложение, което означава, че работи без ограничения от AppArmor. Също така е важно да се отбележи, че само процеси, които имат профили, са изброени под този неограничен статус. Всички други процеси, които се изпълняват във вашата система, но нямат създаден профил за тях, няма да бъдат изброени под aa-status.

Ако сте деактивирали AppArmor, но след това осъзнаете, че искате да подобрите сигурността си или да спазвате разпоредбите за сигурност, можете да използвате този MySQL 8.0 профил, който се предоставя от самия MySQL. За да приложите това, просто изпълнете следната команда:

$ cat /etc/apparmor.d/usr.sbin.mysqld | sudo apparmor_parser -a

Заслужава да се отбележи, че профилите на AppArmor се съхраняват по подразбиране в /etc/apparmor.d/. Добра практика е да добавите профилите си в тази директория.

Диагностика на вашите AppArmor профили

Журналите на AppArmor могат да бъдат намерени в дневника на systemd, в /var/log/syslog и /var/log/kern.log (и /var/log/audit.log, когато auditd е инсталиран). Това, което трябва да търсите, е следното:

• ДОПУСКА (влиза, когато профил в режим на оплакване нарушава правилата)

• ОТКАЗЕН (вписан, когато профил в режим на прилагане действително блокира операция)

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

Например,

$ grep -i -rn -E 'apparmor=.*denied|apparmor=.*allowed' /var/log/

/var/log/kern.log:503:Jun 18 18:54:09 ubuntu-bionic kernel: [  664.680141] audit: type=1400 audit(1624042449.006:19): apparmor="DENIED" operation="capable" profile="/usr/sbin/mysqld" pid=30349 comm="mysqld" capability=2  capname="dac_read_search"

Binary file /var/log/journal/877861ee473c4c03ac1512ed369dead1/system.journal matches

/var/log/syslog:1012:Jun 18 18:54:09 ubuntu-bionic kernel: [  664.680141] audit: type=1400 audit(1624042449.006:19): apparmor="DENIED" operation="capable" profile="/usr/sbin/mysqld" pid=30349 comm="mysqld" capability=2  capname="dac_read_search"

Персонализиране на вашия AppArmor профил

Профилите, изготвени от Oracle MySQL, не трябва да са универсален модел. В този случай може да решите да промените например директорията с данни, където се намират данните на вашия MySQL екземпляр. След като приложите промените към вашия конфигурационен файл и рестартирате вашите MySQL екземпляри, AppArmor ще откаже това действие. Например,

$ egrep -i -rn 'apparmor=.*denied|apparmor=.*allowed' /var/log/

/var/log/kern.log:503:Jun 18 18:54:09 ubuntu-bionic kernel: [  664.680141] audit: type=1400 audit(1624042449.006:19): apparmor="DENIED" operation="capable" profile="/usr/sbin/mysqld" pid=30349 comm="mysqld" capability=2  capname="dac_read_search"

/var/log/kern.log:522:Jun 18 19:46:26 ubuntu-bionic kernel: [ 3801.151770] audit: type=1400 audit(1624045586.822:67): apparmor="DENIED" operation="mknod" profile="/usr/sbin/mysqld" name="/mysql-data/mysql.sock.lock" pid=5262 comm="mysqld" requested_mask="c" denied_mask="c" fsuid=1002 ouid=1002

Binary file /var/log/journal/877861ee473c4c03ac1512ed369dead1/system.journal matches

/var/log/syslog:1012:Jun 18 18:54:09 ubuntu-bionic kernel: [  664.680141] audit: type=1400 audit(1624042449.006:19): apparmor="DENIED" operation="capable" profile="/usr/sbin/mysqld" pid=30349 comm="mysqld" capability=2  capname="dac_read_search"

/var/log/syslog:1313:Jun 18 19:46:26 ubuntu-bionic kernel: [ 3801.151770] audit: type=1400 audit(1624045586.822:67): apparmor="DENIED" operation="mknod" profile="/usr/sbin/mysqld" name="/mysql-data/mysql.sock.lock" pid=5262 comm="mysqld" requested_mask="c" denied_mask="c" fsuid=1002 ouid=1002

Заедно с грешката, която имах по-рано, сега добавя, че току-що съм решил да използвам директорията /mysql-data, но това е отказано.

За да приложите промените, нека направим следното. Редактирайте файла /etc/apparmor.d/usr.sbin.mysqld. Може да намерите тези редове:

# Allow data dir access

  /var/lib/mysql/ r,

  /var/lib/mysql/** rwk,

Those flags such as r, rwk are the so-called access modes. These mean the following:

       r       - read

       w       - write -- conflicts with append

       k       - lock

Частната страница обяснява тези флагове по-подробно.

Сега го промених на следното:

# Allow data dir access

  /mysql-data/ r,

  /mysql-data/** rwk,

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

$ apparmor_parser -r -T /etc/apparmor.d/usr.sbin.mysqld

Рестартирайте MySQL сървъра:

$ systemctl restart mysql.service

Ами ако настроя mysqld в режим на оплакване?

Както беше споменато по-рано, състоянието на режима на оплакване все пак ще налага всички изрични правила за отказ в потребителския профил. Въпреки че това работи например:

$ aa-complain /usr/sbin/mysqld

Настройване на /usr/sbin/mysqld в режим на оплакване.

След това,

$ aa-status

apparmor module is loaded.

56 profiles are loaded.

18 profiles are in enforce mode.

   ...

38 profiles are in complain mode.

   ...

1 processes have profiles defined.

0 processes are in enforce mode.

1 processes are in complain mode.

   /usr/sbin/mysqld (23477)

0 processes are unconfined but have a profile defined.

След като рестартирате MySQL, той ще се стартира и ще показва регистрационни файлове като:

/var/log/syslog:1356:Jun 18 19:58:51 ubuntu-bionic kernel: [ 4545.427074] audit: type=1400 audit(1624046331.098:83): apparmor="ALLOWED" operation="open" profile="/usr/sbin/mysqld" name="/mysql-data/mysql.sock.lock" pid=5760 comm="mysqld" requested_mask="wrc" denied_mask="wrc" fsuid=1002 ouid=1002

/var/log/syslog:1357:Jun 18 19:58:51 ubuntu-bionic kernel: [ 4545.432077] audit: type=1400 audit(1624046331.102:84): apparmor="ALLOWED" operation="mknod" profile="/usr/sbin/mysqld" name="/mysql-data/mysql.sock" pid=5760 comm="mysqld" requested_mask="c" denied_mask="c" fsuid=1002 ouid=1002

/var/log/syslog:1358:Jun 18 19:58:51 ubuntu-bionic kernel: [ 4545.432101] audit: type=1400 audit(1624046331.102:85): apparmor="ALLOWED" operation="mknod" profile="/usr/sbin/mysqld" name="/mysql-data/mysql.pid" pid=5760 comm="mysqld" requested_mask="c" denied_mask="c" fsuid=1002 ouid=1002

And it will work. However, it will probably have issues with networking as it still denies entries as what we have in /etc/apparmor.d/usr.sbin.mysqld. For example, my replica is not able to connect to the primary:

                Last_IO_Error: error connecting to master '[email protected]:3306' - retry-time: 10 retries: 1 message: Host '192.168.40.247' is not allowed to connect to this MySQL server

               Last_SQL_Errno: 0

В този случай използването на принудително и презареждане на вашия профил ще бъде ефективен и лесен подход за управление на вашите MySQL профили с AppArmor.