Systemd 260: TPM2, sandboxing og nye funktioner i Linux

Hardwarevejledning » Købsvejledninger » Systemd 260: TPM2, sandboxing og nye funktioner i Linux

Med ankomsten af systemd 260 Linux-distributioner tager endnu et vigtigt skridt mod et mere moderne og sikkert økosystem rettet mod cloud-miljøer, virtualisering og automatisering. Denne version finpudser ikke kun detaljerne: den introducerer betydelige ændringer til opstart, servicestyring, netværk, brugen af ​​TPM2 til integritet og kryptering samt sandboxing-funktioner på drevniveau.

Samtidig styrker projektet sin dokumentation og sin arbejdsmetode. agenter til kunstig intelligensDette gør det klart, at systemd er en kritisk søjle, som flere og flere udviklings- og observationsværktøjer forbinder sig til. Hvis du administrerer Linux-systemer på servere, i skyen, på virksomhedens desktops eller i laboratorier, er det værd at tage et øjeblik til at gennemgå alle disse nye funktioner for at planlægge opdateringer og konfigurationsjusteringer.

Et endeligt farvel til System V og total afhængighed af native drev

En af de mest slående ændringer i systemd 260 er fuldstændig tilbagetrækning af support til System V-scriptsDen klassiske opstartsproces baseret på /etc/init.d har været i færd med at blive udfaset i årevis, men nu forsvinder den effektivt fra systemd-koden.

Det betyder, at de komponenter, der er ansvarlige for at bygge bro mellem SysV-scripts og native enheder, er blevet fjernet: systemd-rc-local-generator, rc-local.service, systemd-sysv-generator og systemd-sysv-install De ophører med at eksistere. Som følge heraf vil enhver tjeneste, der stadig er afhængig af disse ældre mekanismer, simpelthen ikke starte på systemer, der anvender SystemD 260.

Under oprydningsprocessen er flere Meson-byggemuligheder også blevet markeret som forældede eller fjernet. -Drc-local=, -Dsysvinit-path= og -Dsysvrcnd-path= nogle er henvist til mindernes bagagerum, mens andre som -Dintegrationstests= og -Dcryptolib= De fjernes direkte. Det er et klart budskab: alt skal gå gennem native enheder og den moderne systemd-infrastruktur.

For mange europæiske infrastrukturer, der stadig er afhængige af ældre komponenter, nødvendiggør denne ændring en gennemgang af interne tjenester, brugerdefinerede scripts og ældre implementeringer. Migrering til veldefinerede enhedsfiler anbefales ikke længere kun; det er obligatorisk, hvis du vil fortsætte med at køre tjenester på distributioner, der integrerer systemd 260.

Højere kernekrav og fokus på nuværende miljøer

Den nye version hæver barren for kernen: fra nu af, den Den mindst understøttede Linux-version er 5.10efterlader meget gamle grene som 5.4. Derudover indikerer projektet, at idealet er at arbejde på en kerne 5.14 eller højereog anbefaler især 6.6-serien at udnytte alle tilgængelige funktioner.

Denne stigning i krav er normalt ikke et problem i moderne distributioner, men det kan komplicere tingene i meget konservative miljøer eller i indlejrede løsninger, der er vedligeholdt i mange år. Før du opgraderer til systemd 260, er det tilrådeligt at kontrollere, hvilken kerne der bruges, især i Europæiske datacentre med langsigtede implementeringer eller i brugerdefinerede billeder.

I den modsatte ende af spektret har rullende udgivelsesdistributioner som Arch Linux eller openSUSE Tumbleweed, der er meget populære blandt dem, der ønsker de nyeste funktioner, en tendens til hurtigt at inkorporere både nye kerner og nye grene af systemd. Andre, som Fedora, opretholder en vis grad af stabilitet i den overordnede version af systemd gennem hele livscyklussen for hver udgivelse, hvilket giver lidt mere tid til at planlægge migreringer.

TPM2, bootintegritet og avanceret SRK-understøttelse

Et af de områder, hvor systemd udvikler sig mest, er i dets integration med TPM2 (Trusted Platform Module 2.0)Denne chip, der bliver mere og mere almindelig i moderne UEFI-bundkort og hardware i mellemklassen og high-end, giver dig mulighed for at forankre hemmeligheder til systemtilstanden, måle opstartsfaser og låse op for krypterede volumener automatisk, når miljøet er som forventet.

Systemd 260 forbedrer denne integration yderligere ved at tilføje værktøjer og tjenester, der dækker forskellige faser af opstartsprocessen. En nøglekomponent er... systemd-tpm2-opsætning, ansvarlig for at forberede infrastrukturen omkring Lagerrodnøgle (SRK) af TPM'en. Denne rodnøgle fungerer som det kryptografiske fundament for at sikre kommunikationen med chippen og for sikker lagring af andre hemmeligheder.

