Förra veckan diskuterade vi hur man konfigurerar AppArmor för MongoDB Replica Sets som i princip har samma koncept som gäller när man konfigurerar detta för dina MySQL-baserade system. Säkerhet är verkligen mycket viktigt eftersom du måste se till att din data är mycket väl skyddad och inkapslad mot oönskad datainsamling av information från din affärsdomän.
Lite historik om AppArmor
AppArmor användes först i Immunix Linux 1998–2003. På den tiden var AppArmor känt som SubDomain, en referens till möjligheten för en säkerhetsprofil för ett specifikt program att segmenteras i olika domäner, som programmet kan växla mellan dynamiskt. AppArmor gjordes först tillgängligt i SLES och openSUSE, och aktiverades först som standard i SLES 10 och i openSUSE 10.1.
I maj 2005 förvärvade Novell Immunix och döpte om SubDomain till AppArmor och började kodrensning och omskrivning för inkludering i Linux-kärnan. Från 2005 till september 2007 upprätthölls AppArmor av Novell. Novell togs över av SUSE som nu är de juridiska ägarna av det varumärkesskyddade namnet AppArmor.
AppArmor portades/paketerades först framgångsrikt för Ubuntu i april 2007. AppArmor blev ett standardpaket med start i Ubuntu 7.10, och kom som en del av utgåvan av Ubuntu 8.04 och skyddade endast CUPS som standard. Från och med Ubuntu 9.04 har fler objekt som MySQL installerade profiler. AppArmor-härdningen fortsatte att förbättras i Ubuntu 9.10 eftersom den levereras med profiler för sin gästsession, virtuella libvirt-maskiner, Evince-dokumentvisaren och en valfri Firefox-profil.
Varför behöver vi AppArmor?
I vår tidigare blogg har vi tagit itu med lite av vad som är användningen av AppArmor. Det är ett obligatoriskt åtkomstkontrollsystem (MAC), implementerat på Linux Security Modules (LSM). Den används och är oftast aktiverad som standard i system som Ubuntu, Debian (sedan Buster), SUSE och andra distributioner. Det är jämförbart med RHEL/CentOS SELinux, vilket kräver bra integration av användarutrymmet för att fungera korrekt. SELinux fäster etiketter på alla filer, processer och objekt och är därför mycket flexibel. Men att konfigurera SELinux anses vara mycket komplicerat och kräver ett filsystem som stöds. AppArmor, å andra sidan, fungerar med hjälp av filsökvägar och dess konfiguration kan enkelt anpassas.
AppArmor, liksom de flesta andra LSM:er, kompletterar snarare än ersätter standarddiskretionär åtkomstkontroll (DAC). Som sådan är det omöjligt att ge en process fler privilegier än den hade från början.
AppArmor skyddar proaktivt operativsystemet och applikationerna från externa eller interna hot och till och med nolldagsattacker genom att upprätthålla en specifik regeluppsättning per applikation. Säkerhetspolicyer definierar helt vilka systemresurser enskilda applikationer kan komma åt och med vilka privilegier. Åtkomst nekas som standard om ingen profil säger något annat. Ett fåtal standardpolicyer ingår i AppArmor och med en kombination av avancerad statisk analys och inlärningsbaserade verktyg kan AppArmor-policyer för även mycket komplexa applikationer implementeras framgångsrikt på några timmar.
Varje policybrott utlöser ett meddelande i systemloggen, och AppArmor kan konfigureras för att meddela användare med varningar om överträdelse i realtid.
AppArmor för MySQL
Jag har konfigurerat ett MySQL-replikeringsbaserat kluster med ClusterControl till mina måldatabasnoder som körs i Ubuntu Bionic. Du kan följa den här bloggen om hur du distribuerar den eller följa den här videohandledningen. Observera att ClusterControl kontrollerar eller inaktiverar AppArmor under driftsättning. Du kanske måste avmarkera detta enligt dina inställningar precis som nedan:
ClusterControl kommer bara att utfärda en varning om att den inte rör din nuvarande AppArmor-konfiguration . Se nedan:
Hantera dina AppArmor-profiler
Standardinstallation av din AppArmor i Ubuntu skulle inte innehålla verktyg som skulle hjälpa till att hantera profilerna effektivt. Så låt oss installera dessa paket så här:
$ apt install apparmor-profiles apparmor-utilsNär den har installerats, kontrollera statusen för din AppArmor i systemet genom att köra aa-status-kommandot. I noden jag använder har jag följande utdata utan MySQL 8 installerat.
$ 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.Eftersom jag använder ClusterControl för att distribuera mitt MySQL-replikeringsbaserade kluster med AppArmor (dvs. ClusterControl kommer inte att röra min nuvarande AppArmor-konfiguration), ska implementeringen ha MySQL-profilen på plats och som visas i listan kör 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.
Det är värt att notera att en profil är i ett av följande lägen:
-
Enforce - Standardinställning. Applikationer förhindras från att vidta åtgärder som begränsas av profilreglerna.
-
Klaga – Applikationer tillåts vidta begränsade åtgärder och åtgärderna loggas.
-
Inaktiverad – applikationer tillåts vidta begränsade åtgärder och åtgärderna loggas inte.
Du kan också blanda upprätthållande och klagomålsprofiler på din server.
Baserat på resultatet ovan, låt oss utveckla mer om profilklagomålet. AppArmor kommer att tillåta den att utföra (nästan som status för klagomålsläge fortfarande kommer att upprätthålla alla explicita avslagsregler i en profil) alla uppgifter utan begränsningar men det kommer att logga dem i granskningsloggen som händelser. Detta är användbart när du försöker skapa en profil för en applikation men inte är säker på vilka saker den behöver åtkomst till. Medan den obegränsade statusen, å andra sidan, tillåter programmet att utföra vilken uppgift som helst och kommer inte att logga den. Detta inträffar vanligtvis om en profil laddades efter att en applikation har startat, vilket innebär att den körs utan begränsningar från AppArmor. Det är också viktigt att notera att endast processer som har profiler listas under denna obegränsade status. Alla andra processer som körs på ditt system men som inte har skapat en profil för dem kommer inte att listas under aa-status.
Om du har inaktiverat AppArmor men sedan inser att du ville förbättra din säkerhet eller följa säkerhetsföreskrifter, kan du använda den här MySQL 8.0-profilen som tillhandahålls av MySQL själv. För att tillämpa det, kör bara följande kommando:
$ cat /etc/apparmor.d/usr.sbin.mysqld | sudo apparmor_parser -aDet är värt att notera att AppArmor-profiler lagras som standard i /etc/apparmor.d/. Det är bra att lägga till dina profiler i den katalogen.
Diagnostisera dina AppArmor-profiler
AppArmor-loggar kan hittas i systemd-journalen, i /var/log/syslog och /var/log/kern.log (och /var/log/audit.log när auditd är installerad). Det du behöver leta efter är följande:
-
TILLÅT (loggas när en profil i klagoläge bryter mot policyn)
-
NEDAD (loggas när en profil i verkställande läge faktiskt blockerar en operation)
Det fullständiga loggmeddelandet bör ge mer information om exakt vilken åtkomst som nekats. Du kan använda detta för att redigera profiler innan du aktiverar dem i tillämpningsläge.
Till exempel
$ 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"Anpassa din AppArmor-profil
Profiler förberedda av Oracle MySQL ska inte vara ett mönster som passar alla. I så fall kan du välja att ändra, till exempel, datakatalogen där din MySQL-instansdata finns. När du har tillämpat ändringarna på din konfigurationsfil och startat om dina MySQL-instanser, kommer AppArmor att neka denna åtgärd. Till exempel,
$ 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=1002Tillsammans med felet jag hade tidigare, tillägger det nu att jag precis hade bestämt mig för att använda katalogen /mysql-data men det nekas.
Låt oss göra följande för att tillämpa ändringarna. Redigera filen /etc/apparmor.d/usr.sbin.mysqld. Du kan hitta dessa rader:
# 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
Mansidan förklarar dessa flaggor mer detaljerat.
Nu har jag ändrat det till följande:
# Allow data dir access
/mysql-data/ r,
/mysql-data/** rwk,Då laddar jag om profilerna enligt följande:
$ apparmor_parser -r -T /etc/apparmor.d/usr.sbin.mysqldStarta om MySQL-servern:
$ systemctl restart mysql.serviceVad händer om jag ställer in min mysqld på ett klagoläge?
Som nämnts tidigare kommer statusen för klagoläge fortfarande att upprätthålla alla explicita avslagsregler i en profil. Även om det här fungerar till exempel:
$ aa-complain /usr/sbin/mysqldStäller in /usr/sbin/mysqld till klagoläge.
Så,
$ 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.När du har startat om MySQL kommer den att köras och visar loggfiler som:
/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: 0I så fall ska användningen av enforce och ladda om din profil vara ett effektivt och enkelt sätt att hantera dina MySQL-profiler med AppArmor.