Systemd 260: TPM2, sandkasseing og nye funksjoner i Linux

Maskinvareguide » Kjøpeguider » Systemd 260: TPM2, sandkasse og nye funksjoner i Linux

Med ankomsten av systemd 260 tar Linux-distribusjoner et nytt viktig skritt mot et mer moderne og sikkert økosystem rettet mot skymiljøer, virtualisering og automatisering. Denne versjonen finpusser ikke bare detaljer: den introduserer betydelige endringer i oppstart, tjenesteadministrasjon, nettverk, bruk av TPM2 for integritet og kryptering, og sandkassefunksjoner på disknivå.

Samtidig styrker prosjektet dokumentasjonen og tilnærmingen til arbeid med kunstig intelligens-agenter , noe som tydeliggjør at systemd er en kritisk søyle som stadig flere utviklings- og observasjonsverktøy kobler seg til. Hvis du administrerer Linux-systemer på servere, i skyen, på bedriftsdatamaskiner eller i laboratorier, er det verdt å ta et øyeblikk til å gjennomgå alle disse nye funksjonene for å planlegge oppdateringer og konfigurasjonsjusteringer.

Et siste farvel til System V og total avhengighet av native disker

En av de mest slående endringene i systemd 260 er den fullstendige fjerningen av støtte for System V-skript . Den klassiske oppstartsprosessen basert på /etc/init.d hadde blitt faset ut i årevis, men nå forsvinner den effektivt fra systemd-koden.

Dette betyr at komponentene som er ansvarlige for å bygge bro mellom SysV-skript og native enheter er fjernet: systemd-rc-local-generator, rc-local.service, systemd-sysv-generator og systemd-sysv-install eksisterer ikke lenger. Som et resultat vil enhver tjeneste som fortsatt er avhengig av disse eldre mekanismene, rett og slett ikke starte på systemer som bruker systemd 260.

Under oppryddingsprosessen har flere Meson-byggealternativer også blitt markert som foreldet eller fjernet. Flaggene -Drc-local=, -Dsysvinit-path= og -Dsysvrcnd-path= har blitt henvist til arkivene, mens andre som -Dintegration-tests= og -Dcryptolib= har blitt fjernet helt. Dette sender et klart budskap: alt må nå håndteres av native enheter og den moderne systemd-infrastrukturen.

For mange europeiske infrastrukturer som fortsatt er avhengige av eldre komponenter, nødvendiggjør denne endringen en gjennomgang av interne tjenester, tilpassede skript og eldre distribusjoner. Migrering til veldefinerte enhetsfiler anbefales ikke lenger bare; det er obligatorisk hvis du vil fortsette å kjøre tjenester på distribusjoner som integrerer systemd 260.

Høyere kjernekrav og fokus på nåværende miljøer

Den nye versjonen hever standarden for kjernen: fra nå av er den minimumsstøttede Linux-versjonen 5.10 , og etterlater svært gamle grener som 5.4. Videre indikerer prosjektet at brukere ideelt sett bør jobbe med en 5.14-kjerne eller høyere , og anbefaler spesielt 6.6-serien for å dra full nytte av alle tilgjengelige funksjoner.

Denne økningen i krav er vanligvis ikke et problem i moderne distribusjoner, men det kan komplisere saker i svært konservative miljøer eller innebygde løsninger som vedlikeholdes i mange år. Før du oppgraderer til systemd 260, anbefales det å bekrefte hvilken kjerne som brukes, spesielt i europeiske datasentre med langsiktige distribusjoner eller tilpassede images.

I den motsatte enden av spekteret har rullerende utgivelsesdistribusjoner som Arch Linux eller openSUSE Tumbleweed, svært populære blant de som ønsker de nyeste funksjonene, en tendens til raskt å innlemme både nye kjerner og nye grener av systemd. Andre, som Fedora, opprettholder en viss grad av stabilitet i hovedversjonen av systemd gjennom hele livssyklusen til hver utgivelse, noe som gir litt mer tid til å planlegge migreringer.