Under opstart kan der skelnes mellem to faser: en meget tidlig i initrd og en anden i rodsystemet. I den første kontrollerer en tjeneste kaldet "Early TPM SRK Setup", om TPM'en allerede har en gemt SRK, og hvis den ikke findes, opretter den den og gør den midlertidigt tilgængelig under /run/systemd/tpm2-srk-offentlig-nøgle.*Senere, når det faktiske filsystem er monteret, vil tjenesten konsolidere SRK'en og verificere, at nøglen er gemt i /var/lib/systemd/tpm2-srk-public-key.pem Det stemmer overens med den i TPM.

I velkonfigurerede scenarier ses journalposter som disse. "SRK er allerede gemt i TPM" og meddelelser, der angiver, at SRK-fodaftrykket matcher det forventede. Hvis miljøet derimod ikke er justeret (for eksempel i opsætninger med Yocto eller på boards som Raspberry Pi med SPI TPM og brugerdefinerede boot-metoder med U-Boot og målt boot), kan der opstå situationer, hvor systemd ikke opretter disse filer under /var/lib/systemd, hvilket rejser tvivl om, hvorvidt SRK er konfigureret korrekt.

Når TPM-tilstanden er ændret, partitioner er blevet modificeret, eller opstartsprocessen er blevet ændret, er den tilhørende politik muligvis ikke længere gældende. I sådanne tilfælde anbefaler nogle vedligeholdere Ryd TPM-pladsen eller -politikken, og registrer nøglen igen, efter procedurer svarende til dem, der er beskrevet i diskkrypteringsvejledninger med TPM i miljøer som openSUSE, hvor det er detaljeret beskrevet, hvordan man genskaber PCR-politikken og gentilknytter oplåsning af volumen.

Udover SRK er en anden praktisk forbedring introduktionen i udev af et internt værktøj kaldet tpm2_idDette integrerede værktøj kører, når systemet registrerer en TPM2-enhed og Den udtrækker automatisk producentens identifikator og model.Dette forenkler opgørelsen over sikkerhedshardware, hvilket er meget nyttigt i offentlige forvaltninger, regulerede virksomheder eller kritiske infrastrukturer, hvor det er nødvendigt at vide præcis, hvilke TPM-moduler der er implementeret.

Integrationen med startup-målingsinfrastrukturen er også forstærket med specifikke enheder som f.eks. systemd-pcrextendsom logger hændelser som "enter-initrd", "leave-initrd", "sysinit" eller "ready" i forskellige PCR'er (f.eks. PCR 11). Denne sekvens af udvidelser gør det muligt for TPM'en at akkumulere en kryptografisk verificerbar registrering af bootflowet, som derefter kan bruges til Trusted Boot-politikker eller til UKI (Unified Kernel Images) der validerer maskinens status, før nøglerne frigives.

Sikkerhedsforanstaltninger og sandboxing af tjenester med systemd

Systemd starter ikke kun processer: det tilbyder også et meget omfattende sæt af sandboxing-direktiver at isolere tjenester og begrænse skade i tilfælde af kompromittering. Denne "dybdegående forsvars"-tilgang er afhængig af cgroups, navnerum, kernefunktioner og systemkaldsfiltre (seccomp).

For at vurdere status for en specifik tjeneste inkluderer systemd værktøjet systemd-analyser sikkerhedNår den køres, genererer den en rapport med et eksponeringsindeks på en skala fra 0 til 10, hvor lavere er bedre. Rapporten opdeler aktiverede eller manglende beskyttelser (netværksisolering, adgang til filsystemet, enheder osv.), hvilket gør det meget nemt at opdage sårbarheder. hvilke justeringer er nødvendige og tjek om de introducerede ændringer rent faktisk forbedrer scoren.

I stedet for at redigere den oprindelige enhed – som ville gå tabt i fremtidige pakkeopdateringer – anbefales det at oprette en overstyring en /etc/systemd/system/mi-servicio.service.d/ med en fil, for eksempel sandbox.confEfter at have ændret den, skal du blot genindlæse konfigurationen med systemctl daemon-reload og genstart tjenesten, så de nye restriktioner træder i kraft.

På filsystemniveau er en af ​​de vigtigste muligheder BeskytSystem=Værdier som f.eks. strict, full o true De monterer forskellige dele af træet i skrivebeskyttet tilstand. Den sædvanlige praksis, når det er muligt, er at bruge BeskytSystem=strengDette gør /usr, /boot, /efi og /etc skrivebeskyttede for tjenesten. Hvis et program skal skrive til bestemte mapper, er det tilladt at gøre det ved hjælp af Læse- og skrivestier =/sti i enhed.

