La semana pasada, discutimos cómo configurar AppArmor para MongoDB Replica Sets, que básicamente tiene los mismos conceptos aplicables al configurar esto para sus sistemas basados en MySQL. De hecho, la seguridad es muy importante porque debe asegurarse de que sus datos estén muy bien protegidos y encapsulados contra la recopilación de datos no deseados de información de su dominio comercial.
Un poco de historia sobre AppArmor
AppArmor se utilizó por primera vez en Immunix Linux 1998–2003. En ese momento, AppArmor se conocía como Subdominio, una referencia a la capacidad de segmentar un perfil de seguridad para un programa específico en diferentes dominios, entre los cuales el programa puede cambiar dinámicamente. AppArmor estuvo disponible por primera vez en SLES y openSUSE, y se habilitó por primera vez de forma predeterminada en SLES 10 y en openSUSE 10.1.
En mayo de 2005, Novell adquirió Immunix y renombró SubDomain como AppArmor y comenzó a limpiar y reescribir el código para incluirlo en el kernel de Linux. Desde 2005 hasta septiembre de 2007, Novell mantuvo AppArmor. Novell pasó a manos de SUSE, que ahora son los propietarios legales del nombre comercial AppArmor.
AppArmor fue por primera vez portado/empaquetado con éxito para Ubuntu en abril de 2007. AppArmor se convirtió en un paquete predeterminado a partir de Ubuntu 7.10, y vino como parte del lanzamiento de Ubuntu 8.04, protegiendo solo CUPS de forma predeterminada. A partir de Ubuntu 9.04, más elementos como MySQL tienen perfiles instalados. El endurecimiento de AppArmor continuó mejorando en Ubuntu 9.10, ya que incluye perfiles para su sesión de invitado, máquinas virtuales libvirt, el visor de documentos Evince y un perfil de Firefox opcional.
¿Por qué necesitamos AppArmor?
En nuestro blog anterior, hemos abordado un poco cuál es el uso de AppArmor. Es un sistema de control de acceso obligatorio (MAC), implementado sobre los módulos de seguridad de Linux (LSM). Se utiliza y se activa principalmente de forma predeterminada en sistemas como Ubuntu, Debian (desde Buster), SUSE y otras distribuciones. Es comparable a RHEL/CentOS SELinux, que requiere una buena integración del espacio de usuario para funcionar correctamente. SELinux adjunta etiquetas a todos los archivos, procesos y objetos y, por lo tanto, es muy flexible. Sin embargo, la configuración de SELinux se considera muy complicada y requiere un sistema de archivos compatible. AppArmor, por otro lado, funciona usando rutas de archivos y su configuración se puede adaptar fácilmente.
AppArmor, como la mayoría de los demás LSM, complementa en lugar de reemplazar el control de acceso discrecional (DAC) predeterminado. Como tal, es imposible otorgar a un proceso más privilegios de los que tenía en primer lugar.
AppArmor protege de manera proactiva el sistema operativo y las aplicaciones de amenazas externas o internas e incluso ataques de día cero mediante la aplicación de un conjunto de reglas específico por aplicación. Las políticas de seguridad definen completamente a qué recursos del sistema pueden acceder las aplicaciones individuales y con qué privilegios. El acceso se deniega por defecto si ningún perfil dice lo contrario. Se incluyen algunas políticas predeterminadas con AppArmor y, al usar una combinación de análisis estático avanzado y herramientas basadas en el aprendizaje, las políticas de AppArmor incluso para aplicaciones muy complejas se pueden implementar con éxito en cuestión de horas.
Cada incumplimiento de la política activa un mensaje en el registro del sistema y AppArmor se puede configurar para notificar a los usuarios con advertencias de incumplimiento en tiempo real.
AppArmor para MySQL
Configuré un clúster basado en replicación de MySQL usando ClusterControl para mis nodos de base de datos de destino que se ejecutan en Ubuntu Bionic. Puede seguir este blog sobre cómo implementarlo o seguir este video tutorial. Tenga en cuenta que ClusterControl verifica o deshabilita AppArmor durante la implementación. Es posible que deba desmarcar esto de acuerdo con su configuración, tal como se muestra a continuación:
ClusterControl solo emitirá una advertencia de que no está tocando su configuración actual de AppArmor . Ver a continuación:
Administrar sus perfiles de AppArmor
La instalación estándar de su AppArmor en Ubuntu no incluiría utilidades que ayudarían a administrar los perfiles de manera eficiente. Así que instalemos estos paquetes así:
$ apt install apparmor-profiles apparmor-utilsUna vez instalado, verifique el estado de su AppArmor en el sistema ejecutando el comando aa-status. En el nodo que estoy usando, tengo el siguiente resultado sin MySQL 8 instalado.
$ 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.Dado que estoy usando ClusterControl para implementar mi clúster basado en la replicación de MySQL con AppArmor (es decir, ClusterControl no tocará mi configuración actual de AppArmor), la implementación tendrá el perfil de MySQL en su lugar y eso aparecerá en la lista ejecutando 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.
Vale la pena señalar que un perfil está en uno de los siguientes modos:
-
Aplicar:configuración predeterminada. Se impide que las aplicaciones realicen acciones restringidas por las reglas del perfil.
-
Quejas:las aplicaciones pueden realizar acciones restringidas y las acciones se registran.
-
Deshabilitado:las aplicaciones pueden realizar acciones restringidas y las acciones no se registran.
También puede mezclar perfiles de aplicación y denuncia en su servidor.
Basándonos en el resultado anterior, vamos a elaborar más sobre la queja del perfil. AppArmor le permitirá realizar todas las tareas sin restricciones (casi como el estado del modo de queja seguirá aplicando cualquier regla de denegación explícita en un perfil), pero las registrará en el registro de auditoría como eventos. Esto es útil cuando intenta crear un perfil para una aplicación pero no está seguro de a qué cosas necesita acceder. Mientras que el estado no confinado, por otro lado, permitirá que el programa realice cualquier tarea y no la registrará. Esto suele ocurrir si se cargó un perfil después de iniciar una aplicación, lo que significa que se ejecuta sin restricciones desde AppArmor. También es importante tener en cuenta que solo los procesos que tienen perfiles se enumeran en este estado no confinado. Cualquier otro proceso que se ejecute en su sistema pero que no tenga un perfil creado para ellos no se incluirá en el estado aa.
Si ha deshabilitado AppArmor pero luego se da cuenta de que desea mejorar su seguridad o cumplir con las normas de seguridad, puede usar este perfil de MySQL 8.0 que proporciona el propio MySQL. Para aplicar eso, simplemente ejecute el siguiente comando:
$ cat /etc/apparmor.d/usr.sbin.mysqld | sudo apparmor_parser -aVale la pena señalar que los perfiles de AppArmor se almacenan de forma predeterminada en /etc/apparmor.d/. Es una buena práctica agregar sus perfiles en ese directorio.
Diagnóstico de sus perfiles de AppArmor
Los registros de AppArmor se pueden encontrar en el diario systemd, en /var/log/syslog y /var/log/kern.log (y /var/log/audit.log cuando auditd está instalado). Lo que debes buscar es lo siguiente:
-
PERMITIDO (registrado cuando un perfil en modo de queja infringe la política)
-
DENEGADO (registrado cuando un perfil en modo de cumplimiento bloquea una operación)
El mensaje de registro completo debería proporcionar más información sobre qué acceso exacto se ha denegado. Puede usar esto para editar perfiles antes de activarlos en modo obligatorio.
Por ejemplo,
$ 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"Personalizar su perfil de AppArmor
Los perfiles preparados por Oracle MySQL no deben ser un patrón único para todos. En ese caso, puede decidir cambiar, por ejemplo, el directorio de datos donde se encuentran los datos de su instancia de MySQL. Después de aplicar los cambios a su archivo de configuración y reiniciar sus instancias de MySQL, AppArmor denegará esta acción. Por ejemplo,
$ 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=1002Junto con el error que tuve antes, ahora agrega que acababa de decidir usar el directorio /mysql-data pero se niega.
Para aplicar los cambios, hagamos lo siguiente. Edite el archivo /etc/apparmor.d/usr.sbin.mysqld. Puede encontrar estas líneas:
# 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 página del manual explica esas banderas con más detalle.
Ahora, lo he cambiado a lo siguiente:
# Allow data dir access
/mysql-data/ r,
/mysql-data/** rwk,Luego recargo los perfiles de la siguiente manera:
$ apparmor_parser -r -T /etc/apparmor.d/usr.sbin.mysqldReiniciar el servidor MySQL:
$ systemctl restart mysql.service¿Qué sucede si configuro mysqld en modo de queja?
Como se mencionó anteriormente, el estado del modo de queja seguirá aplicando cualquier regla de denegación explícita en un perfil. Aunque esto funciona, por ejemplo:
$ aa-complain /usr/sbin/mysqldConfigurando /usr/sbin/mysqld en modo de queja.
Entonces,
$ 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.Después de reiniciar MySQL, se ejecutará y mostrará archivos de registro como:
/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: 0En ese caso, usar Forzar y recargar su perfil será un enfoque fácil y eficiente para administrar sus perfiles de MySQL con AppArmor.
