Como configurar o AppArmor para PostgreSQL e TimescaleDB

A segurança é uma obrigação para todos os sistemas para proteger seus dados o máximo possível. Mesmo quando há sempre o risco de ser hackeado, seguir uma lista de verificação de segurança reduzirá esse risco significativamente. Uma lista de verificação de segurança básica inclui uma configuração de firewall, criptografia de dados, política de autenticação, etc. Outra ferramenta importante para proteger seus dados em sistemas operacionais baseados em Debian é o AppArmor. Neste blog, veremos o que é e como configurá-lo para bancos de dados PostgreSQL e TimescaleDB.

O que é AppArmor?

O AppArmor, incluído por padrão nos sistemas operacionais Ubuntu e Debian (entre outros), é um sistema de Controle de Acesso Obrigatório (MAC) para confinar programas a um conjunto limitado de recursos. Ele funciona usando perfis carregados no kernel. Esses perfis podem ser configurados em dois modos:

Aplicação:Os perfis carregados neste modo aplicarão a política definida no perfil, bem como relatarão a violação da política tentativas.
Reclamar:Os perfis neste modo não aplicarão a política, mas relatarão tentativas de violação da política.

Além disso, o AppArmor permite a combinação de perfis de modo de aplicação e reclamação.

Como configurar o AppArmor

Os perfis do AppArmor estão em /etc/apparmor.d/. Você pode criar seus próprios perfis e movê-los para lá ou verificar o repositório do AppArmor. Vamos ver como criar um novo perfil do AppArmor.

Primeiro, vamos instalar os pacotes necessários para lidar com isso:

$ apt install apparmor-profiles apparmor-utils

E veja se o AppArmor está habilitado:

$ systemctl status apparmor.service

$ aa-status
apparmor module is loaded.
31 profiles are loaded.
29 profiles are in enforce mode.
   /snap/snapd/11588/usr/lib/snapd/snap-confine
   /snap/snapd/11588/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
  ...

Se você verificar o caminho mencionado /etc/apparmor.d/, verá alguns perfis básicos como usr.sbin.tcpdump ou usr.sbin.traceroute. Agora, vamos criar um novo perfil para PostgreSQL ou TimescaleDB. Para isso, você pode usar este perfil como exemplo. Com base nesse perfil, substituiremos a versão do PostgreSQL para ser mais específico. Neste caso, usaremos o PostgreSQL 13.

# Author: Felix Geyer <[email protected]>
#include <tunables/global>
/usr/lib/postgresql/13/bin/postgres {
  #include <abstractions/base>
  #include <abstractions/nameservice>
  #include <abstractions/ssl_keys>
  /etc/postgresql/** r,
  /usr/share/postgresql/** r,
  /var/lib/postgresql/** rwl,
  /{,var/}run/postgresql/** rw,
  owner @{PROC}/13/oom_adj rw,
}

Armazene-o em /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres. Em seguida, carregue o novo perfil usando apparmor_parser -a:

$ cat /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres | sudo apparmor_parser -a

Se você quiser alterar algo neste perfil, precisará recarregá-lo:

$ apparmor_parser -r /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres

Você pode atribuir o modo Reclamar ao perfil usando o seguinte comando:

$ aa-complain /usr/lib/postgresql/13/bin/postgres

Então, você pode verificar o arquivo syslog em /var/log para ver se a configuração do AppArmor está correta ou se você precisa modificar algo. Quando for seguro, você pode alterar o modo para Enforce executando:

$ aa-enforce /usr/lib/postgresql/13/bin/postgres

Você pode filtrar o log procurando por ações ALLOWED ou DENIED:

Jun 25 19:48:02 ip-172-31-18-94 kernel: [ 5160.111028] audit: type=1400 audit(1624650482.537:103): apparmor="ALLOWED" operation="open" profile="/usr/lib/postgresql/13/bin/postgres" name="/proc/17405/oom_score_adj" pid=17405 comm="postgres" requested_mask="w" denied_mask="w" fsuid=113 ouid=113

Jun 25 19:48:02 ip-172-31-18-94 kernel: [ 5160.112524] audit: type=1400 audit(1624650482.541:104): apparmor="ALLOWED" operation="open" profile="/usr/lib/postgresql/13/bin/postgres" name="/proc/17404/oom_score_adj" pid=17404 comm="postgres" requested_mask="w" denied_mask="w" fsuid=113 ouid=113

Jun 25 19:50:02 ip-172-31-18-94 kernel: [ 5280.141262] audit: type=1400 audit(1624650602.569:112): apparmor="DENIED" operation="open" profile="/usr/lib/postgresql/13/bin/postgres" name="/proc/17518/oom_score_adj" pid=17518 comm="postgres" requested_mask="w" denied_mask="w" fsuid=113 ouid=113

Você também pode desabilitar perfis desta forma:

$ aa-disable /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres

E você precisará recarregar o serviço:

$ systemctl reload apparmor.service

Caso você prefira desabilitar o AppArmor, você pode executar:

$ systemctl stop apparmor
$ systemctl disable apparmor

Claro, isso não é recomendado para ambientes de produção, e você deve mantê-lo rodando, pelo menos, usando o modo Reclamar em todos os perfis, para que você possa verificar os logs procurando comportamentos inesperados.

Como usar PostgreSQL e TimescaleDB com ClusterControl e AppArmor

O ClusterControl não gerencia nenhum módulo de segurança do kernel Linux como o AppArmor. Ao implantar um cluster PostgreSQL ou TimescaleDB usando o ClusterControl, você pode especificar se deseja que o ClusterControl desabilite o AppArmor para você durante o processo de implantação para reduzir o risco de erros:

Se você não quiser desativá-lo, o que é recomendado para produção ambientes, você pode usar o modo Reclamar e monitorar o log em seus servidores para garantir que você tenha a configuração correta do AppArmor. Depois disso, você pode alterá-lo para Enforce seguindo as instruções mencionadas acima.

Você pode encontrar mais informações sobre a configuração do AppArmor no site oficial do Ubuntu.