Vorige week hebben we besproken hoe u AppArmor voor MongoDB-replicasets configureert, die in principe dezelfde concepten hebben die van toepassing zijn bij het configureren voor uw MySQL-gebaseerde systemen. Beveiliging is inderdaad erg belangrijk omdat u ervoor moet zorgen dat uw gegevens zeer goed worden beschermd en ingekapseld tegen ongewenste gegevensverzameling van informatie uit uw bedrijfsdomein.
Een klein beetje geschiedenis over AppArmor
AppArmor werd voor het eerst gebruikt in Immunix Linux 1998-2003. Destijds stond AppArmor bekend als SubDomain, een verwijzing naar de mogelijkheid om een beveiligingsprofiel voor een specifiek programma te segmenteren in verschillende domeinen, waartussen het programma dynamisch kan schakelen. AppArmor werd voor het eerst beschikbaar gemaakt in SLES en openSUSE en werd voor het eerst standaard ingeschakeld in SLES 10 en in openSUSE 10.1.
In mei 2005 verwierf Novell Immunix en veranderde het SubDomain in AppArmor en begon met het opschonen en herschrijven van de code voor opname in de Linux-kernel. Van 2005 tot september 2007 werd AppArmor onderhouden door Novell. Novell werd overgenomen door SUSE, die nu de wettelijke eigenaars zijn van de handelsmerknaam AppArmor.
AppArmor werd voor het eerst met succes geporteerd/verpakt voor Ubuntu in april 2007. AppArmor werd een standaardpakket vanaf Ubuntu 7.10 en kwam als onderdeel van de release van Ubuntu 8.04, waarbij standaard alleen CUPS werd beschermd. Vanaf Ubuntu 9.04 hebben meer items zoals MySQL profielen geïnstalleerd. De verharding van AppArmor bleef verbeteren in Ubuntu 9.10 omdat het wordt geleverd met profielen voor zijn gastsessie, virtuele libvirt-machines, de Evince-documentviewer en een optioneel Firefox-profiel.
Waarom hebben we AppArmor nodig?
In onze vorige blog hebben we het over het gebruik van AppArmor gehad. Het is een Mandatory Access Control (MAC) systeem, geïmplementeerd op de Linux Security Modules (LSM). Het wordt gebruikt en meestal standaard ingeschakeld in systemen zoals Ubuntu, Debian (sinds Buster), SUSE en andere distributies. Het is vergelijkbaar met RHEL/CentOS SELinux, dat een goede gebruikersruimte-integratie vereist om goed te kunnen werken. SELinux hecht labels aan alle bestanden, processen en objecten en is daarom erg flexibel. Het configureren van SELinux wordt echter als zeer gecompliceerd beschouwd en vereist een ondersteund bestandssysteem. AppArmor daarentegen werkt met bestandspaden en de configuratie kan eenvoudig worden aangepast.
AppArmor is, net als de meeste andere LSM's, een aanvulling op de standaard Discretionary Access Control (DAC) in plaats van deze te vervangen. Als zodanig is het onmogelijk om een proces meer privileges te geven dan het in de eerste plaats had.
AppArmor beschermt het besturingssysteem en de applicaties proactief tegen externe of interne bedreigingen en zelfs zero-day-aanvallen door het afdwingen van een specifieke regelset per applicatie. Beveiligingsbeleid bepaalt volledig tot welke systeembronnen individuele toepassingen toegang hebben en met welke privileges. De toegang wordt standaard geweigerd als geen enkel profiel anders aangeeft. AppArmor bevat een aantal standaardbeleidsregels en met behulp van een combinatie van geavanceerde statische analyse en op leren gebaseerde tools, kan AppArmor-beleid voor zelfs zeer complexe toepassingen binnen enkele uren met succes worden geïmplementeerd.
Elke schending van het beleid activeert een bericht in het systeemlogboek en AppArmor kan worden geconfigureerd om gebruikers op de hoogte te stellen met realtime waarschuwingen voor schending.
AppArmor voor MySQL
Ik heb een op MySQL-replicatie gebaseerd cluster met ClusterControl ingesteld op mijn doeldatabaseknooppunten die in Ubuntu Bionic worden uitgevoerd. U kunt verder deze blog volgen over hoe u het moet implementeren of deze videozelfstudie volgen. Houd er rekening mee dat ClusterControl de AppArmor tijdens de implementatie controleert of uitschakelt. Afhankelijk van uw instellingen moet u dit misschien uitvinken, zoals hieronder:
ClusterControl geeft alleen een waarschuwing dat het uw huidige AppArmor-configuratie niet raakt . Zie hieronder:
Uw AppArmor-profielen beheren
Standaardinstallatie van uw AppArmor in Ubuntu zou geen hulpprogramma's bevatten die zouden helpen om de profielen efficiënt te beheren. Laten we deze pakketten dus als volgt installeren:
$ apt install apparmor-profiles apparmor-utilsControleer na installatie de status van uw AppArmor in het systeem door het aa-status commando uit te voeren. In het knooppunt dat ik gebruik, heb ik de volgende uitvoer zonder MySQL 8 geïnstalleerd.
$ 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.Aangezien ik ClusterControl gebruik om mijn op MySQL-replicatie gebaseerde cluster met AppArmor te implementeren (d.w.z. ClusterControl zal mijn huidige AppArmor-configuratie niet raken), moet de implementatie het MySQL-profiel hebben en dat verschijnt in de lijst met 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.
Het is vermeldenswaard dat een profiel zich in een van de volgende modi bevindt:
-
Afdwingen - Standaardinstelling. Toepassingen kunnen geen acties ondernemen die worden beperkt door de profielregels.
-
Klagen - Toepassingen mogen beperkte acties uitvoeren en de acties worden vastgelegd.
-
Uitgeschakeld - Toepassingen mogen beperkte acties uitvoeren en de acties worden niet geregistreerd.
Je kunt ook handhavings- en klachtprofielen op je server combineren.
Laten we op basis van de bovenstaande uitvoer meer ingaan op de profielklacht. AppArmor zal het toestaan om alle taken zonder beperking uit te voeren (bijna omdat de status van de klachtenmodus nog steeds expliciete weigeringsregels in een profiel afdwingt), maar het zal ze in het auditlogboek loggen als gebeurtenissen. Dit is handig wanneer u probeert een profiel voor een toepassing te maken, maar niet zeker weet tot welke dingen toegang moet worden verkregen. Terwijl de onbeperkte status het programma daarentegen in staat stelt elke taak uit te voeren en deze niet vastlegt. Dit gebeurt meestal als een profiel is geladen nadat een toepassing is gestart, wat betekent dat het zonder beperkingen wordt uitgevoerd vanuit AppArmor. Het is ook belangrijk op te merken dat alleen processen met profielen onder deze onbeperkte status worden vermeld. Alle andere processen die op uw systeem draaien, maar waarvoor geen profiel is aangemaakt, worden niet vermeld onder aa-status.
Als je AppArmor hebt uitgeschakeld, maar je realiseert je dat je je beveiliging wilt verbeteren of wilt voldoen aan de beveiligingsvoorschriften, kun je dit MySQL 8.0-profiel gebruiken dat door MySQL zelf wordt geleverd. Om dat toe te passen, voert u gewoon de volgende opdracht uit:
$ cat /etc/apparmor.d/usr.sbin.mysqld | sudo apparmor_parser -aHet is vermeldenswaard dat AppArmor-profielen standaard worden opgeslagen in /etc/apparmor.d/. Het is een goede gewoonte om uw profielen in die map toe te voegen.
Uw AppArmor-profielen diagnosticeren
AppArmor-logboeken zijn te vinden in het systemd-journaal, in /var/log/syslog en /var/log/kern.log (en /var/log/audit.log wanneer auditd is geïnstalleerd). Waar je naar moet zoeken is het volgende:
-
TOEGESTAAN (geregistreerd wanneer een profiel in de klachtenmodus het beleid schendt)
-
DENIED (geregistreerd wanneer een profiel in de afdwingingsmodus een bewerking daadwerkelijk blokkeert)
Het volledige logbericht zou meer informatie moeten geven over welke exacte toegang is geweigerd. U kunt dit gebruiken om profielen te bewerken voordat u ze in de afdwingingsmodus inschakelt.
Bijvoorbeeld
$ 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"Uw AppArmor-profiel aanpassen
Profielen die zijn opgesteld door Oracle MySQL mogen geen one-size-fits-all patroon zijn. In dat geval kunt u besluiten om bijvoorbeeld de gegevensdirectory te wijzigen waarin uw MySQL-instantiegegevens zich bevinden. Nadat u de wijzigingen op uw configuratiebestand hebt toegepast en uw MySQL-instanties opnieuw hebt opgestart, zal AppArmor deze actie weigeren. Bijvoorbeeld,
$ 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=1002Samen met de fout die ik eerder had, voegt het nu toe dat ik zojuist had besloten om de /mysql-data directory te gebruiken, maar dat wordt geweigerd.
Laten we het volgende doen om de wijzigingen toe te passen. Bewerk het bestand /etc/apparmor.d/usr.sbin.mysqld. Mogelijk vindt u deze regels:
# 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
De man-pagina legt deze vlaggen in meer detail uit.
Nu heb ik het als volgt gewijzigd:
# Allow data dir access
/mysql-data/ r,
/mysql-data/** rwk,Vervolgens herlaad ik de profielen als volgt:
$ apparmor_parser -r -T /etc/apparmor.d/usr.sbin.mysqldHerstart de MySQL-server:
$ systemctl restart mysql.serviceWat als ik mijn mysqld in een klachtenmodus zet?
Zoals eerder vermeld, dwingt de status van de klachtmodus nog steeds expliciete weigeringsregels in een profiel af. Hoewel dit bijvoorbeeld werkt:
$ aa-complain /usr/sbin/mysqldInstellen van /usr/sbin/mysqld op klachtenmodus.
Dan,
$ 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.Nadat je MySQL opnieuw hebt opgestart, wordt het uitgevoerd en worden logbestanden weergegeven zoals:
/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: 0In dat geval is het afdwingen en opnieuw laden van uw profiel een efficiënte en gemakkelijke manier om uw MySQL-profielen met AppArmor te beheren.