Systemd 260: TPM2, sandboxing och nya funktioner i Linux

Hårdvaruguide » Köpguider » Systemd 260: TPM2, sandboxing och nya funktioner i Linux

Med ankomsten av systemd 260 Linuxdistributioner tar ytterligare ett viktigt steg mot ett modernare, säkrare ekosystem inriktat på molnmiljöer, virtualisering och automatisering. Den här versionen finslipar inte bara detaljerna: den introducerar betydande förändringar av uppstart, tjänsthantering, nätverk, användningen av TPM2 för integritet och kryptering samt sandboxfunktioner på enhetsnivå.

Samtidigt stärker projektet sin dokumentation och sitt arbetssätt med agenter för artificiell intelligensDetta gör det tydligt att systemd är en kritisk pelare som fler och fler utvecklings- och observerbarhetsverktyg ansluter till. Om du hanterar Linux-system på servrar, i molnet, på företagsdatorer eller i labb, är det värt att ta en stund att granska alla dessa nya funktioner för att planera för uppdateringar och konfigurationsjusteringar.

Ett sista adjö till System V och totalt beroende av inbyggda hårddiskar

En av de mest slående förändringarna i systemd 260 är fullständigt tillbakadragande av stöd för System V-skriptDen klassiska startprocessen baserad på /etc/init.d har varit på väg att fasas ut i åratal, men nu försvinner den i praktiken från systemd-koden.

Det här innebär att komponenterna som ansvarar för att överbrygga mellan SysV-skript och nativa enheter har tagits bort: systemd-rc-local-generator, rc-local.service, systemd-sysv-generator och systemd-sysv-install De upphör att existera. Som en konsekvens kommer alla tjänster som fortfarande är beroende av dessa äldre mekanismer helt enkelt inte att starta på system som använder SystemD 260.

Under rensningsprocessen har flera Meson-byggalternativ också markerats som föråldrade eller tagits bort. Flaggorna -Drc-local=, -Dsysvinit-path= och -Dsysvrcnd-path= vissa är förpassade till minnenas bagageutrymme, medan andra gillar -Dintegrationstester= och -Dcryptolib= De tas bort direkt. Det är ett tydligt budskap: allt måste gå via inbyggda enheter och den moderna systemd-infrastrukturen.

För många europeiska infrastrukturer som fortfarande förlitar sig på äldre komponenter kräver denna förändring en granskning av interna tjänster, anpassade skript och äldre distributioner. Att migrera till väldefinierade enhetsfiler rekommenderas inte längre bara; det är obligatoriskt om du vill fortsätta köra tjänster på distributioner som integrerar systemd 260.

Högre kärnkrav och fokus på nuvarande miljöer

Den nya versionen höjer ribban för kärnan: från och med nu, Den lägsta Linux-versionen som stöds är 5.10lämnar efter sig mycket gamla grenar som 5.4. Dessutom indikerar projektet att idealet är att arbeta med en kärna 5.14 eller högreoch rekommenderar särskilt 6.6 serie för att dra nytta av alla tillgängliga funktioner.

Denna ökning av krav är vanligtvis inte ett problem i moderna distributioner, men det kan komplicera saker i mycket konservativa miljöer eller i inbäddade lösningar som underhållits i många år. Innan du uppgraderar till systemd 260 är det lämpligt att kontrollera vilken kärna som används, särskilt i Europeiska datacenter med långsiktiga driftsättningar eller i anpassade bilder.

I den motsatta änden av spektrumet tenderar rullande utgåvor som Arch Linux eller openSUSE Tumbleweed, mycket populära bland dem som vill ha de senaste funktionerna, att snabbt införliva både nya kärnor och nya grenar av systemd. Andra, som Fedora, bibehåller en viss grad av stabilitet i huvudversionen av systemd under hela livscykeln för varje utgåva, vilket ger lite mer tid att planera migreringar.

TPM2, startintegritet och avancerat SRK-stöd

Ett av de områden där systemd utvecklas mest är dess integration med TPM2 (Trusted Platform Module 2.0)Detta chip, allt vanligare i moderna UEFI-moderkort och hårdvara i mellan- och avancerade segment, låter dig förankra hemligheter i systemtillståndet, mäta startfaser och låsa upp krypterade volymer automatiskt när miljön är som förväntat.

