Come configurare AppArmor per PostgreSQL e TimescaleDB

La sicurezza è un must per tutti i sistemi per proteggere i tuoi dati il più possibile. Anche quando c'è sempre il rischio di essere hackerato, seguire una checklist di sicurezza ridurrà significativamente questo rischio. Un elenco di controllo di sicurezza di base include una configurazione del firewall, la crittografia dei dati, una politica di autenticazione, ecc. Un altro strumento importante per proteggere i dati sui sistemi operativi basati su Debian è AppArmor. In questo blog vedremo cos'è e come configurarlo per i database PostgreSQL e TimescaleDB.

Cos'è AppArmor?

AppArmor, incluso per impostazione predefinita nei sistemi operativi Ubuntu e Debian (tra gli altri), è un sistema MAC (Mandatory Access Control) per limitare i programmi a un insieme limitato di risorse. Funziona utilizzando i profili caricati nel kernel. Questi profili possono essere configurati in due modalità:

Applicazione:i profili caricati in questa modalità applicheranno la policy definita nel profilo oltre a segnalare la violazione della policy tentativi.
Reclamo:i profili in questa modalità non applicheranno le norme ma segnaleranno invece tentativi di violazione delle norme.

Inoltre, AppArmor consente di combinare profili di applicazione e modalità di reclamo.

Come configurare AppArmor

I profili AppArmor sono in /etc/apparmor.d/. Puoi creare i tuoi profili e spostarli lì o controllare il repository di AppArmor. Vediamo come creare un nuovo profilo AppArmor.

Per prima cosa, installiamo i pacchetti necessari per gestire questo:

$ apt install apparmor-profiles apparmor-utils

E verifica se AppArmor è abilitato:

$ 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 controlli il percorso menzionato /etc/apparmor.d/, vedrai alcuni profili di base come usr.sbin.tcpdump o usr.sbin.traceroute. Ora creiamo un nuovo profilo per PostgreSQL o TimescaleDB. Per questo, puoi usare questo profilo come esempio. Sulla base di quel profilo, sostituiremo la versione di PostgreSQL per essere più specifici. In questo caso, utilizzeremo 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,
}

Memorizzalo in /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres. Quindi, carica il nuovo profilo usando apparmor_parser -a:

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

Se vuoi cambiare qualcosa su questo profilo, dovrai ricaricarlo:

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

Puoi assegnare la modalità Reclamo al profilo utilizzando il seguente comando:

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

Quindi, puoi controllare il file syslog in /var/log per vedere se la configurazione di AppArmor è corretta, oppure devi modificare qualcosa. Quando è sicuro, puoi cambiare la modalità in Enforce eseguendo:

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

Puoi filtrare il registro cercando azioni CONSENTITE o NEGATE:

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

Puoi anche disabilitare i profili in questo modo:

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

E dovrai ricaricare il servizio:

$ systemctl reload apparmor.service

Se preferisci disabilitare AppArmor, puoi eseguire:

$ systemctl stop apparmor
$ systemctl disable apparmor

Ovviamente, questo non è raccomandato per gli ambienti di produzione e dovresti tenerlo in esecuzione, almeno, utilizzando la modalità Reclamo in tutti i profili, in modo da poter controllare i log alla ricerca di comportamenti imprevisti.

Come utilizzare PostgreSQL e TimescaleDB con ClusterControl e AppArmor

ClusterControl non gestisce alcun modulo di sicurezza del kernel Linux come AppArmor. Quando si distribuisce un cluster PostgreSQL o TimescaleDB utilizzando ClusterControl, è possibile specificare se si desidera che ClusterControl disabiliti AppArmor durante il processo di distribuzione per ridurre il rischio di errori:

Se non vuoi disabilitarlo, cosa consigliata per la produzione ambienti, puoi utilizzare la modalità Reclamo e monitorare i log nei tuoi server per assicurarti di avere la corretta configurazione di AppArmor. Successivamente, puoi cambiarlo in Enforce seguendo le istruzioni sopra menzionate.

Puoi trovare maggiori informazioni sulla configurazione di AppArmor sul sito ufficiale di Ubuntu.