I sidste uge diskuterede vi, hvordan man konfigurerer AppArmor til MongoDB Replica Sets, som grundlæggende har de samme koncepter, der gælder, når man konfigurerer dette til dine MySQL-baserede systemer. Sikkerhed er faktisk meget vigtig, fordi du skal sørge for, at dine data er meget godt beskyttet og indkapslet mod uønsket dataindsamling af information fra dit forretningsdomæne.
En lille smule historie om AppArmor
AppArmor blev første gang brugt i Immunix Linux 1998–2003. På det tidspunkt var AppArmor kendt som SubDomain, en reference til muligheden for, at en sikkerhedsprofil for et specifikt program kan segmenteres i forskellige domæner, som programmet kan skifte mellem dynamisk. AppArmor blev først gjort tilgængelig i SLES og openSUSE og blev først aktiveret som standard i SLES 10 og i openSUSE 10.1.
I maj 2005 erhvervede Novell Immunix og omdøbte SubDomain til AppArmor og begyndte at rense og omskrive kode til inkludering i Linux-kernen. Fra 2005 til september 2007 blev AppArmor vedligeholdt af Novell. Novell blev overtaget af SUSE, som nu er de juridiske ejere af det varemærkebeskyttede navn AppArmor.
AppArmor blev først porteret/pakket til Ubuntu i april 2007. AppArmor blev en standardpakke, der startede i Ubuntu 7.10, og kom som en del af udgivelsen af Ubuntu 8.04, der kun beskyttede CUPS som standard. Fra og med Ubuntu 9.04 har flere elementer såsom MySQL installerede profiler. AppArmor-hærdning fortsatte med at forbedres i Ubuntu 9.10, da den leveres med profiler til gæstesessionen, virtuelle libvirt-maskiner, Evince-dokumentfremviseren og en valgfri Firefox-profil.
Hvorfor har vi brug for AppArmor?
I vores tidligere blog har vi behandlet lidt af, hvad der er brugen af AppArmor. Det er et obligatorisk adgangskontrolsystem (MAC), implementeret på Linux Security Modules (LSM). Det bruges og er for det meste aktiveret som standard i systemer som Ubuntu, Debian (siden Buster), SUSE og andre distributioner. Det kan sammenlignes med RHEL/CentOS SELinux, som kræver god brugerrumsintegration for at fungere korrekt. SELinux sætter etiketter på alle filer, processer og objekter og er derfor meget fleksibel. Konfiguration af SELinux anses dog for at være meget kompliceret og kræver et understøttet filsystem. AppArmor, på den anden side, fungerer ved hjælp af filstier, og dens konfiguration kan nemt tilpasses.
AppArmor, ligesom de fleste andre LSM'er, supplerer snarere end erstatter standarden Discretionary Access Control (DAC). Som sådan er det umuligt at give en proces flere privilegier, end den havde i første omgang.
AppArmor beskytter proaktivt operativsystemet og applikationerne mod eksterne eller interne trusler og endda zero-day angreb ved at håndhæve et specifikt regelsæt pr. applikation. Sikkerhedspolitikker definerer fuldstændigt, hvilke systemressourcer individuelle applikationer kan få adgang til, og med hvilke privilegier. Adgang nægtes som standard, hvis ingen profil siger andet. Nogle få standardpolitikker er inkluderet i AppArmor, og ved hjælp af en kombination af avanceret statisk analyse og læringsbaserede værktøjer kan AppArmor-politikker til selv meget komplekse applikationer implementeres med succes på få timer.
Hvert brud på politik udløser en meddelelse i systemloggen, og AppArmor kan konfigureres til at underrette brugere med advarsler om overtrædelse i realtid.
AppArmor til MySQL
Jeg har opsat en MySQL-replikeringsbaseret klynge ved hjælp af ClusterControl til mine måldatabasenoder, der kører i Ubuntu Bionic. Du kan yderligere følge denne blog om, hvordan du implementerer den, eller følge denne videovejledning. Bemærk, at ClusterControl kontrollerer eller deaktiverer AppArmor under implementeringen. Du skal muligvis fjerne markeringen af dette i henhold til din opsætning ligesom nedenfor:
ClusterControl vil bare udsende en advarsel om, at den ikke rører din nuværende AppArmor-konfiguration . Se nedenfor:
Administration af dine AppArmor-profiler
Standardinstallation af din AppArmor i Ubuntu ville ikke inkludere hjælpeprogrammer, der ville hjælpe med at administrere profilerne effektivt. Så lad os installere disse pakker som sådan:
$ apt install apparmor-profiles apparmor-utilsNår den er installeret, skal du kontrollere status for din AppArmor i systemet ved at køre aa-status kommando. I den node, jeg bruger, har jeg følgende output uden MySQL 8 installeret.
$ 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.Da jeg bruger ClusterControl til at implementere min MySQL-replikeringsbaserede klynge med AppArmor (dvs. ClusterControl vil ikke røre min nuværende AppArmor-konfiguration), skal implementeringen have MySQL-profilen på plads, og den vises i listen kører 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 er værd at bemærke, at en profil er i en af følgende tilstande:
-
Enforce - Standardindstilling. Applikationer er forhindret i at udføre handlinger, der er begrænset af profilreglerne.
-
Klag - Programmer har lov til at udføre begrænsede handlinger, og handlingerne logges.
-
Deaktiveret - Programmer har lov til at udføre begrænsede handlinger, og handlingerne logges ikke.
Du kan også blande håndhævelses- og klageprofiler på din server.
Baseret på outputtet ovenfor, lad os uddybe mere om profilklagen. AppArmor vil tillade den at udføre (næsten da status for klagetilstand stadig vil håndhæve eksplicitte afvisningsregler i en profil) alle opgaver uden begrænsninger, men den vil logge dem i revisionsloggen som hændelser. Dette er nyttigt, når du forsøger at oprette en profil til en applikation, men ikke er sikker på, hvilke ting den skal have adgang til. Mens den ubegrænsede status på den anden side vil tillade programmet at udføre enhver opgave og ikke logger den. Dette sker normalt, hvis en profil blev indlæst, efter at en applikation er startet, hvilket betyder, at den kører uden begrænsninger fra AppArmor. Det er også vigtigt at bemærke, at kun processer, der har profiler, er opført under denne ubegrænsede status. Eventuelle andre processer, der kører på dit system, men som ikke har en profil oprettet til dem, vil ikke blive opført under aa-status.
Hvis du har deaktiveret AppArmor, men derefter indser, at du ønskede at forbedre din sikkerhed eller overholde sikkerhedsbestemmelserne, kan du bruge denne MySQL 8.0-profil, der leveres af MySQL selv. For at anvende det skal du bare køre følgende kommando:
$ cat /etc/apparmor.d/usr.sbin.mysqld | sudo apparmor_parser -aDet er værd at bemærke, at AppArmor-profiler gemmes som standard i /etc/apparmor.d/. Det er en god praksis at tilføje dine profiler i den mappe.
Diagnosticering af dine AppArmor-profiler
AppArmor-logfiler kan findes i systemd-journalen i /var/log/syslog og /var/log/kern.log (og /var/log/audit.log når auditd er installeret). Det du skal kigge efter er følgende:
-
TILLADT (logges, når en profil i klagetilstand overtræder politikken)
-
AFVISET (logges, når en profil i håndhævelsestilstand faktisk blokerer en handling)
Den fulde logmeddelelse skulle give flere oplysninger om, hvilken nøjagtig adgang der er blevet nægtet. Du kan bruge dette til at redigere profiler, før du slår dem til i håndhævelsestilstand.
For eksempel
$ 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"Tilpasning af din AppArmor-profil
Profiler udarbejdet af Oracle MySQL må ikke være et mønster, der passer til alle. I så fald kan du beslutte dig for at ændre f.eks. databiblioteket, hvor dine MySQL-instansdata er placeret. Når du har anvendt ændringerne på din konfigurationsfil og genstartet dine MySQL-forekomster, vil AppArmor afvise denne handling. For eksempel
$ 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=1002Sammen med den fejl, jeg havde tidligere, tilføjer den nu, at jeg lige havde besluttet at bruge mappen /mysql-data, men det er afvist.
For at anvende ændringerne, lad os gøre følgende. Rediger filen /etc/apparmor.d/usr.sbin.mysqld. Du kan muligvis finde disse linjer:
# 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
Man-siden forklarer disse flag mere detaljeret.
Nu har jeg ændret det til følgende:
# Allow data dir access
/mysql-data/ r,
/mysql-data/** rwk,Så genindlæser jeg profilerne som følger:
$ apparmor_parser -r -T /etc/apparmor.d/usr.sbin.mysqldGenstart MySQL-serveren:
$ systemctl restart mysql.serviceHvad hvis jeg indstiller min mysqld til en klagetilstand?
Som tidligere nævnt vil status for klagetilstand stadig håndhæve eksplicitte afvisningsregler i en profil. Selvom dette virker for eksempel:
$ aa-complain /usr/sbin/mysqldIndstilling af /usr/sbin/mysqld til klagetilstand.
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.Efter du har genstartet MySQL, vil den køre og vise logfiler så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å fald vil brugen af håndhævelse og genindlæsning af din profil være en effektiv og nem tilgang til at administrere dine MySQL-profiler med AppArmor.