Systemd 260: TPM2, sandboxing en nieuwe mogelijkheden in Linux

Hardwaregids » Koopgidsen » Systemd 260: TPM2, sandboxing en nieuwe mogelijkheden in Linux

Met de komst van systemd 260 zetten Linux-distributies een belangrijke stap richting een moderner en veiliger ecosysteem, gericht op cloudomgevingen, virtualisatie en automatisering. Deze versie verfijnt niet alleen details, maar introduceert ook aanzienlijke wijzigingen in het opstarten, servicebeheer, netwerken, het gebruik van TPM2 voor integriteit en encryptie, en sandboxing-mogelijkheden op schijfniveau.

Tegelijkertijd versterkt het project zijn documentatie en zijn aanpak voor het werken met kunstmatige intelligentie-agenten , waarmee duidelijk wordt dat systemd een cruciale pijler is waarop steeds meer ontwikkelings- en observatietools aansluiten. Als u Linux-systemen beheert op servers, in de cloud, op bedrijfsdesktops of in laboratoria, is het de moeite waard om al deze nieuwe functies te bekijken en te plannen voor updates en configuratieaanpassingen.

Een definitief afscheid van System V en de volledige afhankelijkheid van native schijven.

Een van de meest opvallende veranderingen in systemd 260 is de volledige verwijdering van ondersteuning voor System V-scripts . Het klassieke opstartproces op basis van /etc/init.d was al jaren uitgefaseerd, maar is nu feitelijk verdwenen uit de systemd-code.

Dit betekent dat de componenten die verantwoordelijk waren voor de verbinding tussen SysV-scripts en native units zijn verwijderd: systemd-rc-local-generator, rc-local.service, systemd-sysv-generator en systemd-sysv-install bestaan ​​niet meer. Als gevolg hiervan zal elke service die nog steeds afhankelijk is van deze verouderde mechanismen, simpelweg niet starten op systemen die systemd 260 gebruiken.

Tijdens het opschoonproces zijn verschillende Meson-buildopties als verouderd gemarkeerd of verwijderd. De vlaggen -Drc-local=, -Dsysvinit-path= en -Dsysvrcnd-path= zijn naar het archief verplaatst, terwijl andere zoals -Dintegration-tests= en -Dcryptolib= volledig zijn verwijderd. Dit geeft een duidelijke boodschap: alles moet nu worden afgehandeld door native units en de moderne systemd-infrastructuur.

Voor veel Europese infrastructuren die nog steeds afhankelijk zijn van oudere componenten, vereist deze verandering een herziening van interne services, aangepaste scripts en verouderde implementaties. Migreren naar goed gedefinieerde unit-bestanden is niet langer alleen aanbevolen; het is verplicht als u services wilt blijven draaien op distributies die systemd 260 integreren.

Hogere kernelvereisten en een focus op de huidige omgevingen.

De nieuwe versie legt de lat hoger voor de kernel: vanaf nu is de minimaal ondersteunde Linux-versie 5.10 , waarmee zeer oude versies zoals 5.4 niet meer worden ondersteund. Bovendien geeft het project aan dat gebruikers idealiter met een 5.14-kernel of hoger zouden moeten werken , en raadt met name de 6.6-serie aan om optimaal gebruik te maken van alle beschikbare functies.

Deze toename in vereisten is doorgaans geen probleem in moderne distributies, maar kan de zaken compliceren in zeer conservatieve omgevingen of ingebedde oplossingen die al jarenlang worden onderhouden. Voordat u upgradet naar systemd 260, is het raadzaam te controleren welke kernel er wordt gebruikt, met name in Europese datacenters met langdurige implementaties of aangepaste images.

Aan het andere uiteinde van het spectrum bevinden zich rolling release-distributies zoals Arch Linux of openSUSE Tumbleweed, die erg populair zijn onder gebruikers die de nieuwste functies willen. Deze distributies integreren doorgaans snel zowel nieuwe kernels als nieuwe branches van systemd. Andere distributies, zoals Fedora, handhaven een zekere mate van stabiliteit in de hoofdversie van systemd gedurende de levenscyclus van elke release, waardoor er iets meer tijd is om migraties te plannen.

