Seccomp onder Linux: toepassingen gericht beperken voor meer veiligheid

Seccomp Linux beperkt toepassingen tot precies die systeemaanroepen die ze echt nodig hebben en verkleint zo het aanvalsoppervlak van de kernel aanzienlijk. Ik maak doelgericht gebruik van dit mechanisme om containers, microservices en gevoelige diensten in een Sandbox te blokkeren zonder hun kernfuncties te belemmeren.

Centrale punten

Ik vat de belangrijkste aspecten samen voor een snel overzicht en benadruk hoe ik Seccomp in de praktijk toepas. Zo ontstaat een duidelijke inleiding tot beleidsregels, filters en workload-beveiliging. Deze punten dienen voor mij als rode draad bij de planning, het beheer en de controle. Ze helpen bij het prioriteren van risico’s en het kiezen van degelijke standaardinstellingen. Met deze kernpunten in het achterhoofd blijft de Beveiliging begrijpelijk en beheersbaar.

• Filtermodus: BPF-profielen met fijne granulariteit staan alleen de benodigde syscalls toe.
• Aanvalsoppervlak: Minder toegankelijke kernelpaden verlagen het risico op misbruik.
• Container: Standaardprofielen blokkeren risicovolle oproepen op betrouwbare wijze.
• Kubernetes: seccompProfile en seccompDefault zorgen voor een uniforme beveiliging.
• Werkstroom: Analyseren, profileren, harden, testen, uitrollen.

Ik analyseer elke workload, stel een geschikt profiel vast en controleer het effect daarvan in de praktijk. Zo ontstaat een robuust Basislijn-bescherming die later gericht kan worden uitgebreid.

Seccomp in het kort: Secure Computing Mode

Seccomp staat voor „Secure Computing Mode“ en beperkt Syscalls van een proces tot een duidelijk gedefinieerde verzameling. Ik pas het filter toe op de punten waar applicaties de kernel aanspreken, bijvoorbeeld bij het openen van bestanden, sockets of bij het starten van nieuwe processen. Het idee is simpel: toestaan wat nodig is, en het ongewenste via een foutcode of een kill tegenhouden. Wie de interactie met de kernel begrijpt, bouwt snel solide profielen; een goed begin is het artikel Systeemaanroepen begrijpen. Zo ontstaat een doeltreffende Sandbox, waardoor uitbraken worden bemoeilijkt en ongewenste kernelpaden worden afgesloten.

Waarom Seccomp Linux het aanvalsoppervlak verkleint

Elke extra systeemaanroep verhoogt mogelijk de Aanvalsoppervlak. Ik beperk dit gebied door alleen die syscalls vrij te geven waarvan aantoonbaar is dat de applicatie ze gebruikt. Hierdoor verliezen veel exploitketens de toegang tot kritieke kernel-functies. Zelfs bij het uitvoeren van code binnen het proces stuit een aanvaller vaak op gesloten deuren. Zo voorkom ik dat gevoelige subsystemen worden bereikt, zoals ptrace, BPF of bepaalde debug-interfaces.

Een toelatingslijst in plaats van een blokkeerlijst: de juiste strategie

In productieve omgevingen vertrouw ik op Toegangslijst: De standaardactie is „verbieden“, en alleen een zorgvuldig geselecteerde reeks syscalls wordt toegestaan. Veel runtimes leveren om compatibiliteitsredenen blokkeerlijstprofielen die alleen bijzonder risicovolle aanroepen blokkeren. Voor gevoelige diensten trek ik de teugels strakker aan en sta ik alleen toe wat de runtime-analyse daadwerkelijk aantoont. Dit vermindert verrassingen bij kernelwijzigingen en verschuift de focus van „Wat is gevaarlijk?“ naar „Wat is noodzakelijk?“. Voor generieke workloads kan een solide blokkeerlijst een goed begin zijn, maar bij gateways, betalingsstromen of authenticatiediensten loont het de moeite om over te stappen op een toelatingslijstbeleid met expliciete uitzonderingen.

Modussen en filterlogica: strikt tot BPF