TPM2, oppstartsintegritet og avansert SRK-støtte

Et av områdene der systemd utvikler seg mest, er integrasjonen med TPM2 (Trusted Platform Module 2.0) . Denne brikken, som blir stadig mer vanlig i moderne UEFI-hovedkort og maskinvare i mellomklassen og avanserte segmenter, tillater forankring av hemmeligheter til systemtilstanden, måling av oppstartsfaser og automatisk opplåsing av krypterte volumer når miljøet er som forventet.

Systemd 260 forbedrer denne integrasjonen ytterligere ved å legge til verktøy og tjenester som dekker ulike stadier av oppstartsprosessen. En nøkkelkomponent er systemd-tpm2-setup , som er ansvarlig for å forberede infrastrukturen rundt TPM-ens Storage Root Key (SRK) . Denne rotnøkkelen fungerer som det kryptografiske fundamentet for å sikre kommunikasjon med brikken og for sikker lagring av andre hemmeligheter.

Under oppstart skilles det mellom to faser: en veldig tidlig i initrd og en annen i rotsystemet. I den første sjekker en tjeneste kalt "Early TPM SRK Setup" om TPM allerede har en lagret SRK, og hvis den ikke finnes, oppretter den den og gjør den midlertidig tilgjengelig under /run/systemd/tpm2-srk-public-key.* . Senere, når det virkelige filsystemet er montert, vil tjenesten konsolidere SRK-en og bekrefte at nøkkelen som er lagret i /var/lib/systemd/tpm2-srk-public-key.pem samsvarer med den i TPM-en.

I godt konfigurerte scenarier vil journaloppføringer som "SRK er allerede lagret i TPM" og meldinger som indikerer at SRK-fotavtrykket samsvarer med det forventede vises. Men hvis miljøet ikke er riktig konfigurert (for eksempel i oppsett som bruker Yocto eller på kort som Raspberry Pi med SPI-basert TPM og tilpassede oppstartsmetoder som U-Boot og målt oppstart), kan det oppstå situasjoner der systemd ikke klarer å opprette disse filene under /var/lib/systemd, noe som reiser tvil om SRK er riktig konfigurert.

Når TPM-tilstanden har endret seg, partisjoner har blitt modifisert eller oppstartssekvensen har blitt endret, kan det hende at den tilknyttede policyen ikke lenger er gyldig. I slike tilfeller anbefaler noen vedlikeholdere å tømme TPM-sporet eller policyen og registrere nøkkelen på nytt , ved å følge prosedyrer som ligner på de som er beskrevet i diskkrypteringsveiledninger med TPM i miljøer som openSUSE, som beskriver hvordan du gjenskaper PCR-policyen og kobler opp volumopplåsing på nytt.

Bortsett fra SRK er en annen praktisk forbedring introduksjonen av et internt verktøy kalt tpm2_id i udev . Dette integrerte verktøyet kjører når systemet oppdager en TPM2-enhet og trekker automatisk ut produsent- og modellidentifikator . Dette forenkler inventaret av sikkerhetsmaskinvare, noe som er svært nyttig i offentlige forvaltninger, regulerte selskaper eller kritiske infrastrukturer der det er viktig å vite nøyaktig hvilke TPM-moduler som er distribuert.

Integrasjonen med oppstartsmålingsinfrastrukturen styrkes ytterligere av spesifikke enheter som systemd-pcrextend , som logger hendelser som "enter-initrd", "leave-initrd", "sysinit" og "ready" i forskjellige PCR-er (f.eks. PCR 11). Denne sekvensen av utvidelser lar TPM-en samle en kryptografisk verifiserbar registrering av oppstartsflyten, som deretter kan brukes til Trusted Boot-policyer eller for UKI (Unified Kernel Images) for å validere maskinens tilstand før nøkler frigjøres.