For yderligere at forbedre privatlivets fred anbefales det også at begrænse adgangen til brugermapper via BeskytHjem=sandhvilket forhindrer tjenesten i at læse /home, /root eller /run/user. Desuden, PrivatTmp=sand Det opretter et isoleret /tmp- og /var/tmp-rum, hvilket forhindrer krydssynlighed af midlertidige filer mellem processer.

På enheder, PrivateEnheder=sand Den skjuler det faktiske /dev-træ og erstatter det med et minimalt sæt af sikre pseudo-enheder (null, zero, random osv.). Hvis en enhed har brug for en specifik enhed (for eksempel en seriel port eller en diskblok), kan den tildeles ved hjælp af EnhedsTillad=/dev/xxx rw eller i skrivebeskyttet tilstand.

Netværket er også en vigtig vektor. Med Privatnetværk=sandt Et isoleret netværksnavneområde oprettes, hvor kun loopback'en er tilbage; tjenesten vil ikke se fysiske grænseflader og vil ikke være i stand til at kommunikere med omverdenen. Alternativt kan du begrænse, hvilke adressefamilier den kan bruge, ved at RestrictAddressFamilies=tillader kun AF_INET og AF_INET6 for IPv4/IPv6, AF_UNIX for lokale sockets eller endda none at japanisere netværksfunktioner fuldt ud.

Vedrørende privilegier, direktivet IngenNyePrivilegier=sand Det er et af de mest kraftfulde: det forhindrer processen i at tilegne sig nye privilegier via setuid-binære filer eller ændringer i funktionalitet. Kort sagt, selvom tjenesten udfører sårbar kode, bør den ikke være i stand til at eskalere til root via traditionelle mekanismer. Kombineret med CapabilityBoundingSet=Ved at definere den nøjagtige liste over tilladte funktioner (f.eks. kun CAP_NET_BIND_SERVICE til at lytte på lave porte), minimeres angrebsfladen.

For at gå endnu længere tillader systemd filtrering af systemkald med SystemCallFilter=I stedet for at vedligeholde en manuel liste over syscalls, bruges foruddefinerede grupper, såsom @system-service, @network-io, @basic-io eller afvis grupper som ~@privileged. Med systemd-analyser syscall-filter Det er muligt at inspicere hvilke specifikke kald der tilhører hver gruppe. Dette muliggør konstruktionen af ​​en meget begrænset udførelsesprofil, svarende til hvad en dedikeret sandkasse ville tilbyde.

Andre relevante justeringer er BeskytKernelTunables=sand, som blokerer ændringen af ​​kerneparametre i /proc/sys og /sys, BeskytKernelModuler=sandsom forhindrer indlæsning eller aflæsning af moduler, BeskytKernelLogs=sandhvilket forhindrer læsning af kerneregistre, og BeskytKontrolGrupper=sandhvilket blokerer skrivninger til cgroups-hierarkiet. Alt dette kombineres problemfrit med nye brugerisoleringsfunktioner såsom PrivateBrugere=fuld, som i version 260 er opdateret til at kortlægge hele spektret af bruger-ID'er, hvilket eliminerer tidligere løsninger, der var nødvendige for miljøer med indlejret systemd.

PrivateUsers, xaccess og nye enhedsadgangskontroller

Mekanismen PrivateBrugereDen er designet til at køre tjenester i et isoleret bruger-ID-område og er konsolideret i systemd 260. Muligheden PrivateBrugere=fuld Den kortlægger nu hele spektret af identifikatorer, hvilket forenkler tingene i containere og på systemer med indlejrede systemd-instanser baseret på ældre versioner (før 257). Denne forbedring har elimineret hacks, der blev brugt til at detektere disse ældre instanser.

Parallelt med dette anvendes komponenter som f.eks. systemd-logind og systemd-udevd De lancerer konceptet med xaccessDenne mekanisme supplerer den klassiske logik bag uaccessxaccess giver adgang til bestemte enheder (f.eks. lyd eller video) til brugere med grafiske sessioner i forgrunden på den lokale maskine. Tilladelser kan delegeres til xaccess. fjernbrugere med specielt markerede sessionersåledes at for eksempel en bruger, der er forbundet via fjernskrivebord, kan få adgang til lokale GPU-renderingsenheder uden at give brede tilladelser til hele systemet.