Seccomp kent een strikte modus, waarin alleen read, write, exit en sigreturn zijn toegestaan, en de zeer flexibele Filtermodus via BPF. In de praktijk maak ik bijna altijd gebruik van filters, omdat ik daarmee syscalls en hun argumenten nauwkeurig kan analyseren. De kernel toetst elke aanroep aan het opgeslagen programma en beslist of deze is toegestaan, een foutmelding geeft of het proces beëindigt. Zo kan ik afzonderlijke varianten van een syscall blokkeren, bijvoorbeeld specifieke vlaggen van `clone` of `unshare`. Deze granulariteit zorgt ervoor dat Beleid slanke en doeltreffende oplossing.

Terugnameacties en controle-intensiteit

Ik stuur het gedrag bij overtredingen doelgericht aan door middel van acties: toestaan, gedefinieerde fouten (meestal EPERM of EACCES) teruggeven, via TRAP een signaal activeren, met TRACE Debugging mogelijk maken, of het proces/de thread consequent beëindigen. Het louter retourneren van een foutcode is vaak voldoende en verbetert de fouttolerantie; voor bijzonder gevoelige paden maak ik daarentegen gebruik van kill-acties. Waar ik diagnose nodig heb, maak ik gebruik van de logboekfunctie van de kernel of acties met logboekregistratie om het profiel in staging-omgevingen stapsgewijs te verfijnen, zonder de bedrijfsvoering onnodig te verstoren.

Sandboxing en containerbeveiliging in de praktijk

Container-runtimes bieden beproefde Standaard-profielen die risicovolle syscalls blokkeren. Ik bouw hierop voort en beperk mount, unshare, bpf, ptrace, keyctl en perf_event_open nog verder. Toepassingen die onbetrouwbare invoer verwerken, profiteren hier dubbel van: minder kernel-interface en een duidelijke foutmelding bij overtredingen. Zelfs webbrowsers en sandbox-tools maken gebruik van deze scheiding tussen noodzakelijke en gevaarlijke toegang. Zo blijft het runtime-systeem overzichtelijk en voorspelbaar.

Melding in de gebruikersruimte: gecontroleerde uitzonderingen

Voor zeldzame, maar gerechtvaardigde uitzonderingen gebruik ik de User-Space-Notifier-Aanpak: Een toezichthoudend proces ontvangt verzoeken met betrekking tot geblokkeerde syscalls en kan deze gericht goedkeuren of afwijzen. Op deze manier pas ik broker-patronen toe, bijvoorbeeld om alleen bepaalde mount-Bewerkingen in bepaalde mappen toestaan. Dit vermindert de noodzaak om algemene uitzonderingen in het beleid op te nemen, terwijl de bedrijfsvoering toch flexibel blijft. Belangrijk hierbij is een duidelijke governance: welke commando’s mogen worden uitgevoerd, hoe worden ze gecontroleerd en hoe voorkom ik dat de Notifier zelf een single point of failure wordt?

Seccomp in Kubernetes en OpenShift

In Kubernetes stel ik in het pod-manifest via de SecurityContext in welk profiel actief is. seccompDefault op het knooppunt zorgt ervoor dat workloads zonder eigen instelling direct een zinvol Standaard-profiel ontvangen. OpenShift en Podman integreren dit ook, inclusief overdracht via –security-opt. Ik kan profielen centraal beschikbaar stellen en deze via annotaties of veldkoppelingen toepassen. Op deze manier leg ik duidelijke regels vast voor alle Naamruimten weg.

Beleidsontwerp voor teams en platforms

Ik structureer profielen op basis van Workload-klassen in plaats van per team: web-frontends, workers, DB-clients, datapijplijnen. Elke klasse krijgt een getest profiel, dat ik slechts minimaal aanpas voor speciale gevallen. In Kubernetes zorg ik via een toelatingsbeleid ervoor dat pods ten minste RuntimeDefault gebruiken, terwijl bijzonder gevoelige naamruimten een strikte Localhost-Profiel afdwingen. Voor debug- of incident-situaties bestaat er een duidelijk omschreven uitzonderingsprocedure met een beperkte geldigheidsduur en aanvullende beperkingen op het gebied van netwerktoegang en mogelijkheden, zodat diagnose mogelijk blijft zonder het beveiligingsniveau in het algemeen te verlagen.