Sikkerhetstiltak og sandboksing av tjenester med systemd

Systemd starter ikke bare prosesser, men tilbyr også et omfattende sett med sandkassedirektiver for å isolere tjenester og begrense skade i tilfelle kompromittering. Denne "dybdeforsvarstilnærmingen" er avhengig av cgroups, navnerom, kjernefunksjoner og systemkallfiltre (seccomp).

For å vurdere sikkerheten til en spesifikk tjeneste inkluderer systemd sikkerhetsverktøyet systemd-analyse . Når det kjøres, genereres en rapport med en eksponeringspoengsum på en skala fra 0 til 10, hvor en lavere poengsum er bedre. Rapporten bryter ned hvilke beskyttelser som er aktivert eller deaktivert (nettverksisolering, tilgang til filsystemet, enhetstilgang osv.), noe som gjør det enkelt å identifisere manglende innstillinger og bekrefte om endringer faktisk forbedrer poengsummen.

I stedet for å redigere den opprinnelige enheten – som ville gått tapt i fremtidige pakkeoppdateringer – anbefales det å opprette en overstyring en /etc/systemd/system/mi-servicio.service.d/ med en fil, for eksempel sandbox.confEtter at du har endret den, laster du bare inn konfigurasjonen på nytt med systemtatt daemon-reload og start tjenesten på nytt slik at de nye restriksjonene trer i kraft.

På filsystemnivå er et av de viktigste alternativene BeskyttSystem=Verdier som strict, full o true De monterer forskjellige deler av treet i skrivebeskyttet modus. Vanlig praksis, når det er mulig, er å bruke BeskyttSystem=strengtDette gjør /usr, /boot, /efi og /etc skrivebeskyttet for tjenesten. Hvis et program trenger å skrive til bestemte mapper, er det tillatt å gjøre det ved hjelp av LeseSkrivebaner=/sti i enhet.

For å forbedre personvernet ytterligere anbefales det også å begrense tilgangen til brukerkataloger ved hjelp av `ProtectHome=true` , som hindrer tjenesten i å lese `/home`, `/root` eller `/run/user`. I tillegg oppretter `PrivateTmp=true` isolerte `/tmp`- og `/var/tmp`-mellomrom, noe som forhindrer krysssynlighet av midlertidige filer mellom prosesser.

I enheter skjuler `PrivateDevices=true` det faktiske `/dev`-treet og erstatter det med et minimalt sett med sikre pseudo-enheter (null, null, tilfeldig osv.). Hvis en disk trenger en spesifikk enhet (for eksempel en seriell port eller en diskblokk), kan den gis tillatelse ved å bruke `DeviceAllow=/dev/xxx rw` eller i skrivebeskyttet modus.

Nettverket er også en viktig vektor. Med Privatnettverk=true Et isolert nettverksnavneområde opprettes, og bare loopbacken blir igjen. Tjenesten vil ikke se fysiske grensesnitt og vil ikke kunne kommunisere med omverdenen. Alternativt kan du begrense hvilke adressefamilier den kan bruke ved å BegrensAdresseFamilies=tillater bare AF_INET og AF_INET6 for IPv4/IPv6, AF_UNIX for lokale sockets eller til og med none å fullstendig japanisere nettverkskapasiteter.

Når det gjelder privilegier, er direktivet `NoNewPrivileges=true` et av de kraftigste: det forhindrer prosessen i å tilegne seg nye privilegier gjennom setuid-binærfiler eller endringer i funksjonalitet. Kort sagt, selv om tjenesten kjører sårbar kode, skal den ikke kunne eskalere til root gjennom tradisjonelle mekanismer. Kombinert med `CapabilityBoundingSet=` , som definerer den nøyaktige listen over tillatte funksjoner (for eksempel at bare `CAP_NET_BIND_SERVICE` skal lytte på lave porter), minimeres angrepsflaten.