Systemd 260 förbättrar denna integration ytterligare genom att lägga till verktyg och tjänster som täcker olika steg i startprocessen. En viktig komponent är... systemd-tpm2-installation, ansvarig för att förbereda infrastrukturen runt Lagringsrotnyckel (SRK) av TPM:n. Denna rotnyckel fungerar som den kryptografiska grunden för att säkra kommunikationen med chipet och för att säkert lagra andra hemligheter.

Under uppstarten kan två faser urskiljas: en mycket tidig i initrd och en annan i rotsystemet. I den första kontrollerar en tjänst som heter "Early TPM SRK Setup" om TPM:en redan har en lagrad SRK och, om den inte finns, skapar den och gör den tillfälligt tillgänglig under /run/systemd/tpm2-srk-public-key.*Senare, när själva filsystemet är monterat, kommer tjänsten att konsolidera SRK och verifiera att nyckeln som lagras i /var/lib/systemd/tpm2-srk-public-key.pem Det sammanfaller med det i TPM.

I välkonfigurerade scenarier visas journalposter som dessa. "SRK finns redan lagrat i TPM" och meddelanden som indikerar att SRK-fotavtrycket matchar det förväntade. Om miljön å andra sidan inte är anpassad (till exempel i konfigurationer med Yocto eller på kort som Raspberry Pi med SPI TPM och anpassade startmetoder med U-Boot och uppmätt start), kan situationer uppstå där systemd misslyckas med att skapa dessa filer under /var/lib/systemd, vilket väcker tvivel om huruvida SRK har konfigurerats korrekt.

När TPM-tillståndet har ändrats, partitioner har modifierats eller startflödet har ändrats, kanske den tillhörande policyn inte längre är tillämplig. I sådana fall rekommenderar vissa underhållare rensa TPM-platsen eller policyn och registrera om nyckeln, enligt procedurer som liknar de som beskrivs i guider för diskkryptering med TPM i miljöer som openSUSE, där det beskrivs i detalj hur man återskapar PCR-policyn och återlänkar volymupplåsning.

Förutom SRK är en annan praktisk förbättring introduktionen i udev av ett internt verktyg som kallas tpm2_idDet här integrerade verktyget körs när systemet upptäcker en TPM2-enhet och Den extraherar automatiskt tillverkarens ID och modell.Detta förenklar inventeringen av säkerhetshårdvara, vilket är mycket användbart inom offentliga förvaltningar, reglerade företag eller kritisk infrastruktur där det är nödvändigt att veta exakt vilka TPM-moduler som används.

Integrationen med startup-mätinfrastrukturen förstärks också med specifika enheter som systemd-pcrextendsom loggar händelser som ”enter-initrd”, ”leave-initrd”, ”sysinit” eller ”ready” i olika PCR:er (till exempel PCR 11). Denna sekvens av tillägg gör det möjligt för TPM att samla in en kryptografiskt verifierbar post av startflödet, som sedan kan användas för Trusted Boot-policyer eller för UKI (Unified Kernel Images) som validerar maskinens status innan nycklarna släpps.

Säkerhetsåtgärder och sandboxing av tjänster med systemd

Systemd startar inte bara processer: det erbjuder också en mycket omfattande uppsättning sandboxing-direktiv för att isolera tjänster och begränsa skador vid kompromettering. Denna metod med "djupgående försvar" bygger på cgroups, namnrymder, kärnfunktioner och systemanropsfilter (seccomp).

För att bedöma statusen för en specifik tjänst inkluderar systemd verktyget systemd-analysera säkerhetNär den körs genereras en rapport med ett exponeringsindex på en skala från 0 till 10, där lägre är bättre. Rapporten bryter ner aktiverade eller saknade skydd (nätverksisolering, åtkomst till filsystemet, enheter etc.), vilket gör det mycket enkelt att upptäcka sårbarheter. vilka justeringar behövs och kontrollera om de införda ändringarna faktiskt förbättrar poängen.

Istället för att redigera den ursprungliga enheten – som skulle gå förlorad i framtida paketuppdateringar – rekommenderas det att skapa en åsidosätta en /etc/systemd/system/mi-servicio.service.d/ med en fil, till exempel sandbox.confEfter att du har ändrat den, ladda bara om konfigurationen med system-uppdatering av demonen och starta om tjänsten så att de nya restriktionerna träder i kraft.

På filsystemnivå är ett av de viktigaste alternativen Skyddssystem=Värderingar som strict, full o true De monterar olika delar av trädet i skrivskyddat läge. Vanligtvis, när det är möjligt, är att använda SkyddaSystem=striktDetta gör /usr, /boot, /efi och /etc skrivskyddade för tjänsten. Om ett program behöver skriva till specifika kataloger är det tillåtet att göra det med hjälp av LäsSkrivSökvägar=/sökväg i enhet.