Konfigurationen af ​​disse sessioner involverer miljøvariabler, der eksponeres via PAM, specifikt PAMXDG_SESSION_EXTRA_DEVICE_ACCESS=Dette gør det muligt at definere, hvilke specifikke enheder der falder ind under denne ramme. Det er en tilgang, der er i høj grad i overensstemmelse med EU's krav til overholdelse af lovgivningen og databeskyttelse, som kræver granularitet og sporbarhed i forbindelse med adgang til følsom hardware.

mstack, systemd-mstack og nye containerværktøjer

Inden for containerisering introducerer systemd 260 funktionaliteten mstack og en tilhørende kommando, systemd-mstackIdeen bag mstack er at give mulighed for at definere en OverlayFS baseret på strukturen af ​​en særlig mappe kaldet .mstack/, som følger en specifik specifikation for organisering af sine lag.

Det nye kommandolinjeværktøj, systemd-mstack, gør det nemmere at arbejde interaktivt med disse filsystem-"stacks", hvilket giver fleksibilitet ved opsætning af lagdelte miljøer til containere eller stærkt isolerede tjenester. Denne funktionalitet er også knyttet til forbedringer i systemd-importeret, som udvider sin støtte til Download og administrer OCI-billederDette forstærker systemds rolle som containeriserings- og sandboxing-motor, noget der er meget almindeligt hos europæiske cloud-udbydere og moderne hostingplatforme.

Netværk: Integration med ModemManager og nye ydeevnemuligheder

På netværkslaget fortsætter systemd-networkd med at vinde betydning. En af dens bemærkelsesværdige nye funktioner er dens integration med ModemManager ved hjælp af "simple connect"-protokollenDette giver dig mulighed for at administrere modemer og mobilforbindelser direkte fra networkd uden at være afhængig af eksterne værktøjer.

For at understøtte dette flow er der tilføjet et nyt afsnit. til konfigurationsfilerne med parametre som f.eks. APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=Dette letter implementeringer i landdistrikter eller miljøer med forbindelse baseret på mobilnetværk, meget til stede i visse områder i Europa, hvor der ikke altid er fiber eller fastnettelefoner af god kvalitet.

Med hensyn til ydeevne, filerne .link systemd-networkd inkorporerer nye muligheder specifikt til Ethernet-enheder. Blandt dem er: ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList og GenericReceiveOffloadUDPForwardingDisse muligheder giver mulighed for finjustering af overførslen af ​​arbejde til hardware og drivere, noget der er afgørende i virksomhedsnetværk, datacentre og tjenesteudbydere, der har brug for at minimere hvert millisekund af latenstid.

Desuden er grænsefladerne Varlink og JSON systemd-networkd kan nu rapportere IP-adresser i et format menneskelæsbar (strenge), samtidig med at repræsentationen bevares som et array af heltal. Dette forenkler integrationen med overvågningsdashboards, administrationsscripts eller tredjepartsværktøjer, der ikke ønsker at håndtere uintuitive numeriske formater.

Tjenesteportabilitet, kortvarige virtuelle maskiner og uprivilegerede tjenester

Stykket systemd-bærbarSoftwaren, der er ansvarlig for at administrere "bærbare" tjenester pakket i billeder, får en meget interessant funktion: den kan køre som en brugerniveautjenesteDet betyder, at ikke-privilegerede brugere i deres normale session kan starte og administrere bærbare tjenester i deres eget område uden at ty til sudo eller forhøjede rettigheder.

Desuden kan bærbare, startende med denne version generere politikker og etablere det image, der er knyttet til en bærbar tjenesteDette forhindrer, at billedet ændres uden at det skal vedhæftes igen. Brugere kan således oprette selvstændige miljøer med ekstra garantier for uforanderlighed, hvilket er ret attraktivt for laboratorier, udviklingsmiljøer og testsandkasser.

Endvidere systemd-vmspawn —værktøjet designet til at starte virtuelle maskiner på en integreret måde med systemd— udvider sine muligheder for at registrere i systemd-maskineret i brugersessionenDen introducerer også en mulighed –flygtig at skabe flygtige maskiner, der destrueres, når de ikke længere er brugt. Dette passer perfekt til CI/CD-pipelines, virtuelle klasseværelser eller europæiske uddannelsesplatforme, der kræver at løfte og trække maskiner hurtigt og kontrolleret.

Finjusteret kontrol af CPU, hukommelse og planlægning med SCHED_EXT og THP

Systemd 260 fordyber sig også i ydeevnekontrol med nye politikker. Servicemuligheden CPU-planlægningspolitik= accepter nu værdien ext, som aktiverer planlæggeren SCHED_EXTDenne alternative planlægger åbner døren til eksperimenter med forskellige planlægningspolitikker til kernestandarderne, noget der kan være af interesse i forsknings- og udviklingslaboratorier eller i højt specialiserede implementeringer.