TPM2, opstartintegriteit en geavanceerde SRK-ondersteuning

Een van de gebieden waarop systemd zich het meest ontwikkelt, is de integratie met TPM2 (Trusted Platform Module 2.0) . Deze chip, die steeds vaker voorkomt in moderne UEFI-moederborden en hardware uit het midden- en hogere segment, maakt het mogelijk om geheimen aan de systeemstatus te koppelen, opstartfasen te meten en versleutelde volumes automatisch te ontgrendelen wanneer de omgeving aan de verwachtingen voldoet.

Systemd 260 verbetert deze integratie verder door tools en services toe te voegen die verschillende fasen van het opstartproces bestrijken. Een belangrijk onderdeel is systemd-tpm2-setup , verantwoordelijk voor het voorbereiden van de infrastructuur rond de Storage Root Key (SRK) van de TPM . Deze root-sleutel dient als cryptografische basis voor het beveiligen van de communicatie met de chip en voor het veilig opslaan van andere geheimen.

Tijdens het opstarten worden twee fasen onderscheiden: een zeer vroege fase in de initrd en een tweede fase in het root-systeem. In de eerste fase controleert een service genaamd "Early TPM SRK Setup" of de TPM al een opgeslagen SRK heeft en, indien deze niet bestaat, maakt deze deze aan en stelt deze tijdelijk beschikbaar onder /run/systemd/tpm2-srk-public-key.* . Later, zodra het daadwerkelijke bestandssysteem is aangekoppeld, consolideert de service de SRK en controleert of de sleutel die is opgeslagen in /var/lib/systemd/tpm2-srk-public-key.pem overeenkomt met de sleutel in de TPM.

In goed geconfigureerde scenario's worden logboekvermeldingen zoals "SRK is al opgeslagen in de TPM" en berichten die aangeven dat de SRK-voetafdruk overeenkomt met de verwachte voetafdruk weergegeven. Als de omgeving echter niet correct is geconfigureerd (bijvoorbeeld in configuraties met Yocto of op boards zoals de Raspberry Pi met een SPI-gebaseerde TPM en aangepaste opstartmethoden zoals U-Boot en measured boot), kunnen er situaties ontstaan ​​waarin systemd deze bestanden niet aanmaakt onder /var/lib/systemd, waardoor twijfels ontstaan ​​over de correcte configuratie van de SRK.

Wanneer de TPM-status is gewijzigd, partities zijn aangepast of de opstartvolgorde is gewijzigd, is het bijbehorende beleid mogelijk niet langer geldig. In dergelijke gevallen raden sommige beheerders aan om de TPM-sleuf of het beleid te wissen en de sleutel opnieuw te registreren , volgens procedures die vergelijkbaar zijn met die beschreven in handleidingen voor schijfversleuteling met TPM in omgevingen zoals openSUSE. Deze handleidingen beschrijven hoe het PCR-beleid opnieuw kan worden aangemaakt en hoe de ontgrendeling van volumes opnieuw kan worden gekoppeld.

Naast de SRK is een andere praktische verbetering de introductie van een intern hulpprogramma genaamd tpm2_id in udev . Deze geïntegreerde tool wordt uitgevoerd wanneer het systeem een ​​TPM2-apparaat detecteert en extraheert automatisch de fabrikant en model-ID . Dit vereenvoudigt de inventarisatie van beveiligingshardware, wat zeer nuttig is voor overheidsinstanties, gereguleerde bedrijven of kritieke infrastructuren waar het essentieel is om precies te weten welke TPM-modules zijn ingezet.

De integratie met de opstartmeetinfrastructuur wordt verder versterkt door specifieke eenheden zoals systemd-pcrextend , die gebeurtenissen zoals "enter-initrd", "leave-initrd", "sysinit" en "ready" loggen in verschillende PCR's (bijv. PCR 11). Deze reeks extensies stelt de TPM in staat een cryptografisch verifieerbaar overzicht van het opstartproces te verzamelen, dat vervolgens kan worden gebruikt voor Trusted Boot-beleid of voor UKI (Unified Kernel Images) om de status van de machine te valideren voordat sleutels worden vrijgegeven.

Beveiligingsmaatregelen en sandboxing van services met systemd