För att ytterligare förbättra integriteten rekommenderas det också att begränsa åtkomsten till användarkataloger genom SkyddaHem=santvilket hindrar tjänsten från att läsa /home, /root eller /run/user. Dessutom, PrivateTmp=sant Det skapar ett isolerat /tmp- och /var/tmp-utrymme, vilket förhindrar korsvis synlighet av temporära filer mellan processer.

På enheter, PrivataEnheter=sant Den döljer det faktiska /dev-trädet och ersätter det med en minimal uppsättning säkra pseudoenheter (null, noll, slumpmässiga, etc.). Om en enhet behöver en specifik enhet (till exempel en seriell port eller ett diskblock) kan den beviljas med hjälp av EnhetTillåt=/dev/xxx rw eller i skrivskyddat läge.

Nätverket är också en viktig vektor. Med Privatnätverk=sant Ett isolerat nätverksnamnområde skapas, vilket bara lämnar loopbacken; tjänsten kommer inte att se fysiska gränssnitt och kommer inte att kunna kommunicera med omvärlden. Alternativt kan du begränsa vilka adressfamiljer den kan använda genom att RestrictAddressFamilies=tillåter endast AF_INET och AF_INET6 för IPv4/IPv6, AF_UNIX för lokala sockets eller till och med none för att helt japanisera nätverkskapaciteten.

Angående privilegier, direktivet IngaNyaPrivilegier=sant Det är ett av de kraftfullaste: det förhindrar att processen får nya privilegier via setuid-binärfiler eller funktionsändringar. Kort sagt, även om tjänsten kör sårbar kod, borde den inte kunna eskalera till root via traditionella mekanismer. Kombinerat med CapabilityBoundingSet=Genom att definiera den exakta listan över tillåtna funktioner (t.ex. att endast CAP_NET_BIND_SERVICE ska lyssna på låga portar) minimeras attackytan.

För att gå ännu längre tillåter systemd filtrering av systemanrop med SystemCallFilter=Istället för att underhålla en manuell lista över systemanrop används fördefinierade grupper, till exempel @system-service, @network-io, @basic-io eller förneka grupper som ~@privileged. Med systemd-analysera syscall-filter Det är möjligt att inspektera vilka specifika anrop som tillhör varje grupp. Detta möjliggör konstruktionen av en mycket begränsad exekveringsprofil, liknande vad en dedikerad sandlåda skulle erbjuda.

Andra relevanta justeringar är ProtectKernelTunables=true, vilket blockerar modifieringen av kärnparametrar i /proc/sys och /sys, ProtectKernelModules=truevilket förhindrar lastning eller lossning av moduler, ProtectKernelLogs=truevilket förhindrar läsning av kärnregister, och Skyddskontrollgrupper=santvilket blockerar skrivningar till cgroups hierarki. Allt detta kombineras sömlöst med nya funktioner för användarisolering som Privata användare=fullständig, som i version 260 är uppdaterad för att mappa hela spektrumet av användar-ID:n, vilket eliminerar tidigare lösningar som behövdes för miljöer med kapslad systemd.

PrivateUsers, xaccess och nya enhetsåtkomstkontroller

Mekanismen Privata användareDen är utformad för att köra tjänster i ett isolerat användar-ID-utrymme och konsolideras i systemd 260. Alternativet Privata användare=fullständig Den mappar nu hela spektrumet av identifierare, vilket förenklar saker i containrar och på system med kapslade systemd-instanser baserat på äldre versioner (före 257). Denna förbättring har eliminerat hackningar som användes för att upptäcka dessa äldre instanser.

Parallellt, komponenter som systemd-logind och systemd-udevd De lanserar konceptet med xaccessDenna mekanism kompletterar den klassiska logiken bakom uaccessxaccess ger åtkomst till vissa enheter (t.ex. ljud eller video) till användare med grafiska sessioner i förgrunden på den lokala maskinen. Behörigheter kan delegeras till xaccess. fjärranvändare med särskilt markerade sessionerså att till exempel en användare som är ansluten via fjärrskrivbord kan komma åt lokala GPU-renderingsenheter utan att ge breda behörigheter till hela systemet.

