Seccomp: hoe Linux programma's aan een kort lijntje houdt
Stel je een hotel voor waar gasten normaal gesproken vrij door het hele gebouw mogen lopen: de keuken in, de serverruimte in, zelfs de brandtrap op het dak. Dat klinkt onhandig, want een kwaadwillende gast zou dan zomaar bij de kluis of de elektriciteitskast kunnen komen. Bij seccomp (kort voor "secure computing mode") krijgt elke gast in plaats daarvan een portier toegewezen die exact bijhoudt welke deuren hij mag gebruiken. Vraagt de gast om een deur te openen die niet op zijn lijstje staat, dan wordt dat geweigerd of meldt de portier het incident.
In computertermen is seccomp een beveiligingsfunctie van de Linux-kernel, het besturingssysteem dat draait op vrijwel alle servers, de meeste smartphones (via Android) en een groot deel van de cloud. Programma's praten met de kernel via zogeheten systeemaanroepen (system calls): korte verzoeken om bijvoorbeeld een bestand te openen, geheugen te reserveren of een netwerkverbinding te maken. Seccomp maakt het mogelijk om per programma vast te leggen welke van die honderden mogelijke verzoeken zijn toegestaan. Een simpel programma dat alleen tekst hoeft te verwerken, krijgt dan geen toestemming om plotseling netwerkverbindingen op te zetten, ook niet als het door een bug of aanval daartoe wordt gedwongen.
Wat is het precies?
Om te snappen wat seccomp doet, helpt het om eerst te weten hoe een programma met de Linux-kernel praat. Elk programma draait in zogeheten gebruikersmodus (user space), een afgeschermd deel van het geheugen. Voor alles wat met de buitenwereld te maken heeft, zoals bestanden lezen, geheugen aanvragen of een netwerkpakket versturen, moet het programma een systeemaanroep doen: een verzoek aan de kernel, die wel volledige toegang tot de hardware heeft. Linux kent inmiddels ruim vierhonderd van dit soort aanroepen.
De eerste, simpele versie van seccomp verscheen in 2005 in de Linux-kernel, bedacht door ontwikkelaar Andrea Arcangeli. Die versie, nu "strict mode" genoemd, was extreem streng: een programma dat seccomp inschakelde, mocht daarna nog maar vier systeemaanroepen gebruiken (lezen, schrijven, afsluiten en teruggaan van een signaal-afhandelaar). Dat was veilig, maar voor de meeste programma's ook onbruikbaar beperkt.
De doorbraak kwam in 2012, toen Google-ontwikkelaar Will Drewry "seccomp-bpf" toevoegde aan de kernel. BPF staat voor Berkeley Packet Filter, een klein, snel programmeertaaltje dat oorspronkelijk bedacht was om netwerkverkeer te filteren. Met seccomp-bpf kan een programma een filter meegeven dat per systeemaanroep beslist: toestaan, weigeren, een fout teruggeven, of het programma direct laten crashen. Dat filter kan ook naar de argumenten van een aanroep kijken, bijvoorbeeld om een bestand alleen te mogen openen om te lezen en niet om te schrijven.
In de praktijk schrijven ontwikkelaars zelden zo'n BPF-filter met de hand. Ze gebruiken meestal een hulpbibliotheek als libseccomp, die een simpele lijst van toegestane systeemaanroepen omzet in het onderliggende filterprogramma. Zodra het filter actief is, controleert de kernel bij elke systeemaanroep of die is toegestaan, nog voordat de aanroep zelf wordt uitgevoerd. Een belangrijk kenmerk is dat een proces zijn eigen filter nooit meer kan verruimen: eenmaal ingesteld, kan de regelset alleen strenger worden, nooit soepeler.
Wat wil men ermee bereiken?
Het achterliggende idee heet "least privilege": geef software niet meer rechten dan strikt nodig is om haar werk te doen. Veel beveiligingsproblemen ontstaan doordat een aanvaller een fout in een programma misbruikt, bijvoorbeeld een bug in een PDF-lezer of een webbrowser, om vervolgens willekeurige code uit te voeren. Zonder extra maatregelen heeft die code dan dezelfde rechten als het programma zelf, en kan de aanvaller bestanden lezen, netwerkverbindingen opzetten of proberen verder de machine over te nemen.
Seccomp beperkt de schade die zo'n aanvaller kan aanrichten. Zelfs als een aanvaller code in een proces weet te injecteren, botst die code tegen de muur van het seccomp-filter zodra ze iets probeert wat niet op de toegestane lijst staat. Dit heet in de beveiligingswereld "defense in depth": geen enkele laag hoeft perfect te zijn, zolang er meerdere lagen zijn die een aanval kunnen stoppen.
Een tweede doel is het beperken van het zogeheten aanvalsoppervlak van de kernel zelf. De Linux-kernel is enorm en bevat, zoals elke grote hoeveelheid code, bugs. Sommige van die bugs zitten in zelden gebruikte systeemaanroepen. Door een programma bij voorbaat de toegang tot die zeldzame aanroepen te ontzeggen, wordt voorkomen dat een aanvaller ze kan gebruiken om een kwetsbaarheid in de kernel te misbruiken en zo bijvoorbeeld uit een sandbox of container te ontsnappen.
Voorbeelden uit de praktijk
Google Chrome was een van de eerste grote toepassingen die seccomp-bpf gebruikte, vanaf de introductie in kernel 3.5 in 2012. Chrome splitst het weergeven van webpagina's op in aparte processen ("renderers") die met een streng seccomp-filter zijn afgeschermd. Mocht een kwaadwillende website een lek in de renderer weten te misbruiken, dan kan die renderer alsnog vrijwel niets met het besturingssysteem doen.
Docker, het populaire platform voor software-containers, activeert sinds versie 1.10 uit 2016 standaard een seccomp-profiel voor elke container. Dat standaardprofiel blokkeert ongeveer veertig van de ruim vierhonderd systeemaanroepen, waaronder aanroepen die te maken hebben met het herconfigureren van de kernel of het aanmaken van nieuwe naamruimtes, iets wat een container normaal niet nodig heeft.
Kubernetes, het systeem waarmee bedrijven containers op grote schaal beheren, kreeg in versie 1.19 uit 2020 volwaardige ("GA") ondersteuning voor seccomp-profielen per workload. Beheerders kunnen sindsdien per toepassing een profiel als "RuntimeDefault" instellen, of een eigen, nog strengere lijst opgeven.
Ook systemd, het initsysteem dat op de meeste Linux-distributies draait, biedt via de optie SystemCallFilter een simpele manier om seccomp te gebruiken voor systeemdiensten. Een beheerder kan zo met een paar regels in een configuratiebestand een dienst als een webserver of database beperken tot precies de systeemaanroepen die ze nodig heeft.
Een ouder maar invloedrijk voorbeeld is OpenSSH, dat al sinds het begin van de jaren 2010 gebruikmaakt van "privilege separation" en, op Linux, van seccomp om het proces dat inloggegevens verwerkt zoveel mogelijk af te schermen van de rest van het systeem.
Hoe ver is de techniek?
Seccomp-bpf is inmiddels veertien jaar oud en geldt als volwassen en stabiele kernelfunctionaliteit. Het wordt actief onderhouden binnen de Linux-kernel en is standaard beschikbaar op praktisch elke moderne Linux-distributie. De grootste ontwikkeling van de afgelopen jaren zit niet zozeer in seccomp zelf, maar in de gereedschappen eromheen: standaardprofielen in containersystemen, betere integratie in orkestratiesoftware als Kubernetes, en bibliotheken die het schrijven van filters makkelijker maken.
Er zijn ook duidelijke beperkingen. Het opstellen van een goed filter vereist dat ontwikkelaars precies weten welke systeemaanroepen hun programma nodig heeft, wat in de praktijk lastig is voor grote, complexe software. Een filter dat te streng is, laat de toepassing crashen; een filter dat te soepel is, biedt weinig extra bescherming. Daarnaast verschillen de nummers van systeemaanroepen per hardware-architectuur (bijvoorbeeld tussen x86 en ARM), wat het schrijven van overdraagbare filters bemoeilijkt.
Onderzoekers wijzen er verder op dat seccomp geen wondermiddel is: het beschermt niet tegen aanvallen die volledig binnen de toegestane systeemaanroepen blijven, en biedt geen bescherming tegen kwetsbaarheden op applicatieniveau zelf. Het wordt daarom vrijwel altijd gecombineerd met andere technieken, zoals Linux-naamruimtes (namespaces), capabilities (fijnmazige rechten in plaats van alles-of-niets root-toegang) en mandatory access control-systemen als SELinux of AppArmor. Een recentere, verwante ontwikkeling is gVisor van Google, dat systeemaanroepen niet filtert maar volledig laat afhandelen door een eigen, in gebruikersmodus draaiende kernelvervanger, voor nog sterkere isolatie ten koste van meer overhead.
Wie werken eraan?
De kern van seccomp wordt onderhouden binnen het Linux-kernelproject zelf, met bijdragen van ontwikkelaars bij uiteenlopende bedrijven die met Linux werken. Google speelde een sleutelrol bij de ontwikkeling van seccomp-bpf en gebruikt de techniek intensief in Chrome, ChromeOS en Android. Het bedrijf ontwikkelt daarnaast gVisor als aanvullende isolatietechniek voor zijn cloudplatform.
Docker Inc. en de bredere containergemeenschap, waaronder het Open Container Initiative (OCI) dat gezamenlijke standaarden voor containerruntimes opstelt, onderhouden de standaard seccomp-profielen die worden gebruikt door runtimes als runc en containerd. De Kubernetes-gemeenschap, gecoördineerd via de Cloud Native Computing Foundation, bouwt hierop voort met profielbeheer op clusterniveau.
Het project libseccomp, dat de veelgebruikte programmeerinterface voor seccomp-filters levert, wordt onderhouden door een kleine groep kernel- en beveiligingsontwikkelaars en wordt onder meer gebruikt door Docker, systemd, Podman en Flatpak. Verder dragen distributiemakers zoals Red Hat, Canonical (Ubuntu) en SUSE bij aan het inbouwen en documenteren van seccomp-ondersteuning in hun systemen, en publiceert internationaal beveiligingsonderzoek regelmatig over de sterktes en zwaktes van sandboxing-technieken zoals seccomp.