SELinux vs AppArmor: Vilket MAC-ramverk passar din server?

Både SELinux och AppArmor tillämpar Mandatory Access Control (MAC) på Linux, vilket begränsar vad processer kan göra även om de får root-behörighet. Skillnaden ligger i hur de gör det. SELinux tilldelar permanenta etiketter till varje fil och process. AppArmor använder istället regler för filvägar. Det valet av design påverkar allt annat: komplexitet, säkerhetsnivå och vilken distribution som levererar vilket verktyg som standard.

Hur SELinux fungerar

SELinux utvecklades ursprungligen av NSA och levereras som standard på RHEL, CentOS, Fedora och Rocky Linux. Det märker varje objekt i systemet, inklusive filer, processer, portar och socklar, med en säkerhetskontext i formatet user:role:type:level. Fältet type fältet sköter det mesta av arbetet genom en mekanism som kallas Type Enforcement (TE).

Till exempel körs Apache-webbservern som httpd_t. Webbinnehållsfiler har en annan typ. Om ingen policyregel uttryckligen tillåter httpd_t åtkomst till den innehållstypen nekas begäran. Detta är en modell där allt nekas som standard. Ingenting tillåts om inte en regel säger något annat.

SELinux stöder även Multi-Level Security (MLS) och Multi-Category Security (MCS), som klassificerar data efter känslighetsnivå och begränsar åtkomsten därefter. MCS är det som ger SELinux dess starka containerisolering, vilket håller containrarna åtskilda från varandra och från värden. Detta är viktigt i Kubernetes- och OpenShift-miljöer där poddar delar en nod.

Nackdelen är komplexiteten. SELinux har en brant inlärningskurva. Felsökning av åtkomstnekanden innebär att man måste läsa granskningsloggar, förstå säkerhetskontexter och ibland skapa anpassade policy-moduler med audit2allow. För team utan dedikerad säkerhetspersonal är den extra arbetsbördan påtaglig.

Hur AppArmor fungerar

AppArmor har en annan strategi. Istället för att märka objekt kopplar det säkerhetsprofiler till applikationer baserat på deras filvägar. En profil för /usr/sbin/nginx definierar vilka kataloger Nginx kan läsa, vilka portar den kan binda till och vilka funktioner den behöver. Profiler är vanliga textfiler som lagras i /etc/apparmor.d/.

AppArmor är standardramverket för MAC på Ubuntu, Debian och SUSE. Det har varit en del av Linux-kärnan sedan version 2.6.36. Applikationer utan profil faller tillbaka på standardbehörigheter för Linux DAC.

AppArmor körs i två lägen per profil: Enforce (blockerar och loggar överträdelser) och Complain (loggar överträdelser utan att blockera). Detta gör det praktiskt att rulla ut nya profiler gradvis. Börja i Complain-läge, granska loggarna, skärp profilen och växla sedan till Enforce.

Verktyg som aa-genprof och aa-logprof hjälper till att skapa profiler interaktivt genom att observera vad ett program gör och generera regler utifrån dess beteende. Jämfört med SELinux-policy-moduler är syntaxen mycket lättare att läsa och redigera manuellt.

Nackdelen är att sökvägsbaserade regler inte följer med filerna när de flyttas. En hård länk eller bind-mount kan i teorin kringgå en sökvägsbaserad begränsning. AppArmor saknar också inbyggt stöd för MLS/MCS, så det kan isolera containrar från värden men inte från varandra på samma sätt som SELinux gör.

Jämförelse sida vid sida

Grundläggande konfiguration

SELinux

Kontrollera aktuell status:

sestatus
getenforce

Starta i Permissive-läge för att logga överträdelser utan att blockera något:

setenforce 0

Använd policyn ”targeted” för de flesta servrar. Den begränsar högriskstjänster som webbservrar och databaser samtidigt som allt annat lämnas obegränsat. Gör det permanent i /etc/selinux/config:

SELINUX=enforcing
SELINUXTYPE=targeted

Kontrollera säkerhetskontexter för filer och processer:

ls -Z /var/www/html
ps -eZ | grep httpd

Om en tjänst använder en icke-standardport, uppdatera policyn:

semanage port -a -t ssh_port_t -p tcp 9999

För anpassade applikationer som genererar åtkomstnekanden, skapa en policy-modul från granskningsloggen:

ausearch -m avc -ts recent | audit2allow -M my_custom_policy
semodule -i my_custom_policy.pp

AppArmor

Kontrollera vilka profiler som är laddade:

sudo aa-status

Installera verktygspaketet om du behöver verktyg för profilhantering:

sudo apt install apparmor-utils

Skapa en profil interaktivt medan applikationen körs:

sudo aa-genprof /path/to/binary

Förfina profilen genom att skanna loggarna efter överträdelser:

sudo aa-logprof

Byt läge för en profil:

sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

Vilket ska du använda?

Det praktiska svaret för de flesta administratörer: använd det som följer med din distribution. RHEL, CentOS, Fedora och Rocky Linux levereras med SELinux. Ubuntu, Debian och SUSE levereras med AppArmor. Båda ramverken har välutvecklade verktyg och policyer för sina respektive plattformar. Att byta till ett alternativ som inte är standard på en distribution innebär extra arbete och minskar stödet från communityn.

Utöver det, låt dina krav avgöra:

• Välj SELinux om du behöver efterleva PCI DSS, HIPAA eller DISA-STIG. Om du kör containerarbetsbelastningar med flera användare på Kubernetes eller OpenShift. Om du behöver isolering mellan containrar på delade värdar. Om din miljö hanterar klassificerade eller känsliga data.
• Välj AppArmor om du kör Ubuntu eller Debian och vill ha MAC-skydd utan en brant inlärningskurva. Om din konfiguration är en enskild server eller ett litet kluster som kör standardwebbtjänster. Om snabb driftsättning är viktigare än detaljerad kontroll på etikettnivå.

Båda ramverken medför minimal extra belastning under körning. SELinux cachar åtkomstbeslut i sin Access Vector Cache. AppArmors policyinläsning kan medföra en liten fördröjning vid uppstart men har försumbar inverkan under körning. För de flesta hosting-arbetsbelastningar kommer inget av dem att utgöra en flaskhals.

Om du behöver en pålitlig hostingplattform med fullständig root-åtkomst för att konfigurera något av ramverken, ger FDC:s dedikerade servrar eller VPS dig kontrollen att ställa in SELinux eller AppArmor på det sätt som din miljö kräver.