For å gå enda lenger, tillater systemd filtrering av systemkall med Systemanropsfilter=I stedet for å vedlikeholde en manuell liste over systemanrop, brukes forhåndsdefinerte grupper, for eksempel @system-service, @network-io, @basic-io eller nekte grupper som ~@privileged. Med systemd-analysere syscall-filter Det er mulig å inspisere hvilke spesifikke anrop som tilhører hver gruppe. Dette gir mulighet for konstruksjon av en svært begrenset utførelsesprofil, likt det en dedikert sandkasse ville tilby.

Andre relevante innstillinger inkluderer `ProtectKernelTunables=true` , som blokkerer endring av kjerneparametere i `/proc/sys` og `/sys`; `ProtectKernelModules=true` , som forhindrer lasting eller lossing av moduler; `ProtectKernelLogs=true` , som forhindrer lesing av kjernelogger; og `ProtectControlGroups=true` , som blokkerer skriving til cgroups-hierarkiet. Alt dette fungerer sømløst med nye brukerisoleringsfunksjoner som ` PrivateUsers=full` , som i versjon 260 er oppdatert for å kartlegge hele spekteret av bruker-ID-er, og eliminerer tidligere løsninger som var nødvendige for nestede systemd-miljøer.

PrivateUsers, xaccess og nye tilgangskontroller for enheter

PrivateUsers- mekanismen , som er utformet for å tillate tjenester å kjøre i et isolert bruker-ID-område, er konsolidert i systemd 260. Alternativet PrivateUsers=full kartlegger nå hele spekteret av identifikatorer, noe som forenkler ting i containere og på systemer med nestede systemd-instanser basert på eldre versjoner (før 257). Denne forbedringen har eliminert hacking som tidligere ble brukt til å oppdage disse eldre instansene.

Parallelt introduserte komponenter som systemd-logind og systemd-udevd konseptet xaccess . Denne mekanismen utfyller den klassiske logikken til uaccess , som gir tilgang til bestemte enheter (for eksempel lyd eller video) til brukere med grafikkøkter i forgrunnen på den lokale maskinen. Med xaccess kan tillatelser delegeres til eksterne brukere med spesielt merkede økter , slik at for eksempel en bruker som er koblet til via eksternt skrivebord, kan få tilgang til lokale GPU-gjengivelsesenheter uten å gi brede tillatelser til hele systemet.

Konfigurasjonen av disse øktene involverer miljøvariabler eksponert via PAM, nærmere bestemt PAMXDG_SESSION_EXTRA_DEVICE_ACCESS= , som gjør det mulig å definere hvilke spesifikke enheter som er inkludert i denne logikken. Denne tilnærmingen er i høy grad i tråd med kravene til regelverkssamsvar og databeskyttelse i EU, der granularitet og sporbarhet kreves for tilgang til sensitiv maskinvare.

mstack, systemd-mstack og nye containerverktøy

Innen containerisering introduserer systemd 260 funksjonaliteten mstack og en tilhørende kommando, systemd-mstackIdeen bak mstack er å tillate å definere en OverlayFS basert på strukturen til en spesiell katalog kalt .mstack/, som følger en spesifikk spesifikasjon for å organisere lagene sine.

Det nye kommandolinjeverktøyet, systemd-mstack, gjør det enklere å jobbe interaktivt med disse filsystemstablene, noe som gir fleksibilitet når man setter opp lagdelte miljøer for containere eller svært isolerte tjenester. Denne funksjonaliteten er også knyttet til forbedringer i systemd-importd , som utvider støtten for nedlasting og administrasjon av OCI-bilder , og dermed forsterker systemds rolle som en containeriserings- og sandboksmotor, noe som er veldig vanlig blant europeiske skyleverandører og moderne hostingplattformer.

Nettverk: Integrasjon med ModemManager og nye ytelsesalternativer

