Sikkerhed er et must for alle systemer for at beskytte dine data så meget som muligt. Selv når der altid er en risiko for at blive hacket, vil ved at følge en sikkerhedstjekliste denne risiko reduceres betydeligt. En grundlæggende sikkerhedstjekliste inkluderer en firewall-konfiguration, datakryptering, autentificeringspolitik osv. Et andet vigtigt værktøj til at beskytte dine data på Debian-baserede operativsystemer er AppArmor. I denne blog vil vi se, hvad der er, og hvordan man konfigurerer det til PostgreSQL- og TimescaleDB-databaser.
Hvad er AppArmor?
AppArmor, inkluderet som standard i Ubuntu og Debian (blandt andre) operativsystemer, er et obligatorisk adgangskontrolsystem (MAC) til at begrænse programmer til et begrænset sæt ressourcer. Det fungerer ved at bruge profiler indlæst i kernen. Disse profiler kan konfigureres i to tilstande:
-
Håndhævelse:Profilerne indlæst i denne tilstand vil håndhæve den politik, der er defineret i profilen, samt rapportere overtrædelse af politikken forsøg.
-
Klag:Profilerne i denne tilstand håndhæver ikke politik, men rapporterer i stedet forsøg på overtrædelse af politik.
AppArmor tillader også blanding af håndhævelses- og klagetilstandsprofiler.
Sådan konfigureres AppArmor
AppArmor-profilerne er i /etc/apparmor.d/. Du kan oprette dine egne profiler og flytte dem dertil eller tjekke AppArmor-lageret. Lad os se, hvordan du opretter en ny AppArmor-profil.
Lad os først installere de nødvendige pakker til at håndtere dette:
$ apt install apparmor-profiles apparmor-utils
Og se om AppArmor er aktiveret:
$ systemctl status apparmor.service
eller
$ 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
...
Hvis du tjekker den nævnte sti /etc/apparmor.d/, vil du se nogle grundlæggende profiler som usr.sbin.tcpdump eller usr.sbin.traceroute. Lad os nu oprette en ny profil til PostgreSQL eller TimescaleDB. Til dette kan du bruge denne profil som eksempel. Baseret på den profil vil vi erstatte PostgreSQL-versionen for at være mere specifik. I dette tilfælde vil vi bruge 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,
}
Gem det i /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres. Indlæs derefter den nye profil ved hjælp af apparmor_parser -a:
$ cat /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres | sudo apparmor_parser -a
Hvis du vil ændre noget på denne profil, skal du genindlæse den:
$ apparmor_parser -r /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres
Du kan tildele klagetilstanden til profilen ved at bruge følgende kommando:
$ aa-complain /usr/lib/postgresql/13/bin/postgres
Derefter kan du tjekke syslog-filen i /var/log for at se, om AppArmor-konfigurationen er korrekt, eller du skal ændre noget. Når det er sikkert, kan du ændre tilstanden til Enforce ved at køre:
$ aa-enforce /usr/lib/postgresql/13/bin/postgres
Du kan filtrere loggen på udkig efter TILLADTE eller NÆKTEDE handlinger:
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
Du kan også deaktivere profiler på denne måde:
$ aa-disable /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres
Og du bliver nødt til at genindlæse tjenesten:
$ systemctl reload apparmor.service
Hvis du foretrækker at deaktivere AppArmor, kan du køre:
$ systemctl stop apparmor
$ systemctl disable apparmor
Selvfølgelig anbefales dette ikke til produktionsmiljøer, og du bør i det mindste holde det kørende ved at bruge klagetilstanden i alle profilerne, så du kan tjekke logfilerne på udkig efter uventet adfærd.
Sådan bruger du PostgreSQL og TimescaleDB med ClusterControl og AppArmor
ClusterControl administrerer ikke nogen Linux-kernesikkerhedsmoduler som AppArmor. Når du implementerer en PostgreSQL- eller TimescaleDB-klynge ved at bruge ClusterControl, kan du angive, om du ønsker, at ClusterControl skal deaktivere AppArmor for dig under implementeringsprocessen for at reducere risikoen for fejl:
Hvis du ikke vil deaktivere det, hvilket anbefales til produktion miljøer, kan du bruge klagetilstanden og overvåge loggen på dine servere for at sikre, at du har den korrekte AppArmor-konfiguration. Derefter kan du ændre det til Enforce ved at følge instruktionerne nævnt ovenfor.
Du kan finde mere information om AppArmor-konfigurationen på Ubuntus officielle websted.