Minulý týden jsme diskutovali o tom, jak nakonfigurovat AppArmor pro sady replik MongoDB, které mají v zásadě stejné koncepty, které lze použít při konfiguraci pro vaše systémy založené na MySQL. Zabezpečení je skutečně velmi důležité, protože se musíte ujistit, že vaše data jsou velmi dobře chráněna a zapouzdřena proti nežádoucímu shromažďování dat z vaší obchodní domény.
Něco z historie o AppArmor
AppArmor byl poprvé použit v Immunix Linuxu v letech 1998–2003. V té době byl AppArmor známý jako SubDomain, odkaz na možnost segmentovat bezpečnostní profil pro konkrétní program do různých domén, mezi kterými může program dynamicky přepínat. AppArmor byl poprvé zpřístupněn v SLES a openSUSE a poprvé byl standardně povolen v SLES 10 a v openSUSE 10.1.
V květnu 2005 Novell získal Immunix a přejmenoval SubDomain na AppArmor a začal s čištěním a přepisováním kódu pro zahrnutí do linuxového jádra. Od roku 2005 do září 2007 byl AppArmor spravován společností Novell. Novell byl převzat společností SUSE, která je nyní zákonnými vlastníky názvu AppArmor s ochrannou známkou.
AppArmor byl poprvé úspěšně portován/zabalen pro Ubuntu v dubnu 2007. AppArmor se stal výchozím balíčkem počínaje Ubuntu 7.10 a přišel jako součást vydání Ubuntu 8.04, ve výchozím nastavení chrání pouze CUPS. Od Ubuntu 9.04 má nainstalované profily více položek, jako je MySQL. Upevňování AppArmor se v Ubuntu 9.10 nadále zlepšovalo, protože je dodáváno s profily pro relaci hosta, virtuálními stroji libvirt, prohlížečem dokumentů Evince a volitelným profilem Firefoxu.
Proč potřebujeme AppArmor?
V našem předchozím blogu jsme se trochu zabývali tím, jak se AppArmor používá. Jedná se o systém povinného řízení přístupu (MAC), implementovaný na Linux Security Modules (LSM). Používá se a většinou je standardně povolen v systémech jako Ubuntu, Debian (od Buster), SUSE a dalších distribucích. Je srovnatelný s RHEL/CentOS SELinux, který ke správnému fungování vyžaduje dobrou integraci uživatelského prostoru. SELinux připojuje štítky ke všem souborům, procesům a objektům a je proto velmi flexibilní. Konfigurace SELinuxu je však považována za velmi komplikovanou a vyžaduje podporovaný souborový systém. AppArmor na druhou stranu funguje pomocí cest k souborům a jeho konfiguraci lze snadno přizpůsobit.
AppArmor, stejně jako většina ostatních LSM, spíše doplňuje, než nahrazuje výchozí Discretionary Access Control (DAC). Proto je nemožné udělit procesu více privilegií, než měl původně.
AppArmor proaktivně chrání operační systém a aplikace před vnějšími nebo interními hrozbami a dokonce i před útoky zero-day tím, že vynucuje specifická pravidla nastavená pro jednotlivé aplikace. Bezpečnostní zásady zcela definují, k jakým systémovým prostředkům mohou jednotlivé aplikace přistupovat as jakými oprávněními. Pokud žádný profil neříká jinak, je přístup ve výchozím nastavení odepřen. AppArmor obsahuje několik výchozích zásad a pomocí kombinace pokročilé statické analýzy a nástrojů založených na učení lze zásady AppArmor pro i velmi složité aplikace úspěšně nasadit během několika hodin.
Každé porušení zásad spustí zprávu v systémovém protokolu a AppArmor lze nakonfigurovat tak, aby uživatele upozorňoval na porušení zásad v reálném čase.
AppArmor pro MySQL
Nastavil jsem cluster založený na replikaci MySQL pomocí ClusterControl pro mé cílové databázové uzly běžící v Ubuntu Bionic. Můžete dále sledovat tento blog o tom, jak jej nasadit, nebo se řídit tímto videonávodem. Pamatujte, že ClusterControl kontroluje nebo deaktivuje AppArmor během nasazení. Možná budete muset zrušit zaškrtnutí podle vašeho nastavení, jak je uvedeno níže:
ClusterControl pouze vydá varování, že se nedotýká vaší aktuální konfigurace AppArmor . Viz níže:
Správa vašich profilů AppArmor
Standardní instalace vašeho AppArmor v Ubuntu by nezahrnovala nástroje, které by pomohly efektivně spravovat profily. Nainstalujme tedy tyto balíčky takto:
$ apt install apparmor-profiles apparmor-utilsPo instalaci zkontrolujte stav vašeho AppArmor v systému spuštěním příkazu aa-status. V uzlu, který používám, mám následující výstup bez nainstalovaného 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.Protože používám ClusterControl k nasazení mého clusteru založeného na replikaci MySQL s AppArmor (tj. ClusterControl se nedotkne mé aktuální konfigurace AppArmor), nasazení musí mít profil MySQL a ten se zobrazí v seznam běží 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.
Za zmínku stojí, že profil je v jednom z následujících režimů:
-
Vynutit – výchozí nastavení. Aplikace nemohou provádět akce omezené pravidly profilu.
-
Stížnost – Aplikace mohou provádět omezené akce a akce jsou protokolovány.
-
Zakázáno – Aplikace mohou provádět omezené akce a akce nejsou protokolovány.
Můžete také kombinovat profily pro vynucení a stížnosti na svém serveru.
Na základě výše uvedeného výstupu se podrobněji rozvedeme o stížnosti na profil. AppArmor mu umožní provádět (téměř jako stav režimu stížnosti bude stále vynucovat jakákoli explicitní pravidla odmítnutí v profilu) všechny úkoly bez omezení, ale bude je zaznamenávat do protokolu auditu jako události. To je užitečné, když se pokoušíte vytvořit profil pro aplikaci, ale nejste si jisti, k jakým věcem potřebuje přístup. Zatímco neomezený stav na druhé straně umožní programu provést jakýkoli úkol a nebude jej protokolovat. K tomu obvykle dochází, pokud byl profil načten po spuštění aplikace, což znamená, že běží bez omezení z AppArmor. Je také důležité poznamenat, že v tomto neomezeném stavu jsou uvedeny pouze procesy, které mají profily. Jakékoli další procesy, které běží na vašem systému, ale nemají pro ně vytvořený profil, nebudou uvedeny pod aa-status.
Pokud jste deaktivovali AppArmor, ale pak jste si uvědomili, že chcete zvýšit své zabezpečení nebo splnit bezpečnostní předpisy, můžete použít tento profil MySQL 8.0, který poskytuje samotná MySQL. Chcete-li to použít, spusťte následující příkaz:
$ cat /etc/apparmor.d/usr.sbin.mysqld | sudo apparmor_parser -aZa zmínku stojí, že profily AppArmor jsou standardně uloženy v /etc/apparmor.d/. Je dobrým zvykem přidat své profily do tohoto adresáře.
Diagnostika vašich profilů AppArmor
Protokoly AppArmor lze nalézt v deníku systemd, v /var/log/syslog a /var/log/kern.log (a /var/log/audit.log, když je nainstalován auditd). Musíte hledat následující:
-
POVOLENO (přihlášeno, když profil v režimu stížností porušuje zásady)
-
DENIED (zaprotokolováno, když profil v režimu vynucení skutečně blokuje operaci)
Úplná zpráva protokolu by měla obsahovat více informací o tom, jaký konkrétní přístup byl odepřen. Toto můžete použít k úpravě profilů před jejich zapnutím v režimu vynucení.
Například
$ 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"Přizpůsobení profilu AppArmor
Profily připravené Oracle MySQL nesmí být univerzálním vzorem. V takovém případě se můžete rozhodnout změnit například datový adresář, kde se nacházejí vaše data instance MySQL. Poté, co použijete změny ve vašem konfiguračním souboru a restartujete své instance MySQL, AppArmor tuto akci odmítne. Například,
$ 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=1002Spolu s chybou, kterou jsem měl dříve, nyní dodává, že jsem se právě rozhodl použít adresář /mysql-data, ale to je zamítnuto.
Chcete-li změny použít, proveďte následující. Upravte soubor /etc/apparmor.d/usr.sbin.mysqld. Můžete najít tyto řádky:
# 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
Manuálová stránka vysvětluje tyto příznaky podrobněji.
Nyní jsem to změnil na následující:
# Allow data dir access
/mysql-data/ r,
/mysql-data/** rwk,Potom znovu načtu profily následovně:
$ apparmor_parser -r -T /etc/apparmor.d/usr.sbin.mysqldRestartujte server MySQL:
$ systemctl restart mysql.serviceCo když nastavím svůj mysqld do režimu stížnosti?
Jak již bylo zmíněno dříve, stav režimu stížností bude i nadále uplatňovat veškerá explicitní pravidla odepření v profilu. I když to funguje například:
$ aa-complain /usr/sbin/mysqldNastavení /usr/sbin/mysqld na režim stížnosti.
Potom
$ 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.Po restartování MySQL se spustí a zobrazí soubory protokolu, jako například:
/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: 0V takovém případě bude použití vynucení a opětovného načtení vašeho profilu efektivním a snadným přístupem ke správě vašich MySQL profilů pomocí AppArmor.