Systemd start niet alleen processen, maar biedt ook een uitgebreide set sandboxing-richtlijnen om services te isoleren en de schade te beperken in geval van een inbreuk. Deze "verdediging in de diepte"-aanpak is gebaseerd op cgroups, namespaces, kernelmogelijkheden en systeemoproepfilters (seccomp).

Om de beveiliging van een specifieke service te beoordelen, bevat systemd de beveiligingstool systemd-analyze . Door deze tool uit te voeren, wordt een rapport gegenereerd met een blootstellingsscore op een schaal van 0 tot 10, waarbij een lagere score beter is. Het rapport geeft aan welke beveiligingen zijn in- of uitgeschakeld (netwerkisolatie, toegang tot het bestandssysteem, toegang tot apparaten, enz.), waardoor het eenvoudig is om ontbrekende instellingen te identificeren en te controleren of wijzigingen de score daadwerkelijk verbeteren.

In plaats van de originele eenheid te bewerken – wat bij toekomstige pakketupdates verloren zou gaan – is het aan te raden een nieuwe te maken. override en /etc/systemd/system/mi-servicio.service.d/ bijvoorbeeld met een bestand, sandbox.confNa de wijziging kunt u de configuratie eenvoudig opnieuw laden met systemctl daemon-reload en de service opnieuw opstarten zodat de nieuwe beperkingen van kracht worden.

Op bestandsysteemniveau is een van de belangrijkste opties: ProtectSystem=Waarden zoals strict, full o true Ze koppelen verschillende delen van de boomstructuur in alleen-lezenmodus. De gebruikelijke werkwijze is, indien mogelijk, om gebruik te maken van ProtectSystem=strictHierdoor worden /usr, /boot, /efi en /etc alleen-lezen voor de service. Als een applicatie naar specifieke mappen moet schrijven, is dat toegestaan. ReadWritePaths=/pad in eenheid.

Om de privacy verder te verbeteren, wordt ook aanbevolen de toegang tot gebruikersmappen te beperken met `ProtectHome=true` . Dit voorkomt dat de service `/home`, `/root` of `/run/user` kan lezen. Daarnaast creëert `PrivateTmp=true` geïsoleerde `/tmp` en `/var/tmp` mappen, waardoor tijdelijke bestanden niet meer zichtbaar zijn voor verschillende processen.

In apparaten zorgt `PrivateDevices=true` ervoor dat de daadwerkelijke `/dev`-structuur wordt verborgen en vervangen door een minimale set veilige pseudo-apparaten (null, zero, random, enz.). Als een schijf een specifiek apparaat nodig heeft (bijvoorbeeld een seriële poort of een schijfblok), kan dit worden verleend met `DeviceAllow=/dev/xxx rw` of in de alleen-lezenmodus.

Het netwerk is ook een belangrijke factor. Met Privénetwerk=true Er wordt een geïsoleerde netwerknaamruimte gecreëerd, waarbij alleen de loopback overblijft; de service ziet geen fysieke interfaces en kan niet communiceren met de buitenwereld. Als alternatief kunt u beperken welke adresfamilies de service kan gebruiken door RestrictAddressFamilies=alleen AF_INET en AF_INET6 toestaan ​​voor IPv4/IPv6, AF_UNIX voor lokale sockets of zelfs none om de netwerkmogelijkheden volledig te 'Japansiseren'.

Wat privileges betreft, is de `NoNewPrivileges=true` -richtlijn een van de krachtigste: deze voorkomt dat het proces nieuwe privileges verkrijgt via setuid-binaire bestanden of wijzigingen in mogelijkheden. Kortom, zelfs als de service kwetsbare code uitvoert, zou deze niet via traditionele mechanismen root-toegang moeten kunnen verkrijgen. In combinatie met `CapabilityBoundingSet=` , waarmee de exacte lijst met toegestane mogelijkheden wordt gedefinieerd (bijvoorbeeld alleen `CAP_NET_BIND_SERVICE` om te luisteren op lage poorten), wordt het aanvalsoppervlak geminimaliseerd.