Konfigurationen av dessa sessioner involverar miljövariabler som exponeras via PAM, specifikt PAMXDG_SESSION_EXTRA_DEVICE_ACCESS=Detta gör det möjligt att definiera vilka specifika enheter som faller under detta ramverk. Det är en metod som är i hög grad i linje med EU:s regelefterlevnads- och dataskyddskrav, vilka kräver detaljerad och spårbarhet vid åtkomst till känslig hårdvara.

mstack, systemd-mstack och nya containerverktyg

Inom området containerisering introducerar systemd 260 funktionaliteten mstack och ett tillhörande kommando, systemd-mstackTanken bakom mstack är att tillåta att definiera en OverlayFS baserat på strukturen i en speciell katalog som heter .mstack/, som följer en specifik specifikation för att organisera sina lager.

Det nya kommandoradsverktyget, systemd-mstack, gör det enklare att arbeta interaktivt med dessa filsystems"stackar", vilket ger flexibilitet vid konfigurering av lagermiljöer för containrar eller mycket isolerade tjänster. Denna funktionalitet är också kopplad till förbättringar i systemd-importerad, vilket utökar sitt stöd för Ladda ner och hantera OCI-bilderDetta förstärker systemds roll som en containeriserings- och sandlådemotor, något som är mycket vanligt hos europeiska molnleverantörer och moderna hostingplattformar.

Nätverk: Integration med ModemManager och nya prestandaalternativ

På nätverkslagret fortsätter systemd-networkd att få större betydelse. En av dess anmärkningsvärda nya funktioner är dess integration med ModemManager med hjälp av protokollet "simple connect"Detta gör att du kan hantera modem och mobila anslutningar direkt från networkd utan att förlita dig på externa verktyg.

För att stödja detta flöde har ett nytt avsnitt lagts till. till konfigurationsfilerna, med parametrar som APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=Detta underlättar utplaceringar i landsbygdsområden eller miljöer med uppkoppling baserad på mobilnät, mycket förekommande i vissa områden i Europa där det inte alltid finns fiber eller fasta telefoner av hög kvalitet.

När det gäller prestanda, filerna .länk systemd-networkd innehåller nya alternativ specifikt för Ethernet-enheter. Bland dem finns: ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList och GenericReceiveOffloadUDPForwardingDessa alternativ möjliggör finjustering av avlastningen av arbete till hårdvara och drivrutiner, något som är avgörande i företagsnätverk, datacenter och tjänsteleverantörer som behöver minimera varje millisekund av latens.

Dessutom gränssnitten Varlink och JSON systemd-networkd kan nu rapportera IP-adresser i ett format läsbar för människor (strängar) samtidigt som representationen bibehålls som en array av heltal. Detta förenklar integrationen med övervakningsinstrumentpaneler, administrationsskript eller tredjepartsverktyg som inte vill hantera ointuitiva numeriska format.

Tjänsteportabilitet, kortlivade virtuella maskiner och oprivilegierade tjänster

Stycket systemd-portabelProgramvaran som ansvarar för att hantera "portabla" tjänster paketerade i avbildningar får en mycket intressant funktion: den kan köras som en tjänst på användarnivåDet här innebär att oprivilegierade användare, i sin vanliga session, kan starta och hantera portabla tjänster inom sitt eget utrymme utan att behöva använda sudo eller utökade privilegier.

Dessutom, från och med den här versionen, kan bärbar generera policyer och etablera avbildningen associerad med en portabel tjänstDetta förhindrar att bilden ändras utan att den behöver bifogas på nytt. Användare kan därmed skapa självständiga miljöer med extra garantier för oföränderlighet, vilket är ganska attraktivt för laboratorier, utvecklingsmiljöer och testsandlådor.

Vidare, systemd-vmspawn —verktyget som är utformat för att starta virtuella maskiner på ett integrerat sätt med systemd— utökar sina möjligheter att registrera sig i systemd-maskinerad inom användarsessionenDen introducerar också ett alternativ -kortlivad att skapa kortlivade maskiner som förstörs när de är slut. Detta passar perfekt med CI/CD-pipelines, virtuella klassrum eller europeiska utbildningsplattformar som kräver att lyfta och dra maskiner snabbt och kontrollerat.

Finjusterad kontroll av CPU, minne och schemaläggning med SCHED_EXT och THP

