Säkerhet är ett måste för alla system för att skydda dina data så mycket som möjligt. Även när det alltid finns en risk att bli hackad, kommer att följa en säkerhetschecklista att minska denna risk avsevärt. En grundläggande säkerhetschecklista inkluderar en brandväggskonfiguration, datakryptering, autentiseringspolicy, etc. Ett annat viktigt verktyg för att skydda dina data på Debian-baserade operativsystem är AppArmor. I den här bloggen kommer vi att se vad som är och hur man konfigurerar det för PostgreSQL- och TimescaleDB-databaser.
Vad är AppArmor?
AppArmor, som ingår som standard i operativsystemen Ubuntu och Debian (bland annat), är ett obligatoriskt åtkomstkontrollsystem (MAC) för att begränsa program till en begränsad uppsättning resurser. Det fungerar med profiler som laddas in i kärnan. Dessa profiler kan konfigureras i två lägen:
-
Tillämpning:Profilerna som laddas i det här läget kommer att tillämpa policyn som definieras i profilen och rapportera policyöverträdelser försök.
-
Klaga:Profilerna i det här läget upprätthåller inte policy utan rapporterar istället försök till policyöverträdelse.
AppArmor tillåter också blandning av profiler för verkställighet och klagomål.
Hur man konfigurerar AppArmor
AppArmor-profilerna finns i /etc/apparmor.d/. Du kan skapa dina egna profiler och flytta dem dit eller kolla AppArmor-förrådet. Låt oss se hur du skapar en ny AppArmor-profil.
Låt oss först installera de nödvändiga paketen för att hantera detta:
$ apt install apparmor-profiles apparmor-utilsOch se om AppArmor är aktiverat:
$ systemctl status apparmor.serviceeller
$ 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
...Om du kollar den nämnda sökvägen /etc/apparmor.d/ kommer du att se några grundläggande profiler som usr.sbin.tcpdump eller usr.sbin.traceroute. Låt oss nu skapa en ny profil för PostgreSQL eller TimescaleDB. För detta kan du använda den här profilen som ett exempel. Baserat på den profilen kommer vi att ersätta PostgreSQL-versionen för att vara mer specifik. I det här fallet kommer vi att använda 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,
}Lagra det i /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres. Ladda sedan den nya profilen med apparmor_parser -a:
$ cat /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres | sudo apparmor_parser -aOm du vill ändra något i den här profilen måste du ladda om den:
$ apparmor_parser -r /etc/apparmor.d/usr.lib.postgresql.13.bin.postgresDu kan tilldela klagoläge till profilen genom att använda följande kommando:
$ aa-complain /usr/lib/postgresql/13/bin/postgresDå kan du kontrollera syslog-filen i /var/log för att se om AppArmor-konfigurationen är korrekt, eller om du behöver ändra något. När det är säkert kan du ändra läget till Enforce genom att köra:
$ aa-enforce /usr/lib/postgresql/13/bin/postgresDu kan filtrera loggen och leta efter TILLÅTNA eller NEKADE åtgärder:
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=113Du kan också inaktivera profiler på detta sätt:
$ aa-disable /etc/apparmor.d/usr.lib.postgresql.13.bin.postgresOch du måste ladda om tjänsten:
$ systemctl reload apparmor.serviceOm du föredrar att inaktivera AppArmor kan du köra:
$ systemctl stop apparmor
$ systemctl disable apparmor
Detta rekommenderas naturligtvis inte för produktionsmiljöer, och du bör åtminstone hålla det igång med läget Klagomål i alla profiler, så att du kan kontrollera loggarna och leta efter oväntat beteende.
Hur man använder PostgreSQL och TimescaleDB med ClusterControl och AppArmor
ClusterControl hanterar inte några Linux-kärnsäkerhetsmoduler som AppArmor. När du distribuerar ett PostgreSQL- eller TimescaleDB-kluster genom att använda ClusterControl kan du ange om du vill att ClusterControl ska inaktivera AppArmor för dig under distributionsprocessen för att minska risken för fel:
Om du inte vill inaktivera det, vilket rekommenderas för produktion miljöer kan du använda Klagoläge och övervaka loggen på dina servrar för att se till att du har rätt AppArmor-konfiguration. Efter det kan du ändra det till Enforce enligt instruktionerna som nämns ovan.
Du kan hitta mer information om AppArmor-konfigurationen på Ubuntus officiella webbplats.