På nettverkslaget fortsetter systemd-networkd å få større betydning. En av de bemerkelsesverdige nye funksjonene er integrasjonen med ModemManager via "simple connect"-protokollen , som lar modemer og mobiltilkoblinger administreres direkte fra networkd uten å være avhengig av eksterne verktøy.

For å støtte denne flyten er en ny seksjon lagt til. til konfigurasjonsfilene, med parametere som APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=Dette forenkler utplasseringer i landlige områder eller miljøer med tilkobling basert på mobilnettverk, svært tilstede i visse områder i Europa hvor det ikke alltid er fiber eller fasttelefoner av god kvalitet.

Når det gjelder ytelse, inkluderer systemd-networkd .link -filene nye alternativer spesielt for Ethernet-enheter. Disse inkluderer ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList og GenericReceiveOffloadUDPForwarding . Disse alternativene muliggjør finjustering av avlasting av arbeid til maskinvare og drivere, noe som er avgjørende i bedriftsnettverk, datasentre og tjenesteleverandører som trenger å minimere hvert millisekund med ventetid.

Videre kan systemd-networkds Varlink- og JSON- grensesnitt nå rapportere IP-adresser i et menneskelig lesbart format (strenger) samtidig som representasjonen opprettholdes som en heltallsmatrise. Dette forenkler integrasjon med overvåkingsdashboards, administrasjonsskript eller tredjepartsverktøy som ikke ønsker å håndtere uintuitive numeriske formater.

Tjenesteportabilitet, flyktige virtuelle maskiner og uprivilegerte tjenester

Systemd-portabled- komponenten , som er ansvarlig for å administrere "bærbare" tjenester pakket i avbildninger, får en svært interessant funksjon: den kan nå kjøres som en tjeneste på brukernivå . Dette betyr at uprivilegerte brukere, i sin normale økt, kan starte og administrere bærbare tjenester i sitt eget område uten å ty til sudo eller utvidede rettigheter.

Videre, fra og med denne versjonen, kan portabled generere policyer og låse imaget som er knyttet til en portabel tjeneste , noe som forhindrer endring av imaget uten å koble det til på nytt. Dette lar brukere sette opp selvstendige miljøer med ekstra uforanderlighetsgarantier, en spesielt attraktiv funksjon for laboratorier, utviklingsmiljøer og testsandkasser.

På den annen side utvider systemd-vmspawn – verktøyet som er utviklet for å starte virtuelle maskiner på en integrert måte med systemd – mulighetene til å registrere seg med systemd-machined i brukerøkten . Det introduserer også et `-ephemeral` -alternativ for å opprette flyktige maskiner som ødelegges når de er ferdige med bruken. Dette passer perfekt for CI/CD-pipelines, virtuelle klasserom eller europeiske utdanningsplattformer som krever rask og kontrollert opprettelse og ødeleggelse av virtuelle maskiner.

Finjustert kontroll av CPU, minne og planlegging med SCHED_EXT og THP

Systemd 260 fordyper seg også i ytelseskontroll med nye policyer. Tjenestealternativet CPU-planleggingspolicy = nå aksepterer du verdien ext, som aktiverer planleggeren SCHED_EXTDenne alternative planleggeren åpner døren for eksperimenter med ulike planleggingspolitikker til kjernestandardene, noe som kan være av interesse i FoU-laboratorier eller i høyspesialiserte distribusjoner.

I minneområdet finner du `MemoryTHP=` , som lar deg administrere bruken av Transparent Huge Pages (THP) på en per-tjeneste-basis. I stedet for en systemomfattende, global innstilling, kan du bestemme om en bestemt enhet skal bruke THP, deaktivere den eller ta i bruk mellomliggende moduser. For kritiske applikasjoner innen bank, forsikring eller offentlig sektor kan denne detaljerte kontrollen utgjøre en betydelig forskjell i ventetid, minneforbruk og ytelse.

Nye kommandoer i systemctl og utvidet bruk av Varlink

