SELinux vs. AppArmor – En sammenligning af sikkerhedskoncepter til moderne Linux-servere

SELinux AppArmor bestemmer på moderne Linux-servere, hvor strengt processer må fungere, selv når de får root-rettigheder. Jeg viser de praktiske forskelle mellem labelbaseret og sti-baseret adgangskontrol og vurderer deres nytte for containere, Server-sikkerhedsforstærkning og overholdelse.

Centrale punkter

• MAC-princippet: Begge begrænser processer ud over Unix-rettighederne.
• Model: SELinux bruger mærker, AppArmor bruger stier.
• Container: SELinux adskiller containere mere præcist via MCS.
• Operation: AppArmor anses for at være lettere at håndtere.
• Brug: Valget følger ofte distributionen.

SELinux og AppArmor kort forklaret

Jeg stoler på Obligatorisk Adgangskontrol, når jeg sikrer Linux-servere. SELinux udvider kernen med en mærkebaseret model, der tildeler processer, filer, sockets og porte sikkerhedskontekster. En global politik fastlægger, hvilke typer der må interagere, og hvilke adgange der strengt blokeres. AppArmor følger et profil- og sti-baseret koncept, der for hver applikation tillader, hvilke stier, funktioner og grænseflader der må benyttes. Begge supplerer klassiske DAC-rettigheder, så kompromitterede processer kun kan Godkendte udføre, og det lykkes ikke at bevæge sig sidelæns.

Sikkerhedsmodel: Etiketter vs. stier

Jeg vurderer først sikkerhedsmodellen, fordi den er afgørende for vedligeholdelsen og minimerer fejl. SELinux knytter regler til labels, som følger med filen og derfor forbliver konsistente, når der flyttes rundt i filsystemet. AppArmor knytter regler til stier, hvilket er meget håndgribeligt, men kræver efterfølgende vedligeholdelse ved omdøbninger. Den labelbaserede tilgang virker systemcentreret, mens den stibaserede er mere applikationscentreret og tæt på administratorernes værktøjskasse. Begge tilgange kontrollerer den samme virkelighed, men de strukturerer Politik er mere varierede og kræver forskellige arbejdsmetoder, som jeg vælger afhængigt af teamets modenhed.

Aspekt	SELinux	AppArmor
Kontrolmodel	Mærke-/typebaseret (Type Enforcement)	Stibaseret/profilbaseret alt efter applikation
Politikkens rækkevidde	Globale, systemomfattende regler	Proces- og anvendelsesrelaterede profiler
Flyt fil	Mærket bevares	Stien skal eventuelt justeres
MLS/MCS	Tilgængelig (fin opdeling)	Ikke tilgængelig
Isolering af containere	Afskærmning mellem værts- og container-systemer	Primær værtsafskærmning
Adgang	En stejlere indlæringskurve	Hurtigere at anvende

Kompleksitet og brugervenlighed

Jeg planlægger implementeringen ud fra teamets kompetencer og virksomhedens fejltolerance. SELinux tilbyder en enorm detaljeringsgrad, men kræver til gengæld en god forståelse af typer, roller og domæner samt solide diagnosticeringsværktøjer. Det globale overblik øger konsistensen, men fejlregler kan have indvirkning på mange tjenester og skal afhjælpes på en struktureret måde. AppArmor giver mig en blød start, da jeg skriver profiler for hver enkelt tjeneste og målrettet tildeler overtrædelser til netop denne tjeneste. Denne gennemsigtighed mindsker frustrationen og giver mig mulighed for at foretage ændringer hurtigt og med Oversigt sætte i produktion.

Trusselsmodel og typiske scenarier

Jeg træffer beslutninger på baggrund af de konkrete risici, jeg tager fat på. Begge MAC-mekanismer medfører en vedvarende reduktion:

• RCE-følgeskader: En kapret webproces læser ikke automatisk vilkårlige nøgler eller konfigurationsfiler.
• Privilegieskalering: Selv med root-rettigheder forhindrer sikkerhedspolitikker uautoriseret adgang til følsomme ressourcer.
• Sidelæns bevægelse: Processer har ikke adgang til tilstødende datamængder, sockets eller enheder.
• Exfiltration: Ulovlige fil- og netværksstier blokeres eller logges på et tidligt tidspunkt.
• Risici i forsyningskæden: Fremmede eller opdaterede binærfiler forbliver inden for rammerne af de definerede rettigheder.

Jeg definerer disse risici på forhånd, da de bestemmer profilernes præcision, logningens dybde og min Accept af indledende falske alarmer.

Politikobjekter, booleske værdier og profiler

I forbindelse med SELinux bruger jeg den etablerede Typehåndhævelse med moduler, som jeg udruller som pakker med versionsnumre. Booleske variabler giver mig mulighed for sikkert at aktivere eller deaktivere funktioner (f.eks. om en HTTP-server må oprette netværksforbindelser) uden at skulle lave en fork af modulet. Valget mellem målrettet og MLS/MCS-Politikkerne er baseret på compliance- og kundekrav. I AppArmor arbejder jeg med klare, procesrelaterede profiler, der nøje styrer filstier, kapaciteter samt netværks- og DBus-adgang. Til dynamiske stier bruger jeg jokertegn eller abstrakte mapper og holder profilerne modulære, så opdateringer vedligeholdelig forbliver.

Funktioner: MLS/MCS og containere

Når det gælder moderne arbejdsbelastninger, lægger jeg vægt på klientadskillelse og containerisolering. SELinux indeholder MLS og MCS, dvs. sikkerhedsniveauer og kategorier, der strengt regulerer informationsstrømme og automatisk adskiller containere med entydige mærker. Dermed begrænser jeg rækkevidden af kompromitterede containere og holder dataene adskilt fra hinanden. AppArmor beskytter primært værten mod containere, mens en klar adskillelse mellem containerne indbyrdes kræver yderligere foranstaltninger. Til strenge compliance-krav satser jeg derfor på SELinux og bruger MCS til at Klienter at isolere pålideligt.

Distributioner og typiske anvendelsesområder

Jeg træffer ofte mine valg ud fra distributionen, fordi økosystemet og værktøjerne der fungerer bedst sammen. I RHEL-, CentOS- og Fedora-miljøer kører SELinux ofte som standard og udgør en bærende sikkerhedslinje i systemdesignet. Ubuntu, Debian og SUSE leverer AppArmor-profiler til udbredte tjenester, hvilket gør det muligt for mig hurtigt at aktivere beskyttelse og komme i gang. Hvis jeg har brug for mere grundlæggende sikkerhed, kombinerer jeg MAC-valget med Kernel-hærdning, for yderligere at mindske angrebsfladerne. På den måde skaber jeg en harmonisk kombination af distribution, MAC-mekanisme og Hærdning uden afbrydelser i hverdagen.

Integration af containere og orkestratorer

Jeg integrerer konsekvent MAC i kørselsmiljøer, så sikkerhedsgarantierne også gælder i forbindelse med orkestrering. Container-runtimes overholder AppArmor-profiler og SELinux-labels; via security-opts Jeg tildeler profiler/labels målrettet til hver enkelt container. I Kubernetes administrerer jeg profiler og kontekster som en del af manifesterne eller via relevante annoteringer/indstillinger, så deploymenter forbliver reproducerbare og kontrollerbare. Vigtigt: Volumes og HostMounts skal være korrekt mærket eller inkluderet i profiler, ellers mislykkes containerne ved opstart. Min regel lyder: Implementering og politik skal versioneres, testes og implementeres samlet, så skalering og rollbacks forbliver sikre.

Håndtering af retningslinjer i hverdagen

