Na semana passada, discutimos como configurar AppArmor for MongoDB Replica Sets, que basicamente tem os mesmos conceitos aplicáveis ao configurar isso para seus sistemas baseados em MySQL. De fato, a segurança é muito importante porque você precisa garantir que seus dados estejam muito bem protegidos e encapsulados contra a coleta de dados indesejados de seu domínio de negócios.
Um pouco da história do AppArmor
O AppArmor foi usado pela primeira vez no Immunix Linux 1998–2003. Na época, o AppArmor era conhecido como SubDomain, uma referência à capacidade de um perfil de segurança para um programa específico ser segmentado em diferentes domínios, entre os quais o programa pode alternar dinamicamente. O AppArmor foi disponibilizado pela primeira vez no SLES e no openSUSE e foi ativado por padrão no SLES 10 e no openSUSE 10.1.
Em maio de 2005, a Novell adquiriu a Immunix e renomeou SubDomain como AppArmor e começou a limpeza e reescrita de código para inclusão no kernel Linux. De 2005 a setembro de 2007, o AppArmor foi mantido pela Novell. A Novell foi adquirida pela SUSE, que agora é a proprietária legal da marca registrada AppArmor.
O AppArmor foi portado/empacotado com sucesso para o Ubuntu em abril de 2007. O AppArmor tornou-se um pacote padrão a partir do Ubuntu 7.10 e veio como parte do lançamento do Ubuntu 8.04, protegendo apenas o CUPS por padrão. A partir do Ubuntu 9.04, mais itens como o MySQL têm perfis instalados. O endurecimento do AppArmor continuou a melhorar no Ubuntu 9.10, pois ele vem com perfis para sua sessão de convidado, máquinas virtuais libvirt, o visualizador de documentos Evince e um perfil opcional do Firefox.
Por que precisamos do AppArmor?
Em nosso blog anterior, abordamos um pouco do que é o uso do AppArmor. É um sistema de Controle de Acesso Obrigatório (MAC), implementado sobre os Módulos de Segurança Linux (LSM). Ele é usado e ativado principalmente por padrão em sistemas como Ubuntu, Debian (desde Buster), SUSE e outras distribuições. É comparável ao RHEL/CentOS SELinux, que requer uma boa integração de espaço de usuário para funcionar corretamente. O SELinux anexa rótulos a todos os arquivos, processos e objetos e, portanto, é muito flexível. No entanto, configurar o SELinux é considerado muito complicado e requer um sistema de arquivos suportado. O AppArmor, por outro lado, funciona usando caminhos de arquivo e sua configuração pode ser facilmente adaptada.
O AppArmor, como a maioria dos outros LSMs, complementa em vez de substituir o controle de acesso discricionário (DAC) padrão. Como tal, é impossível conceder a um processo mais privilégios do que ele tinha em primeiro lugar.
O AppArmor protege proativamente o sistema operacional e os aplicativos contra ameaças externas ou internas e até mesmo ataques de dia zero, aplicando uma regra específica definida por aplicativo. As políticas de segurança definem completamente quais recursos do sistema os aplicativos individuais podem acessar e com quais privilégios. O acesso é negado por padrão se nenhum perfil disser o contrário. Algumas políticas padrão estão incluídas no AppArmor e, usando uma combinação de análise estática avançada e ferramentas baseadas em aprendizado, as políticas do AppArmor para aplicativos muito complexos podem ser implantadas com sucesso em questão de horas.
Cada violação de política aciona uma mensagem no log do sistema, e o AppArmor pode ser configurado para notificar os usuários com avisos de violação em tempo real.
AppArmor para MySQL
Eu configurei um cluster baseado em replicação MySQL usando ClusterControl para meus nós de banco de dados de destino em execução no Ubuntu Bionic. Você pode seguir este blog sobre como implantá-lo ou seguir este tutorial em vídeo. Observe que o ClusterControl verifica ou desabilita o AppArmor durante a implantação. Você pode ter que desmarcar isso de acordo com sua configuração, como abaixo:
ClusterControl apenas emitirá um aviso de que não está afetando sua configuração atual do AppArmor . Ver abaixo:
Gerenciando seus perfis do AppArmor
A instalação padrão do seu AppArmor no Ubuntu não inclui utilitários que ajudem a gerenciar os perfis com eficiência. Então vamos instalar esses pacotes assim:
$ apt install apparmor-profiles apparmor-utilsUma vez instalado, verifique o status do seu AppArmor no sistema executando o comando aa-status. No nó que estou usando, tenho a seguinte saída sem o 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.Como estou usando o ClusterControl para implantar meu cluster baseado em replicação MySQL com o AppArmor (ou seja, o ClusterControl não tocará na minha configuração atual do AppArmor), a implantação deve ter o perfil MySQL em vigor e que aparece em a lista executando 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 a pena notar que um perfil está em um dos seguintes modos:
-
Aplicar - Configuração padrão. Os aplicativos são impedidos de realizar ações restritas pelas regras de perfil.
-
Reclamar - Os aplicativos podem realizar ações restritas e as ações são registradas.
-
Desativado - Os aplicativos podem realizar ações restritas e as ações não são registradas.
Você também pode misturar perfis de imposição e reclamação em seu servidor.
Com base na saída acima, vamos elaborar mais sobre a reclamação do perfil. O AppArmor permitirá que ele execute (quase como o status do modo de reclamação ainda impõe quaisquer regras de negação explícitas em um perfil) todas as tarefas sem restrição, mas as registrará no log de auditoria como eventos. Isso é útil quando você está tentando criar um perfil para um aplicativo, mas não tem certeza de quais itens ele precisa acessar. Já o status não confinado, por outro lado, permitirá que o programa execute qualquer tarefa e não a registrará. Isso geralmente ocorre se um perfil foi carregado após o início de um aplicativo, o que significa que ele é executado sem restrições do AppArmor. Também é importante observar que apenas os processos que possuem perfis são listados sob esse status não confinado. Quaisquer outros processos executados em seu sistema, mas que não tenham um perfil criado para eles, não serão listados no status aa.
Se você desativou o AppArmor, mas depois percebeu que queria aumentar sua segurança ou cumprir os regulamentos de segurança, você pode usar este perfil MySQL 8.0 que é fornecido pelo próprio MySQL. Para aplicar isso, basta executar o seguinte comando:
$ cat /etc/apparmor.d/usr.sbin.mysqld | sudo apparmor_parser -aVale a pena notar que os perfis do AppArmor são armazenados por padrão em /etc/apparmor.d/. É uma boa prática adicionar seus perfis nesse diretório.
Diagnosticando seus perfis do AppArmor
Os logs do AppArmor podem ser encontrados no diário do systemd, em /var/log/syslog e /var/log/kern.log (e /var/log/audit.log quando o auditd está instalado). O que você precisa procurar é o seguinte:
-
PERMITIDO (registrado quando um perfil no modo de reclamação viola a política)
-
NEGADO (registrado quando um perfil no modo de imposição bloqueia uma operação)
A mensagem de log completa deve fornecer mais informações sobre qual acesso exato foi negado. Você pode usar isso para editar perfis antes de ativá-los no modo de imposição.
Por exemplo,
$ 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"Personalizando seu perfil do AppArmor
Os perfis preparados pelo Oracle MySQL não devem ser um padrão de tamanho único. Nesse caso, você pode decidir alterar, por exemplo, o diretório de dados em que os dados da instância do MySQL estão localizados. Depois de aplicar as alterações em seu arquivo de configuração e reiniciar suas instâncias MySQL, o AppArmor negará essa ação. Por exemplo,
$ 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=1002Juntamente com o erro que tive anteriormente, agora acrescenta que acabei de decidir usar o diretório /mysql-data, mas isso é negado.
Para aplicar as alterações, vamos fazer o seguinte. Edite o arquivo /etc/apparmor.d/usr.sbin.mysqld. Você pode encontrar estas linhas:
# 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
A página man explica esses sinalizadores com mais detalhes.
Agora, alterei para o seguinte:
# Allow data dir access
/mysql-data/ r,
/mysql-data/** rwk,Então eu recarrego os perfis da seguinte forma:
$ apparmor_parser -r -T /etc/apparmor.d/usr.sbin.mysqldReinicie o servidor MySQL:
$ systemctl restart mysql.serviceE se eu configurar meu mysqld para um modo de reclamação?
Como mencionado anteriormente, o status do modo de reclamação ainda aplicará todas as regras de negação explícitas em um perfil. Embora isso funcione, por exemplo:
$ aa-complain /usr/sbin/mysqldConfigurando /usr/sbin/mysqld para o modo de reclamação.
Então,
$ 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.Depois de reiniciar o MySQL, ele será executado e mostrará arquivos de log 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: 0Nesse caso, usar forçar e recarregar seu perfil será uma abordagem eficiente e fácil para gerenciar seus perfis MySQL com o AppArmor.