Den kjente systemctl- kommandoen får en ny kommando: enqueue-marked . Denne handlingen kaller internt D-Bus-metoden EnqueueMarkedJobs() og tillater arbeid med køer av forhåndsmerkede jobber og tjenester. Selv om det kan virke som en liten detalj, er det et annet verktøy for å forbedre distribusjons- og automatiseringsarbeidsflyter for driftsteam som orkestrerer store serverfarmer .

Parallelt fortsetter prosjektet å utvide bruken av Varlink som en kommunikasjonsmekanisme mellom komponenter. Mange deler av systemd eksponerer stabile Varlink-grensesnitt, som forenkler integrering med eksterne verktøy, tilpassede dashbord eller overvåkingsagenter som krever strukturert tilgang til systeminformasjon.

Systemidentifikasjonsfelt og brukeropplevelse

En merkelig, men nyttig ny funksjon for noen distribusjoner er introduksjonen av feltet FANTASTISK_NAVN= i arkivet /etc/os-releaseDette feltet ligner på PRETTY_NAME, men tillater ANSI-sekvenser og mer forseggjorte Unicode-tegnTakket være dette kan spesifikke distribusjoner og utgaver presenteres med mer iøynefallende eller særegne navn.

Verdien til FANCY_NAME kan sees via systemd-behandleren, ved å bruke systemd-hostnamed eller ved å spørre hostnamectl . Selv om det er en liten endring, kan det i skrivebordsmiljøer og grafiske administrasjonspaneler være nyttig for raskt å identifisere systemet som administreres, spesielt når man håndterer mange avledede varianter.

Spesifikk dokumentasjon for AI-agenter og assistert gjennomgangsarbeidsflyt

Et av de mest interessante tegnene på retningen systemds utvikling tar, er fremveksten av dokumentasjon spesielt rettet mot kunstig intelligens-agenter . Arkivet inneholder en AGENTS.md -fil , designet for å hjelpe kodeanalyseverktøy og programmeringsassistenter, samt noen teknologiguider , med å bedre forstå prosjektets arkitektur, stil, utviklingsflyt og retningslinjer for bidrag.

Dette dokumentet beskriver komponenter, byggebaner, hvordan man kjører tester og integrasjoner, og retningslinjer for å generere akseptable oppdateringer. Hensikten er å gi AI-agenter som gjennomgår kode eller gjør endringer en solid forståelse av hvordan systemd er organisert , noe som reduserer feil og feilplasserte forslag.

Ved siden av AGENTS.md finnes det en fil kalt CLAUDE.md , som eksplisitt refererer til førstnevnte og er utformet for å veilede Claude Code-verktøyet, en av de mest brukte AI-baserte utviklingsassistentene. På denne måten integrerer prosjektet eksplisitt AI i utviklingssyklusen.

I tillegg er en konfigurasjonsfil inkludert. claude-review.ymlder det defineres hvordan prosessen med å analysere endringsforespørsler (pull requests) skal gjennomgås, ved hjelp av Claude Code. I denne sammenhengen er bidrag som har brukt AI pålagt å innlemme avsløringsetiketter som Co-developed-by i oppdateringene, og etterlater bevis på at et automatisert verktøy har deltatt i opprettelsen av koden.

Med dette omfattende settet med endringer – opprydding av eldre støtte, forbedring av sandkassefunksjoner, forbedring av TPM2 og SRK, avansert nettverksintegrasjon, nye portabilitetsmuligheter og dokumentasjon utviklet for intelligente agenter – forsterker systemd 260 sin sentrale rolle i det moderne Linux-økosystemet. For administratorer og utviklere i Spania og Europa ligger den umiddelbare utfordringen i å gjennomgå kjerner, tilpasse oppstartskonfigurasjoner og tjenester, og utnytte disse funksjonene for å bygge sikrere, automatiserte infrastrukturer i tråd med gjeldende systembruk.