Jeg arbejder trin for trin, fordi ændringer, der sker trin for trin, forbliver overskuelige. Med SELinux bruger jeg den permissive tilstand og anvender værktøjer som audit2allow til målrettet at udlede legitime tilladelser ud fra logfiler. Derefter overfører jeg de godkendte regler til versionsstyring og implementerer dem på en reproducerbar måde. Med AppArmor starter jeg ofte i »complain«-tilstand, indtil en profil dækker den faktiske brug, og skifter derefter til »enforce«. Denne fremgangsmåde skåner Tilgængelighed af tjenester og forhindrer uventede hændelser under vedligeholdelsesvinduer.

Hyppige snublesten og anti-mønstre

• Blind deaktivering: Jeg løser ikke problemer med politikker ved at deaktivere MAC; jeg finder årsagen i loggen og foretager målrettede justeringer.
• Forkerte filkontekster: I SELinux bevares mærkerne, når filer flyttes, men ikke ved forkert gendannelse. Jeg bruger rene installationer og relabel-rutiner.
• For brede jokertegn: I AppArmor svækker for generøse pladsholdere beskyttelsen. Jeg starter med stramme indstillinger og udvider kun det, som telemetrien bekræfter.
• Drift: Manuelle ændringer i nødsituationer uden at blive overført til Git fører til inkonsekvenser. Jeg mener, at retningslinjerne deklarativ og automatiseret.
• Blanding af LSM'er: Jeg kombinerer ikke SELinux og AppArmor på samme vært; i praksis bruger jeg en primær MAC-mekanisme samt supplerende LSM'er som Yama/Lockdown, hvis disse understøttes.
• Midlertidige stier: /tmp, runtime-sockets og dynamiske mapper planlægger jeg tidligt, ellers mislykkes opgraderinger eller blue-green-udrulninger.

Ydeevne og fejltolerance

Jeg tjekker først, om MAC bremser min gennemstrømning eller forsinker opstarten af kritiske tjenester. I praksis ser jeg næsten ingen målbare tab, når konfigurationen er korrekt, fordi kernel-kontrollerne fungerer effektivt. Det er vigtigere, at for strenge regler kan blokere opstarten eller funktionen af enkelte tjenester, indtil jeg har justeret dem. Derfor er ordentlig logning, tydelig ændringsstyring og velovervejet implementering absolut nødvendige punkter på dagsordenen. På den måde opretholder jeg et højt sikkerhedsniveau og Risici operativt lille, uden at det bremser platformen.

Serverhærdning i et netværk

Jeg kombinerer MAC med netværksfiltre, SSH-sikkerhedsforstærkning og procesbegrænsninger, så fejl ikke eskalerer. Namespaces og cgroups organiserer arbejdsbelastninger og begrænser ressourcer, mens MAC forbyder alt, hvad der ikke udtrykkeligt er tilladt. For at opnå en tydeligere adskillelse af klienter i containere benytter jeg MCS under SELinux og supplerer med passende værtsregler. Som vejledning bruger jeg Navneområder og cgroups, for at opbygge lagene på en ensartet måde. Denne lagdeling holder angribere i snævre Beskyttelsesskinner, selvom enkelte beskyttelsesringe svigter.

Overholdelse af regler og revision

Jeg integrerer MAC med revisionsstrategier for at opfylde kravene på en målbar måde. SELinux og AppArmor leverer præcise hændelser, som jeg indsamler centralt og sammenholder med oplysninger om ændringer. Til interne og eksterne revisioner dokumenterer jeg:

• Dækning i henhold til forsikringsbetingelserne: Hvilke tjenester kører i Enforce-tilstand, og hvilke undtagelser er der?
• Ændringshistorik: Hvem har ændret hvilken regel, hvornår og i forbindelse med hvilken gennemgang?
• Alarmveje: Hvilke MAC-begivenheder er spændende, hvem reagerer, og hvordan er Gennemsnitlig tid til afhjælpning?
• Adskillelse af klienter: Hvilke MCS-kategorier (SELinux) er tildelt, og hvordan administreres de?