Profielen opstellen: workflow van analyse tot implementatie

Ik begin met een looptijdanalyse en kijk welke Syscalls die de applicatie tijdens normaal gebruik maakt. Vervolgens stel ik een startprofiel op dat precies deze aanroepen toestaat en zeldzame paden uitsluit. Daarna scherp ik het profiel verder aan door zeldzame of risicovolle aanroepen te schrappen of strakker te definiëren. Een testfase brengt hiaten aan het licht en laat zien of er functies ontbreken of dat foutcodes zinvol zijn. Pas daarna rol ik de Beleid in productie en geef elke wijziging een versienummer.

Architecturale en ABI-aspecten

Syscalls verschillen naargelang de architectuur en de kernelgeneratie. Ik let erop dat profielen Multi-Arch volledig dekken (bijv. x86_64 en arm64) en dat nieuwere varianten zoals openat2 of time64-systeemaanroepen worden meegenomen. In containers met oudere basisbesturingssystemen controleer ik of er legacy-paden zijn (bijvoorbeeld via socketcall of bepaalde IPC-aanroepen) voorkomen. Wie libseccomp of de runtime gebruikt voor het genereren, profiteert van stabiele koppelingen tussen symboolnamen en syscall-nummers – ik gebruik bewust geen vaste nummers om de overdraagbaarheid te waarborgen. Belangrijk: filters zijn erfelijk en alleen monotoon kan worden aangescherpt; wat eenmaal verboden is, blijft verboden, ook na execve.

Upgrade- en compatibiliteitsbeheer

Bibliotheek- en kernel-updates introduceren nieuwe syscalls of wijzigen de aanroeppatronen. Ik ben daarom van plan om gerichte Rooktesten na upgrades en zorg voor een staging-omgeving die in geval van twijfel met LOG-acties. Zo zie ik wat er nieuw wordt aangevraagd voordat ik de productie vergrendel. Daarnaast documenteer ik bewust verschillen tussen images (bijv. op musl- versus op glibc-gebaseerde containers), aangezien deze verschillende paden naar de kernel-API kunnen volgen. Voor rollbacks is een duidelijke versiebeheer van de profielen cruciaal; in geval van een incident schakel ik tijdelijk over op een minder strikt beleid met een korte looptijd en intensieve monitoring.

Foutpatronen herkennen: logging en triage

Geblokkeerde syscalls moeten opspoorbaar zijn, anders tast men in het Donker. Ik schakel logging in tijdens de runtime en analyseer statistieken die pieken en uitschieters laten zien. Meldingen met EPERM of EACCES duiden vaak op te strenge regels. Onverwachte afbrekingen schrijf ik toe aan de betreffende component en controleer ik de bijbehorende vlaggen of argumenten. Vervolgens pas ik de Filters Stel het minimaal in en test het opnieuw.

Draaiboek voor probleemoplossing

• Reproduceren: precies dezelfde input/verkeer herhalen en de logbestanden met elkaar in verband brengen.
• Identificeer: de betreffende syscall met argumenten vastleggen (bijvoorbeeld via een runtime-log of audit-uitvoer).
• Prijs: Is deze aanroep nodig? Is er een variant met minder risico (bijvoorbeeld `openat` in plaats van `open`, of specifiekere vlaggen)?
• Aanpassen: minimaal toestaan, bij voorkeur met argumentfilters; standaardactie strikt laten.
• Beveiligen: voor gevoelige uitzonderingen bovendien de capaciteit verlagen, het bestandssysteem op alleen-lezen zetten of de naamruimten verder afbakenen.
• Hertest & telemetrie: na de fix gericht testen, statistieken in de gaten houden en waarschuwingen instellen.

Vergelijking met SELinux, AppArmor en Capabilities