I hukommelsesområdet vises HukommelseTHP=hvilket giver mulighed for at styre brugen af Gennemsigtige store sider (THP) pr. tjeneste. I stedet for at have en global adfærd for hele systemet, kan det besluttes, om en specifik enhed skal udnytte THP, deaktivere det eller anvende mellemliggende tilstande. For kritiske applikationer inden for bank, forsikring eller offentlig administration kan denne granulære kontrol gøre en forskel i latenstid, hukommelsesforbrug og ydeevne.

Nye kommandoer i systemctl og udvidet brug af Varlink

Den velkendte kommando systemctl vinder en ny ordre: enqueue-markeretDenne handling aktiverer internt D-Bus-metoden. SætMarkedJobs i kø() og giver mulighed for at arbejde med køer af forudvalgte job og tjenester. Selvom dette kan virke som en mindre detalje, er det afgørende for driftsteams, der orkestrerer storskala serverfarme Det er endnu et værktøj til at forfine implementerings- og automatiseringsarbejdsgange.

Parallelt fortsætter projektet med at udvide brugen af Varlink som en kommunikationsmekanisme mellem komponenter. Mange dele af systemd eksponerer stabile Varlink-grænseflader, som letter integration med eksterne værktøjer, brugerdefinerede dashboards eller overvågningsagenter, der har brug for struktureret adgang til systeminformation.

Systemidentifikationsfelter og brugeroplevelse

En kuriøs, men nyttig ny funktion for nogle distributioner er introduktionen af ​​feltet FANCY_NAME= i arkivet /etc/os-releaseDette felt ligner PRETTY_NAME, men tillader ANSI-sekvenser og mere detaljerede Unicode-tegnTakket være dette kan specifikke distributioner og udgaver præsenteres med mere iøjnefaldende eller karakteristiske navne.

Værdien af ​​FANCY_NAME kan ses via systemd manager ved hjælp af systemd-værtnavn eller når man konsulterer hostnamectlSelvom det er en lille ændring, kan det være nyttigt i skrivebordsmiljøer og grafiske administrationspaneler. Identificér systemet med et hurtigt blik der håndteres, især når man har med mange afledte varianter at gøre.

Specifik dokumentation for AI-agenter og assisteret gennemgangsworkflow

Et af de mest interessante tegn på, hvor systemudvikling er på vej hen, er fremkomsten af ​​dokumentation, der specifikt er rettet mod agenter til kunstig intelligensEn fil er inkluderet i arkivet AGENTER.mddesignet til kodeanalyseværktøjer og programmeringsassistenter, og som nogle har bemærket teknologiguider, bedre forstå projektets arkitektur, stil, udviklingsflow og retningslinjer for bidrag.

Dette dokument beskriver komponenter, byggestier, hvordan man kører tests og integrationer, og retningslinjer for generering af acceptable programrettelser. Hensigten er, at AI-agenter, der gennemgår kode eller genererer ændringer, kan arbejde med dem. en solid kontekst for, hvordan systemd er organiseretreducere fejl og forkerte forslag.

Ved siden af ​​AGENTS.md vises en fil kaldet CLAUDE.mdDette refererer eksplicit til den første og fokuserer på at guide Claude Code-værktøjet, en af ​​de mest anvendte AI-baserede udviklingsassistenter. På denne måde inkorporerer projektet eksplicit AI i sin udviklingscyklus.

Derudover er en konfigurationsfil inkluderet. claude-review.ymlhvor det er defineret, hvordan processen med at analysere ændringsanmodninger (pull requests) skal gennemgås, ved hjælp af Claude Code. I denne sammenhæng skal bidrag, der har brugt AI, inkorporere afsløringsetiketter som Co-developed-by i programrettelserne, hvilket efterlader bevis for, at et automatiseret værktøj har deltaget i oprettelsen af ​​koden.

Med alle disse ændringer – oprydning af ældre understøttelse, sandboxing-forfinelser, forbedringer af TPM2 og SRK, avanceret netværksintegration, nye portabilitetsfunktioner og dokumentation designet til intelligente agenter – systemd 260 Dette styrker dets centrale rolle i det moderne Linux-økosystem. For administratorer og udviklere i Spanien og Europa involverer den umiddelbare udfordring at gennemgå kerner, tilpasse bootkonfigurationer og -tjenester og udnytte disse funktioner til at bygge mere sikre, automatiserede infrastrukturer, der er afstemt med den nuværende systembrug.