På den måde dokumenterer jeg tekniske foranstaltninger i forhold til compliance-rammerne og opbevarer dokumentation testbar før.

Vejledning: Hvilket valg passer bedst?

Først afklarer jeg compliance-mål, teamets kompetencer og driftsrisici, før jeg lægger kursen. Hvis miljøet kræver MLS/MCS, finmasket containerisolering og en ensartet systempolitik, taler meget for SELinux. Hvis jeg lægger vægt på hurtig implementering, gennemsigtige profiler og klar tildeling pr. tjeneste, kommer AppArmor til sin ret. I hybride miljøer anvender jeg distributionens indbyggede system og supplerer det forsigtigt med egne regler. Når det gælder applikationsisolering, kan det som supplement være værd at kigge på Procesisolering, for at indskrænke privilegierne endnu mere opsummere.

Praktiske scenarier: hurtig indplacering

• VM'er med én lejer: AppArmor er ofte tilstrækkeligt, hurtig implementering, klare profiler for hver tjeneste.
• Multi-tenant-host med containere: SELinux med MCS for en klar adskillelse mellem containere og data.
• Legacy-monolit: AppArmor som mellemtrin, senere overgang til SELinux, når teamet bliver mere modent.
• Et strengt reguleret miljø: SELinux med streng politik, minimale booleske værdier, audit indstillet til „Bloker først, tillad derefter“.
• Edge/Embedded: Strømlinede AppArmor-profiler, minimal overhead, streng kontrol af de få tjenesters adgangsveje.

Mini-casestudie: Sikker implementering af web-stack

Jeg implementerer NGINX, PHP-FPM og en scheduler på en gæsteplatform. Først aktiverer jeg MAC i klage/tolerant-tilstand og lad trafikken køre i realtid. Derefter:

• Gennemgang af begivenheder: Jeg filtrerer auditlogfilerne efter disse tjenester, fjerner åbenlyse fejlagtige adgangsforespørgsler og fortolker de resterende hændelser.
• Udarbejdelse af regler: Til SELinux genererer jeg målrettede »Allows« og samler dem i et modul; til AppArmor finjusterer jeg profilerne med cache-, upload- og midlertidige stier.
• Revalidering: Belastningstestene undersøger opstart, rullende opdateringer og fejlforløb (f.eks. logrotation, fornyelse af certifikater).
• Overgang til Enforce: Jeg aktiverer Enforce gradvist (Canary) og overvåger målinger og afvigelser i logfilerne.
• Betjening: Retningslinjer indgår i CI/CD, ændringer gennemgår reviews og pre-production-tests. Jeg definerer en Nødglas-Procedure for reelle nødsituationer med streng opfølgning.

Gode eksempler fra praksis

Jeg sætter aldrig MAC i gang i blinde, men observerer først. Logfiler viser den faktiske anvendelse, og ud fra dem udarbejder jeg minimale godkendelser og dokumenterer tilpasningerne fuldstændigt. Jeg integrerer politikker og profiler i CI/CD for at levere ændringer på en måde, der kan kontrolleres og gentages. Overvågningen korrelerer MAC-hændelser med andre signaler og synliggør afvigelser. Denne cyklus af observation, tilpasning og kontrol sikrer, at kvalitet højt og udfylder hullerne gradvist.

Resumé og indplacering

Jeg bruger SELinux, når jeg har brug for finjusteret adskillelse, MCS til containere og en ensartet systempolitik. Jeg vælger AppArmor, når hurtig implementering, letforståelige profiler og klar fejlanalyse er i fokus. Begge systemer styrker Linux-servere betydeligt ud over de klassiske filrettigheder og begrænser omfanget af vellykkede angreb. Det afgørende er fortsat en konsekvent vedligeholdelse af reglerne samt integrationen i firewalls, isolationsmekanismer og logning. På den måde opnår jeg en høj sikkerhedsgevinst med en overskuelig indsats og holder samtidig driften kontrollerbar.