Om nog een stap verder te gaan, biedt systemd de mogelijkheid om systeemoproepen te filteren met SysteemCallFilter=In plaats van een handmatige lijst met systeemaanroepen bij te houden, worden vooraf gedefinieerde groepen gebruikt, zoals @system-service, @network-io, @basic-io of groepen zoals ~@privileged. Met systemd-analyze syscall-filter Het is mogelijk om te inspecteren welke specifieke aanroepen bij elke groep horen. Dit maakt het mogelijk om een ​​zeer beperkt uitvoeringsprofiel op te stellen, vergelijkbaar met wat een speciale sandbox zou bieden.

Andere relevante instellingen zijn onder andere `ProtectKernelTunables=true` , waarmee het wijzigen van kernelparameters in `/proc/sys` en `/sys` wordt geblokkeerd; `ProtectKernelModules=true` , waarmee het laden of ontladen van modules wordt voorkomen; `ProtectKernelLogs=true` , waarmee het lezen van kernellogboeken wordt voorkomen; en `ProtectControlGroups=true` , waarmee schrijfbewerkingen naar de cgroups-hiërarchie worden geblokkeerd. Dit alles werkt naadloos samen met nieuwe mogelijkheden voor gebruikersisolatie, zoals ` PrivateUsers=full` , die in versie 260 is bijgewerkt om het volledige bereik van gebruikers-ID's in kaart te brengen, waardoor eerdere oplossingen die nodig waren voor geneste systemd-omgevingen overbodig worden.

PrivateUsers, xaccess en nieuwe toegangsbeheeropties voor apparaten

Het PrivateUsers- mechanisme , ontworpen om services in een geïsoleerde gebruikers-ID-ruimte te laten draaien, is geconsolideerd in systemd 260. De optie PrivateUsers=full koppelt nu het volledige scala aan identificatoren, wat de zaken vereenvoudigt in containers en op systemen met geneste systemd-instanties gebaseerd op oudere versies (vóór 257). Deze verbetering heeft de workarounds die voorheen werden gebruikt om deze oudere instanties te detecteren, overbodig gemaakt.

Parallel daaraan introduceerden componenten zoals systemd-logind en systemd-udevd het concept van xaccess . Dit mechanisme vormt een aanvulling op de klassieke logica van uaccess , waarmee gebruikers met actieve grafische sessies op de lokale machine toegang krijgen tot bepaalde apparaten (bijvoorbeeld audio of video). Met xaccess kunnen machtigingen worden gedelegeerd aan externe gebruikers met speciaal gemarkeerde sessies , zodat bijvoorbeeld een gebruiker die via een extern bureaublad is verbonden, toegang kan krijgen tot lokale GPU-renderingapparaten zonder brede machtigingen aan het hele systeem te hoeven verlenen.

De configuratie van deze sessies omvat omgevingsvariabelen die via PAM beschikbaar worden gesteld, met name PAMXDG_SESSION_EXTRA_DEVICE_ACCESS= , waarmee kan worden gedefinieerd welke specifieke apparaten in deze logica worden opgenomen. Deze aanpak sluit nauw aan bij de wettelijke vereisten voor naleving en gegevensbescherming van de Europese Unie, waar granulariteit en traceerbaarheid vereist zijn voor toegang tot gevoelige hardware.

mstack, systemd-mstack en nieuwe containertools

Op het gebied van containerisatie introduceert systemd 260 de volgende functionaliteit. stapelen en een bijbehorend commando, systemd-mstackHet idee achter mstack is om het mogelijk te maken een definitie te maken OverlayFS gebaseerd op de structuur van een speciale map genaamd .mstack/, dat een specifieke specificatie volgt voor het organiseren van de lagen.

De nieuwe opdrachtregeltool systemd-mstack maakt het eenvoudiger om interactief met deze bestandssysteemstacks te werken, waardoor er meer flexibiliteit ontstaat bij het opzetten van gelaagde omgevingen voor containers of sterk geïsoleerde services. Deze functionaliteit is ook gekoppeld aan verbeteringen in systemd-importd , dat de ondersteuning voor het downloaden en beheren van OCI-images uitbreidt , waardoor de rol van systemd als containerisatie- en sandboxing-engine wordt versterkt, iets wat veel voorkomt bij Europese cloudproviders en moderne hostingplatforms.

Netwerk: Integratie met ModemManager en nieuwe prestatieopties