Systemd 260 fördjupar sig också i prestandakontroll med nya policyer. Tjänstalternativet CPUSchedulingPolicy= acceptera nu värdet ext, vilket aktiverar schemaläggaren SCHED_EXTDenna alternativa planerare öppnar dörren till experiment med olika planeringspolicyer till kärnstandarderna, något som kan vara av intresse i FoU-laboratorier eller i högspecialiserade implementeringar.

I minnesområdet visas MinneTHP=vilket möjliggör hantering av användningen av Transparenta stora sidor (THP) per tjänst. Istället för att ha ett globalt beteende för hela systemet kan man avgöra om en specifik enhet ska utnyttja THP, inaktivera det eller använda mellanliggande lägen. För kritiska tillämpningar inom bank, försäkring eller offentlig förvaltning kan denna detaljerade kontroll göra skillnad i latens, minnesförbrukning och prestanda.

Nya kommandon i systemctl och utökad användning av Varlink

Det välkända kommandot systemctl vinner en ny order: kömärktDen här åtgärden anropar internt D-Bus-metoden. Lägg tillMarkedJobs() i kö och möjliggör arbete med köer av förvalda jobb och tjänster. Även om detta kan verka som en mindre detalj är det avgörande för driftsteam som orkestrerar storskaliga serverfarmar Det är ännu ett verktyg för att förfina driftsättnings- och automatiseringsarbetsflöden.

Parallellt fortsätter projektet att utöka användningen av Varlink som en kommunikationsmekanism mellan komponenter. Många delar av systemd exponerar stabila Varlink-gränssnitt, vilket underlättar integration med externa verktyg, anpassade instrumentpaneler eller övervakningsagenter som behöver strukturerad åtkomst till systeminformation.

Systemidentifieringsfält och användarupplevelse

En märklig men användbar ny funktion för vissa distributioner är introduktionen av fältet FINCY_NAME= i arkivet /etc/os-releaseDet här fältet liknar PRETTY_NAME, men tillåter ANSI-sekvenser och mer avancerade Unicode-teckenTack vare detta kan specifika distributioner och utgåvor presenteras med mer iögonfallande eller distinkta namn.

Värdet för FANCY_NAME kan ses via systemd-hanteraren med hjälp av systemd-värdnamn eller vid konsultation hostnamectlÄven om det är en liten förändring kan den vara användbar i skrivbordsmiljöer och grafiska administrationspaneler för identifiera systemet med en snabb blick som hanteras, särskilt när det gäller många härledda varianter.

Specifik dokumentation för AI-agenter och arbetsflöden för assisterad granskning

Ett av de mest intressanta tecknen på vart systemutvecklingen är på väg är framväxten av dokumentation som är specifikt inriktad på agenter för artificiell intelligensEn fil finns inkluderad i arkivet AGENTS.mdutformad för kodanalysverktyg och programmeringsassistenter, och som vissa har noterat teknikguider, bättre förstå projektets arkitektur, stil, utvecklingsflöde och riktlinjer för bidrag.

Det här dokumentet beskriver komponenter, byggvägar, hur man kör tester och integrationer, samt riktlinjer för att generera acceptabla patchar. Avsikten är att AI-agenter som granskar kod eller genererar ändringar ska kunna arbeta med dem. en solid kontext för hur systemd är organiseratminska fel och felaktiga förslag.

Bredvid AGENTS.md visas en fil som heter CLAUDE.mdDetta refererar explicit till det första och fokuserar på att vägleda Claude Code-verktyget, en av de mest använda AI-baserade utvecklingsassistenterna. På så sätt integrerar projektet explicit AI i sin utvecklingscykel.

Dessutom ingår en konfigurationsfil. claude-review.ymldär det definieras hur processen för att analysera ändringsförfrågningar (pull requests) ska granskas, med hjälp av Claude Code. I detta sammanhang krävs att bidrag som har använt AI införlivar etiketter för avslöjande som Co-developed-by i patcharna, vilket lämnar bevis på att ett automatiserat verktyg har deltagit i skapandet av koden.

Med alla dessa förändringar – upprensning av äldre stöd, förbättringar av sandboxing, förbättringar av TPM2 och SRK, avancerad nätverksintegration, nya portabilitetsfunktioner och dokumentation utformad för intelligenta agenter – systemd 260 Detta förstärker dess centrala roll i det moderna Linux-ekosystemet. För administratörer och utvecklare i Spanien och Europa innebär den omedelbara utmaningen att granska kärnor, anpassa startkonfigurationer och tjänster, och utnyttja dessa funktioner för att bygga säkrare, automatiserade infrastrukturer i linje med nuvarande systemanvändning.