Seccomp grijpt in op het raakvlak tussen de toepassing en de kernel, terwijl SELinux en AppArmor vooral de toegang tot objecten reguleren. Capabilities regelen bevoorrechte bewerkingen, die ik bovendien sterk beperk. Samen met Naamruimten en cgroups Zo ontstaat een meerlagig beveiligingsconcept. Ik scheid resources, beperk onnodige rechten en beperk kernelpaden via Seccomp. Deze combinatie zorgt ervoor dat workloads strak worden beheerd en gemakkelijk te controleren zijn.

Prestaties en overhead

Een goed opgebouwd Seccomp-profiel veroorzaakt slechts een geringe Overhead: De kernel controleert per syscall een klein BPF-programma. In de praktijk is dit bij gangbare web- en service-workloads nauwelijks meetbaar. Kritisch kunnen echter paden worden die zeer frequent worden uitgevoerd en veel syscalls vereisen (bijv. pakketverwerking, IPC-intensieve workers). Ik houd het aantal regels daarom beperkt, gebruik argumentfilters in plaats van lange lijsten en test hotpaths met benchmarks. Als een profiel meetbare vertraging veroorzaakt, controleer ik eerst op duplicaten, onnauwkeurige matches en of bepaalde zeldzame aanroepen naar een apart proces kunnen worden verplaatst.

Best practices voor veilige standaardinstellingen

Ik begin met het standaardprofiel van de runtime en pas dit aan, afhankelijk van Werkbelasting. Voor zeer gevoelige diensten, zoals gateways of authenticatiediensten, gelden bijzonder strenge regels. Wijzigingen aan profielen integreer ik in CI/CD en test ik automatisch. Daarnaast raad ik een sterke beperking van de capabilities aan, read-only bestandssystemen en NoNewPrivs. Een handleiding voor overkoepelende hostbeveiligingsmechanismen is te vinden op Kernel-beveiliging, dat goed te combineren is met Seccomp.

Uitgebreide uitharding: wat ik nog extra controleer

Naast de gebruikelijke verdachten (mount, ontkoppelen, bpf, ptrace, keyctl, perf_event_open) bekijk ik de volgende verzoeken en beperk ik ze, afhankelijk van de context, sterk of blokkeer ik ze volledig:

• setns: voorkomt dat er naar andere naamruimten wordt gesprongen.
• process_vm_readv/process_vm_writev: voorkomt directe toegang tot het geheugen van andere processen.
• kexec_load en reboot: beschermen tegen pogingen tot herstart of vervanging van de kernel.
• swapon/swapoff en init_module/finit_module: beperken de mechanismen voor het laden van systemen en modules.
• clone3 met risicovolle flags (bijv. naamruimten): gedetailleerd beperken via argumenten.
• io_uring_setup: afhankelijk van de werklast toestaan of strak beperken, aangezien het een krachtige interface is.

De richtlijn luidt: zoveel als nodig, zo weinig mogelijk – en liever een klein, gedocumenteerd uitzonderingspad dan een wijd open standaardregel.

Integratie in CI/CD en Teams

Ik behandel Seccomp-profielen als Code: versiebeheer, beoordeling, testen. Pipeline-taken controleren of profielen bij de image passen en of er blokkades optreden. Smoke-tests met testgegevens brengen gedragsveranderingen sneller aan het licht dan handmatig klikken. Ontwikkelaars krijgen een kort draaiboek waarin wordt uitgelegd hoe logging eruitziet en waar ze handtekeningen kunnen aanpassen. Zo komt de Beveiliging direct in de ontwikkelingsstroom en blijft actueel.

Kort samengevat

Seccomp beperkt de Syscalls een toepassing beperk ik tot het noodzakelijke en sluit daarmee veel aanvalsroutes af. Ik begin met een sterke standaardinstelling, meet het daadwerkelijke gedrag en beperk de toegang daarna stap voor stap. Containerplatforms zoals Kubernetes of OpenShift nemen veel basiswerk uit handen wanneer ik seccompDefault instel en profielen centraal distribueer. In combinatie met capabilities, SELinux/AppArmor, namespaces en cgroups ontstaat zo een effectieve meervoudige beveiliging. Wie deze aanpak consequent volgt, verlaagt het risico op kernel-exploits en houdt tegelijkertijd de workloads goed bestuurbaar.