Op netwerkniveau wint systemd-networkd steeds meer aan belang. Een van de opvallende nieuwe functies is de integratie met ModemManager via het "simple connect"-protocol , waarmee modems en mobiele verbindingen rechtstreeks vanuit networkd beheerd kunnen worden zonder afhankelijk te zijn van externe tools.

Om deze workflow te ondersteunen, wordt een nieuwe sectie toegevoegd. naar de configuratiebestanden, met parameters zoals APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=Dit vergemakkelijkt de implementatie in landelijke gebieden of omgevingen met connectiviteit op basis van mobiele netwerken, zeer aanwezig in bepaalde delen van Europa waar niet altijd glasvezel of kwalitatief goede vaste telefoonlijnen beschikbaar zijn.

Wat prestaties betreft, bevatten de systemd-networkd .link -bestanden nieuwe opties specifiek voor Ethernet-apparaten. Deze omvatten ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList en GenericReceiveOffloadUDPForwarding . Met deze opties kan de offloading van taken naar de hardware en drivers nauwkeurig worden afgestemd, wat cruciaal is in bedrijfsnetwerken, datacenters en bij serviceproviders die elke milliseconde latentie tot een minimum moeten beperken.

Bovendien kunnen de Varlink- en JSON- interfaces van systemd-networkd nu IP-adressen rapporteren in een leesbaar formaat (strings), terwijl de weergave als een integer-array behouden blijft. Dit vereenvoudigt de integratie met monitoringdashboards, beheerscripts of tools van derden die geen onintuïtieve numerieke formaten willen verwerken.

Serviceportabiliteit, tijdelijke virtuele machines en services zonder verhoogde privileges

De systemd-portabled- component , verantwoordelijk voor het beheren van "draagbare" services die in images zijn verpakt, krijgt een zeer interessante mogelijkheid: deze kan nu als een service op gebruikersniveau worden uitgevoerd . Dit betekent dat gebruikers zonder beheerdersrechten, in hun normale sessie, draagbare services binnen hun eigen ruimte kunnen starten en beheren zonder sudo of verhoogde bevoegdheden te hoeven gebruiken.

Bovendien kan portabled vanaf deze versie beleidsregels genereren en de image vergrendelen die is gekoppeld aan een portable service , waardoor het wijzigen van die image zonder herkoppeling wordt voorkomen. Dit stelt gebruikers in staat om op zichzelf staande omgevingen op te zetten met extra garanties voor onveranderlijkheid, een bijzonder aantrekkelijke functie voor labs, ontwikkelomgevingen en testomgevingen.

Aan de andere kant breidt systemd-vmspawn —de tool die is ontworpen om virtuele machines op een geïntegreerde manier met systemd te starten— zijn mogelijkheden uit door zich binnen de gebruikerssessie te registreren bij systemd-machined . Het introduceert ook een `-ephemeral`- optie om tijdelijke machines te creëren die na gebruik worden verwijderd. Dit is perfect geschikt voor CI/CD-pipelines, virtuele klaslokalen of Europese onderwijsplatformen die de snelle en gecontroleerde aanmaak en verwijdering van virtuele machines vereisen.

Nauwkeurige controle van CPU, geheugen en planning met SCHED_EXT en THP.

Systemd 260 gaat ook dieper in op prestatiebeheer met nieuwe beleidsregels. De serviceoptie CPUSchedulingPolicy= accepteer nu de waarde ext, waardoor de planner wordt geactiveerd SCHED_EXTDeze alternatieve planner opent de deur naar experimenten met verschillende planningsbeleidsmaatregelen wat betreft de kernelstandaarden, iets dat interessant kan zijn voor R&D-laboratoria of voor zeer gespecialiseerde implementaties.

In het geheugengedeelte vindt u `MemoryTHP=` , waarmee u het gebruik van Transparent Huge Pages (THP) per service kunt beheren . In plaats van een systeemwijde, globale instelling kunt u bepalen of een specifieke eenheid THP moet gebruiken, uitschakelen of tussenliggende modi moet toepassen. Voor kritieke applicaties in de bank-, verzekerings- of overheidssector kan deze gedetailleerde controle een significant verschil maken in latentie, geheugenverbruik en prestaties.

