Det intressanta med systemd-sandboxning är hur snabbt teori möter drift: en kontroll måste fungera även när systemet uppdateras, felsöks och utsätts för fel. systemd kan begränsa en tjänsts filsystem, capabilities, namespaces och åtkomst till kernel-funktioner utan att applikationen behöver skrivas om.
systemd-sandboxning i praktiken
Första byggstenen: NoNewPrivileges kan hindra processen från att få nya privilegier. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: ProtectSystem och ProtectHome reducerar skriv- och läsåtkomst. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: CapabilityBoundingSet kan ta bort Linux-capabilities som tjänsten inte behöver. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: Systemd-analyze security ger en startpunkt men ersätter inte funktionstest. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Så skulle jag testa det i en riktig miljö
- Kartlägg vilka kataloger, sockets och capabilities tjänsten faktiskt använder.
- Lägg override-konfiguration i stället för att redigera paketets unit-fil.
- Aktivera begränsningar stegvis.
- Läs journalen när en skyddsmekanism blockerar legitim funktion.
- Dokumentera nödvändiga undantag.
För systemd-sandboxning håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Praktiskt exempel
En enkel intern webbtjänst behöver kanske läsa sin konfiguration, skriva i en enda datafolder och binda en port. Då kan resten av filsystemet göras read-only och capabilities reduceras till just det som krävs.
Misstag som skapar falsk trygghet
- Att slå på många skydd samtidigt och sedan inte veta vilken som bröt tjänsten.
- Att ge bred WritePaths när en enda katalog räcker.
- Att behandla ett högt automatiskt score som garanti för säkerhet.
Verifiering före stängning
För systemd-sandboxning vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Tjänsten startar och klarar sitt normala arbetsflöde.
- Nekade operationer syns och kan förklaras.
- Unit-overrides finns kvar efter paketuppdatering.
Ett negativt test hör också till systemd-sandboxning: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
systemd-sandboxning – minska vad en Linux-tjänst får göra handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.