Letzte Woche haben wir darüber gesprochen, wie man AppArmor für MongoDB-Replikatsätze konfiguriert, die im Grunde die gleichen Konzepte haben, die anwendbar sind, wenn Sie dies für Ihre MySQL-basierten Systeme konfigurieren. Sicherheit ist in der Tat sehr wichtig, da Sie sicherstellen müssen, dass Ihre Daten sehr gut geschützt und gegen unerwünschtes Sammeln von Daten aus Ihrer Geschäftsdomäne eingekapselt sind.
Ein bisschen Geschichte über AppArmor
AppArmor wurde erstmals 1998–2003 in Immunix Linux verwendet. AppArmor war damals als SubDomain bekannt, ein Hinweis auf die Möglichkeit, ein Sicherheitsprofil für ein bestimmtes Programm in verschiedene Domänen zu unterteilen, zwischen denen das Programm dynamisch wechseln kann. AppArmor wurde zuerst in SLES und openSUSE verfügbar gemacht und war zuerst standardmäßig in SLES 10 und in openSUSE 10.1 aktiviert.
Im Mai 2005 erwarb Novell Immunix und benannte SubDomain in AppArmor um und begann mit der Code-Bereinigung und -Umschreibung für die Aufnahme in den Linux-Kernel. Von 2005 bis September 2007 wurde AppArmor von Novell gewartet. Novell wurde von SUSE übernommen, die nun die rechtmäßigen Eigentümer des markenrechtlich geschützten Namens AppArmor sind.
AppArmor wurde erstmals im April 2007 erfolgreich für Ubuntu portiert/gepackt. AppArmor wurde ab Ubuntu 7.10 zu einem Standardpaket und kam als Teil der Veröffentlichung von Ubuntu 8.04, das standardmäßig nur CUPS schützt. Ab Ubuntu 9.04 haben weitere Elemente wie MySQL installierte Profile. Die AppArmor-Härtung wurde in Ubuntu 9.10 weiter verbessert, da es mit Profilen für seine Gastsitzung, virtuellen libvirt-Maschinen, dem Evince-Dokumentenbetrachter und einem optionalen Firefox-Profil ausgeliefert wird.
Warum brauchen wir AppArmor?
In unserem vorherigen Blog haben wir uns ein wenig mit der Verwendung von AppArmor beschäftigt. Es ist ein Mandatory Access Control (MAC)-System, das auf den Linux Security Modules (LSM) implementiert ist. Es wird in Systemen wie Ubuntu, Debian (seit Buster), SUSE und anderen Distributionen verwendet und meistens standardmäßig aktiviert. Es ist vergleichbar mit RHEL/CentOS SELinux, das eine gute Userspace-Integration erfordert, um ordnungsgemäß zu funktionieren. SELinux versieht alle Dateien, Prozesse und Objekte mit Labels und ist daher sehr flexibel. Die Konfiguration von SELinux gilt jedoch als sehr kompliziert und erfordert ein unterstütztes Dateisystem. AppArmor hingegen arbeitet mit Dateipfaden und lässt sich einfach konfigurieren.
AppArmor ergänzt, wie die meisten anderen LSMs, die standardmäßige Discretionary Access Control (DAC), anstatt sie zu ersetzen. Daher ist es unmöglich, einem Prozess mehr Privilegien zu gewähren, als er ursprünglich hatte.
AppArmor schützt das Betriebssystem und Anwendungen proaktiv vor externen oder internen Bedrohungen und sogar vor Zero-Day-Angriffen, indem es einen bestimmten Regelsatz pro Anwendung durchsetzt. Sicherheitsrichtlinien definieren vollständig, auf welche Systemressourcen einzelne Anwendungen zugreifen können und mit welchen Rechten. Der Zugriff wird standardmäßig verweigert, wenn kein Profil etwas anderes sagt. Einige Standardrichtlinien sind in AppArmor enthalten, und mithilfe einer Kombination aus fortschrittlicher statischer Analyse und lernbasierten Tools können AppArmor-Richtlinien selbst für sehr komplexe Anwendungen innerhalb weniger Stunden erfolgreich bereitgestellt werden.
Jeder Richtlinienverstoß löst eine Meldung im Systemprotokoll aus und AppArmor kann so konfiguriert werden, dass Benutzer in Echtzeit mit Verstößen gewarnt werden.
AppArmor für MySQL
Ich habe einen auf MySQL-Replikation basierenden Cluster mit ClusterControl für meine Zieldatenbankknoten eingerichtet, die in Ubuntu Bionic ausgeführt werden. Sie können diesem Blog weiter folgen, um zu erfahren, wie es bereitgestellt wird, oder diesem Video-Tutorial folgen. Beachten Sie, dass ClusterControl AppArmor während der Bereitstellung überprüft oder deaktiviert. Möglicherweise müssen Sie dies entsprechend Ihrer Einrichtung wie folgt deaktivieren:
ClusterControl gibt nur eine Warnung aus, dass Ihre aktuelle AppArmor-Konfiguration nicht berührt wird . Siehe unten:
Ihre AppArmor-Profile verwalten
Die Standardinstallation Ihres AppArmor in Ubuntu würde keine Dienstprogramme enthalten, die bei der effizienten Verwaltung der Profile helfen würden. Also lassen Sie uns diese Pakete wie folgt installieren:
$ apt install apparmor-profiles apparmor-utilsÜberprüfen Sie nach der Installation den Status Ihres AppArmor im System, indem Sie den Befehl aa-status ausführen. In dem von mir verwendeten Knoten habe ich die folgende Ausgabe, ohne dass MySQL 8 installiert ist.
$ 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 ich ClusterControl verwende, um meinen auf MySQL-Replikation basierenden Cluster mit AppArmor bereitzustellen (d. h. ClusterControl wird meine aktuelle AppArmor-Konfiguration nicht berühren), muss die Bereitstellung das MySQL-Profil haben und das wird in angezeigt die Liste mit 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.
Es ist erwähnenswert, dass sich ein Profil in einem der folgenden Modi befindet:
-
Erzwingen - Standardeinstellung. Anwendungen werden daran gehindert, durch die Profilregeln eingeschränkte Aktionen auszuführen.
-
Beschweren – Anwendungen dürfen eingeschränkte Aktionen ausführen, und die Aktionen werden protokolliert.
-
Deaktiviert – Anwendungen dürfen eingeschränkte Aktionen ausführen, und die Aktionen werden nicht protokolliert.
Sie können auf Ihrem Server auch Vollstreckungs- und Beschwerdeprofile mischen.
Lassen Sie uns basierend auf der obigen Ausgabe näher auf die Profilbeschwerde eingehen. AppArmor lässt zu, dass alle Aufgaben uneingeschränkt ausgeführt werden (fast so, wie der Status des Beschwerdemodus immer noch alle expliziten Ablehnungsregeln in einem Profil erzwingt), aber es protokolliert sie im Audit-Protokoll als Ereignisse. Dies ist nützlich, wenn Sie versuchen, ein Profil für eine Anwendung zu erstellen, sich aber nicht sicher sind, auf welche Dinge sie Zugriff benötigt. Der uneingeschränkte Status hingegen erlaubt dem Programm, jede Aufgabe auszuführen, und protokolliert sie nicht. Dies tritt normalerweise auf, wenn ein Profil geladen wurde, nachdem eine Anwendung gestartet wurde, was bedeutet, dass sie ohne Einschränkungen von AppArmor ausgeführt wird. Es ist auch wichtig zu beachten, dass nur Prozesse mit Profilen unter diesem uneingeschränkten Status aufgelistet werden. Alle anderen Prozesse, die auf Ihrem System ausgeführt werden, für die jedoch kein Profil erstellt wurde, werden nicht unter aa-status aufgelistet.
Wenn Sie AppArmor deaktiviert haben, dann aber feststellen, dass Sie Ihre Sicherheit verbessern oder Sicherheitsvorschriften einhalten möchten, können Sie dieses MySQL 8.0-Profil verwenden, das von MySQL selbst bereitgestellt wird. Führen Sie dazu einfach den folgenden Befehl aus:
$ cat /etc/apparmor.d/usr.sbin.mysqld | sudo apparmor_parser -aEs ist erwähnenswert, dass AppArmor-Profile standardmäßig in /etc/apparmor.d/ gespeichert werden. Es empfiehlt sich, Ihre Profile in diesem Verzeichnis hinzuzufügen.
Ihre AppArmor-Profile diagnostizieren
AppArmor-Protokolle finden Sie im systemd-Journal, in /var/log/syslog und /var/log/kern.log (und /var/log/audit.log, wenn auditd installiert ist). Worauf Sie achten müssen, ist Folgendes:
-
ERLAUBT (wird protokolliert, wenn ein Profil im Beschwerdemodus gegen die Richtlinie verstößt)
-
DENIED (protokolliert, wenn ein Profil im Erzwingungsmodus tatsächlich eine Operation blockiert)
Die vollständige Protokollnachricht sollte mehr Informationen darüber enthalten, welcher Zugriff verweigert wurde. Sie können dies verwenden, um Profile zu bearbeiten, bevor Sie sie im Erzwingungsmodus aktivieren.
Zum Beispiel
$ 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"Anpassen Ihres AppArmor-Profils
Profile, die von Oracle MySQL erstellt wurden, dürfen kein Einheitsmuster sein. In diesem Fall können Sie beispielsweise das Datenverzeichnis ändern, in dem sich Ihre MySQL-Instanzdaten befinden. Nachdem Sie die Änderungen auf Ihre Konfigurationsdatei angewendet und Ihre MySQL-Instanzen neu gestartet haben, verweigert AppArmor diese Aktion. Zum Beispiel
$ 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=1002Zusammen mit dem Fehler, den ich zuvor hatte, fügt es jetzt hinzu, dass ich mich gerade entschieden hatte, das /mysql-data-Verzeichnis zu verwenden, aber das wird verweigert.
Um die Änderungen anzuwenden, gehen wir wie folgt vor. Bearbeiten Sie die Datei /etc/apparmor.d/usr.sbin.mysqld. Sie könnten diese Zeilen finden:
# 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
Die Manpage erklärt diese Flags ausführlicher.
Jetzt habe ich es wie folgt geändert:
# Allow data dir access
/mysql-data/ r,
/mysql-data/** rwk,Dann lade ich die Profile wie folgt neu:
$ apparmor_parser -r -T /etc/apparmor.d/usr.sbin.mysqldStarten Sie den MySQL-Server neu:
$ systemctl restart mysql.serviceWas ist, wenn ich mysqld in einen Beschwerdemodus versetze?
Wie bereits erwähnt, erzwingt der Beschwerdemodusstatus weiterhin alle expliziten Ablehnungsregeln in einem Profil. Obwohl dies zum Beispiel funktioniert:
$ aa-complain /usr/sbin/mysqldSetze /usr/sbin/mysqld in den Beschwerdemodus.
Dann
$ 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.Nachdem Sie MySQL neu gestartet haben, wird es ausgeführt und zeigt Protokolldateien wie:
/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 diesem Fall ist das Erzwingen und Neuladen Ihres Profils ein effizienter und einfacher Ansatz, um Ihre MySQL-Profile mit AppArmor zu verwalten.