Nieuwe commando's in systemctl en uitgebreider gebruik van Varlink

Het bekende systemctl- commando krijgt er een nieuwe bij: enqueue-marked . Deze actie roept intern de D-Bus-methode EnqueueMarkedJobs() aan en maakt het mogelijk om met wachtrijen van vooraf gemarkeerde taken en services te werken. Hoewel dit misschien een klein detail lijkt, is het voor operationele teams die grootschalige serverparken beheren een waardevolle tool om implementatie- en automatiseringsworkflows te verfijnen.

Parallel daaraan wordt het gebruik van Varlink als communicatiemechanisme tussen componenten verder uitgebreid. Veel onderdelen van systemd bieden stabiele Varlink-interfaces, die de integratie met externe tools, aangepaste dashboards of monitoringagents die gestructureerde toegang tot systeeminformatie vereisen, vergemakkelijken.

Systeemidentificatievelden en gebruikerservaring

Een merkwaardige maar nuttige nieuwe functie voor sommige distributies is de introductie van het veld. FANCY_NAME= in het archief /etc/os-releaseDit veld lijkt op PRETTY_NAME, maar staat toe ANSI-reeksen en meer geavanceerde Unicode-tekensDankzij deze functie kunnen specifieke distributies en edities worden gepresenteerd met meer in het oog springende of onderscheidende namen.

De waarde van FANCY_NAME kan worden bekeken via de systemd-manager met behulp van systemd-hostnamed of door hostnamectl op te vragen . Hoewel het een kleine wijziging is, kan het in desktopomgevingen en grafische beheerpanelen nuttig zijn om snel het beheerde systeem te identificeren , vooral bij het werken met veel afgeleide varianten.

Specifieke documentatie voor AI-agenten en een workflow voor ondersteunde beoordeling.

Een van de meest interessante signalen over de ontwikkelingsrichting van systemd is de verschijning van documentatie die specifiek gericht is op kunstmatige intelligentie-agenten . De repository bevat een AGENTS.md- bestand , bedoeld om codeanalysetools en programmeerassistenten, evenals enkele technologiehandleidingen , te helpen de architectuur, stijl, ontwikkelingsworkflow en bijdragerichtlijnen van het project beter te begrijpen.

Dit document beschrijft componenten, build-paden, hoe tests en integraties uitgevoerd moeten worden, en richtlijnen voor het genereren van acceptabele patches. Het doel is om AI-agenten die code beoordelen of wijzigingen aanbrengen, een gedegen begrip te geven van de structuur van systemd , waardoor fouten en onterechte suggesties worden verminderd.

Naast AGENTS.md bevindt zich een bestand genaamd CLAUDE.md , dat expliciet naar het eerstgenoemde bestand verwijst en is ontworpen om de Claude Code-tool te begeleiden, een van de meest gebruikte AI-gebaseerde ontwikkelingsassistenten. Op deze manier integreert het project expliciet AI in zijn ontwikkelingscyclus.

Daarnaast is er een configuratiebestand meegeleverd. claude-review.ymlHierin wordt beschreven hoe het proces van het analyseren van wijzigingsverzoeken (pull requests) moet worden beoordeeld, met behulp van Claude Code. In deze context moeten bijdragen die AI hebben gebruikt, dit integreren. openbaarmakingslabels als Co-developed-by In de patches zijn sporen te vinden die erop wijzen dat een geautomatiseerd hulpmiddel heeft meegewerkt aan het maken van de code.

Met deze uitgebreide reeks wijzigingen – het opruimen van verouderde ondersteuning, het verfijnen van sandboxing, het verbeteren van TPM2 en SRK, geavanceerde netwerkintegratie, nieuwe portabiliteitsmogelijkheden en documentatie speciaal ontworpen voor intelligente agents – versterkt systemd 260 zijn centrale rol in het moderne Linux-ecosysteem. Voor beheerders en ontwikkelaars in Spanje en Europa ligt de directe uitdaging in het beoordelen van kernels, het aanpassen van opstartconfiguraties en -services, en het benutten van deze functies om veiligere, geautomatiseerde infrastructuren te bouwen die aansluiten op het huidige systeemgebruik.