La semaine dernière, nous avons expliqué comment configurer AppArmor pour les ensembles de répliques MongoDB, qui a essentiellement les mêmes concepts applicables lors de la configuration de vos systèmes basés sur MySQL. En effet, la sécurité est très importante car vous devez vous assurer que vos données sont très bien protégées et encapsulées contre la collecte de données indésirables d'informations provenant de votre domaine d'activité.
Un peu d'histoire sur AppArmor
AppArmor a été utilisé pour la première fois dans Immunix Linux 1998–2003. À l'époque, AppArmor était connu sous le nom de SubDomain, une référence à la capacité d'un profil de sécurité pour un programme spécifique à être segmenté en différents domaines, entre lesquels le programme peut basculer de manière dynamique. AppArmor a été mis à disposition pour la première fois dans SLES et openSUSE, et a été activé pour la première fois par défaut dans SLES 10 et dans openSUSE 10.1.
En mai 2005, Novell a acquis Immunix et a renommé SubDomain en AppArmor et a commencé le nettoyage et la réécriture du code pour l'inclure dans le noyau Linux. De 2005 à septembre 2007, AppArmor a été maintenu par Novell. Novell a été racheté par SUSE, qui est désormais le propriétaire légal du nom de marque AppArmor.
AppArmor a été porté pour la première fois avec succès pour Ubuntu en avril 2007. AppArmor est devenu un package par défaut à partir d'Ubuntu 7.10 et faisait partie de la version d'Ubuntu 8.04, protégeant uniquement CUPS par défaut. Depuis Ubuntu 9.04, d'autres éléments tels que MySQL ont installé des profils. Le renforcement d'AppArmor a continué de s'améliorer dans Ubuntu 9.10 car il est livré avec des profils pour sa session invité, des machines virtuelles libvirt, la visionneuse de documents Evince et un profil Firefox facultatif.
Pourquoi avons-nous besoin d'AppArmor ?
Dans notre blog précédent, nous avons abordé un peu l'utilisation d'AppArmor. Il s'agit d'un système de contrôle d'accès obligatoire (MAC), implémenté sur les modules de sécurité Linux (LSM). Il est utilisé et principalement activé par défaut dans des systèmes tels que Ubuntu, Debian (depuis Buster), SUSE et d'autres distributions. Il est comparable à RHEL/CentOS SELinux, qui nécessite une bonne intégration de l'espace utilisateur pour fonctionner correctement. SELinux attache des étiquettes à tous les fichiers, processus et objets et est donc très flexible. Cependant, la configuration de SELinux est considérée comme très compliquée et nécessite un système de fichiers pris en charge. AppArmor, en revanche, fonctionne à l'aide de chemins de fichiers et sa configuration peut être facilement adaptée.
AppArmor, comme la plupart des autres LSM, complète plutôt qu'il ne remplace le contrôle d'accès discrétionnaire (DAC) par défaut. En tant que tel, il est impossible d'accorder à un processus plus de privilèges qu'il n'en avait au départ.
AppArmor protège de manière proactive le système d'exploitation et les applications contre les menaces externes ou internes et même les attaques zero-day en appliquant un ensemble de règles spécifiques pour chaque application. Les politiques de sécurité définissent complètement les ressources système auxquelles les applications individuelles peuvent accéder et avec quels privilèges. L'accès est refusé par défaut si aucun profil ne dit le contraire. Quelques stratégies par défaut sont incluses avec AppArmor et en utilisant une combinaison d'analyse statique avancée et d'outils basés sur l'apprentissage, les stratégies AppArmor pour les applications même très complexes peuvent être déployées avec succès en quelques heures.
Chaque violation de politique déclenche un message dans le journal système, et AppArmor peut être configuré pour notifier les utilisateurs avec des avertissements de violation en temps réel.
AppArmor pour MySQL
J'ai configuré un cluster basé sur la réplication MySQL à l'aide de ClusterControl sur mes nœuds de base de données cibles exécutés dans Ubuntu Bionic. Vous pouvez en outre suivre ce blog sur la façon de le déployer ou suivre ce didacticiel vidéo. Notez que ClusterControl vérifie ou désactive AppArmor lors du déploiement. Vous devrez peut-être décocher cette option en fonction de votre configuration, comme ci-dessous :
ClusterControl émettra simplement un avertissement indiquant qu'il ne touche pas votre configuration AppArmor actuelle . Voir ci-dessous :
Gérer vos profils AppArmor
L'installation standard de votre AppArmor dans Ubuntu n'inclurait pas les utilitaires qui aideraient à gérer efficacement les profils. Alors installons ces packages comme suit :
$ apt install apparmor-profiles apparmor-utilsUne fois installé, vérifiez l'état de votre AppArmor dans le système en exécutant la commande aa-status. Dans le nœud que j'utilise, j'ai la sortie suivante sans MySQL 8 installé.
Le module$ 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.Puisque j'utilise ClusterControl pour déployer mon cluster basé sur la réplication MySQL avec AppArmor (c'est-à-dire que ClusterControl ne touchera pas ma configuration AppArmor actuelle), le déploiement doit avoir le profil MySQL en place et qui apparaît dans la liste exécutant aa-status.
Le module$ 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.
Il convient de noter qu'un profil est dans l'un des modes suivants :
-
Appliquer - Paramètre par défaut. Les applications ne peuvent pas effectuer d'actions restreintes par les règles de profil.
-
Plainte :les applications sont autorisées à effectuer des actions restreintes, et les actions sont consignées.
-
Désactivé :les applications sont autorisées à effectuer des actions restreintes et les actions ne sont pas enregistrées.
Vous pouvez également combiner les profils d'application et de réclamation dans votre serveur.
En fonction du résultat ci-dessus, expliquons plus en détail la réclamation de profil. AppArmor lui permettra d'effectuer (presque comme l'état du mode de réclamation appliquera toujours les règles de refus explicites dans un profil) toutes les tâches sans restriction, mais il les enregistrera dans le journal d'audit en tant qu'événements. Ceci est utile lorsque vous essayez de créer un profil pour une application mais que vous ne savez pas à quoi elle doit accéder. Alors que le statut non confiné, d'autre part, permettra au programme d'effectuer n'importe quelle tâche et ne l'enregistrera pas. Cela se produit généralement si un profil a été chargé après le démarrage d'une application, ce qui signifie qu'il s'exécute sans restrictions à partir d'AppArmor. Il est également important de noter que seuls les processus qui ont des profils sont répertoriés sous ce statut non limité. Tous les autres processus qui s'exécutent sur votre système mais pour lesquels aucun profil n'a été créé pour eux ne seront pas répertoriés sous le statut aa.
Si vous avez désactivé AppArmor mais réalisez ensuite que vous vouliez améliorer votre sécurité ou vous conformer aux réglementations de sécurité, vous pouvez utiliser ce profil MySQL 8.0 fourni par MySQL lui-même. Pour l'appliquer, exécutez simplement la commande suivante :
$ cat /etc/apparmor.d/usr.sbin.mysqld | sudo apparmor_parser -aIl convient de noter que les profils AppArmor sont stockés par défaut dans /etc/apparmor.d/. C'est une bonne pratique d'ajouter vos profils dans ce répertoire.
Diagnostic de vos profils AppArmor
Les journaux AppArmor se trouvent dans le journal systemd, dans /var/log/syslog et /var/log/kern.log (et /var/log/audit.log lorsque auditd est installé). Ce que vous devez rechercher est le suivant :
-
AUTORISÉ (enregistré lorsqu'un profil en mode réclamation enfreint la politique)
-
REFUSÉ (consigné lorsqu'un profil en mode application bloque réellement une opération)
Le message de journal complet devrait fournir plus d'informations sur l'accès exact qui a été refusé. Vous pouvez l'utiliser pour modifier les profils avant de les activer en mode d'application.
Par exemple,
$ 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"Personnalisation de votre profil AppArmor
Les profils préparés par Oracle MySQL ne doivent pas être un modèle unique. Dans ce cas, vous pouvez décider de modifier, par exemple, le répertoire de données dans lequel se trouvent les données de votre instance MySQL. Après avoir appliqué les modifications à votre fichier de configuration et redémarré vos instances MySQL, AppArmor refusera cette action. Par exemple,
$ 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=1002Avec l'erreur que j'ai eue plus tôt, il ajoute maintenant que je venais de décider d'utiliser le répertoire /mysql-data mais cela est refusé.
Pour appliquer les modifications, procédons comme suit. Modifiez le fichier /etc/apparmor.d/usr.sbin.mysqld. Vous pourriez trouver ces lignes :
# 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
La page de manuel explique ces drapeaux plus en détail.
Maintenant, je l'ai changé comme suit :
# Allow data dir access
/mysql-data/ r,
/mysql-data/** rwk,Puis je recharge les profils comme suit :
$ apparmor_parser -r -T /etc/apparmor.d/usr.sbin.mysqldRedémarrez le serveur MySQL :
$ systemctl restart mysql.serviceEt si je mets mon mysqld en mode réclamation ?
Comme mentionné précédemment, le statut du mode de réclamation appliquera toujours les règles de refus explicites dans un profil. Bien que cela fonctionne par exemple :
$ aa-complain /usr/sbin/mysqldConfigurer /usr/sbin/mysqld en mode plainte.
Alors,
Le module$ 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.Après avoir redémarré MySQL, il s'exécutera et affichera des fichiers journaux tels que :
/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: 0Dans ce cas, l'utilisation de l'application et du rechargement de votre profil constitue une approche efficace et simple pour gérer vos profils MySQL avec AppArmor.
