Systemd 260: TPM2, sandboxing a nové možnosti v Linuxe

Sprievodca hardvérom » Sprievodcovia nákupom » Systemd 260: TPM2, sandboxing a nové možnosti v Linuxe

S príchodom systemd 260 robia linuxové distribúcie ďalší dôležitý krok smerom k modernejšiemu a bezpečnejšiemu ekosystému zameranému na cloudové prostredia, virtualizáciu a automatizáciu. Táto verzia nielen vylepšuje detaily: zavádza významné zmeny v bootovaní, správe služieb, sieťovaní, používaní TPM2 pre integritu a šifrovanie a v možnostiach sandboxu na úrovni disku.

Zároveň projekt posilňuje svoju dokumentáciu a prístup k práci s agentmi umelej inteligencie , čím jasne uvádza, že systemd je kľúčovým pilierom, ku ktorému sa pripája stále viac a viac nástrojov na vývoj a sledovanie. Ak spravujete systémy Linux na serveroch, v cloude, na firemných počítačoch alebo v laboratóriách, oplatí sa si na chvíľu preštudovať všetky tieto nové funkcie a naplánovať aktualizácie a úpravy konfigurácie.

Konečné zbohom Systemu V a úplná závislosť od natívnych diskov

Jednou z najvýraznejších zmien v systemd 260 je úplné odstránenie podpory pre skripty System V. Klasický proces zavádzania založený na /etc/init.d bol roky postupne ukončený, ale teraz v podstate zmizol z kódu systemd.

To znamená, že komponenty zodpovedné za prepojenie medzi skriptami SysV a natívnymi jednotkami boli odstránené: systemd-rc-local-generator, rc-local.service, systemd-sysv-generator a systemd-sysv-install už neexistujú. V dôsledku toho sa žiadna služba, ktorá stále závisí od týchto starších mechanizmov, jednoducho nespustí na systémoch, ktoré používajú systemd 260.

Počas procesu čistenia bolo niekoľko možností zostavenia Meson označených ako zastarané alebo odstránené. Príznaky -Drc-local=, -Dsysvinit-path= a -Dsysvrcnd-path= boli presunuté do archívov, zatiaľ čo iné, ako napríklad -Dintegration-tests= a -Dcryptolib=, boli úplne odstránené. Toto vysiela jasný signál: všetko musia teraz spravovať natívne jednotky a moderná infraštruktúra systemd.

Pre mnohé európske infraštruktúry, ktoré sa stále spoliehajú na staršie komponenty, si táto zmena vyžaduje revíziu interných služieb, vlastných skriptov a starších nasadení. Migrácia na dobre definované súbory jednotiek sa už nielen odporúča; je povinná, ak chcete naďalej prevádzkovať služby na distribúciách, ktoré integrujú systemd 260.

Vyššie požiadavky na jadro a zameranie na súčasné prostredia

Nová verzia zvyšuje latku pre jadro: odteraz je minimálna podporovaná verzia Linuxu 5.10 , čím sa zaostáva za veľmi starými vetvami ako 5.4. Projekt ďalej naznačuje, že ideálne by používatelia mali pracovať na jadre 5.14 alebo vyššom , a najmä odporúča sériu 6.6, aby sa naplno využili všetky dostupné funkcie.

Toto zvýšenie požiadaviek zvyčajne nie je problémom v moderných distribúciách, ale môže to veci skomplikovať vo veľmi konzervatívnych prostrediach alebo v embedded riešeniach udržiavaných dlhé roky. Pred aktualizáciou na systemd 260 je vhodné overiť, ktoré jadro sa používa, najmä v európskych dátových centrách s dlhodobým nasadením alebo vlastnými obrazmi.

Na opačnom konci spektra sú distribúcie s postupným vydávaním, ako napríklad Arch Linux alebo openSUSE Tumbleweed, veľmi populárne medzi tými, ktorí chcú najnovšie funkcie, a majú tendenciu rýchlo začleňovať nové jadrá aj nové vetvy systemd. Iné, ako napríklad Fedora, si udržiavajú určitý stupeň stability v hlavnej verzii systemd počas celého životného cyklu každého vydania, čo umožňuje o niečo viac času na plánovanie migrácií.

TPM2, integrita bootovania a pokročilá podpora SRK

Jednou z oblastí, kde sa systemd najviac vyvíja, je jeho integrácia s TPM2 (Trusted Platform Module 2.0) . Tento čip, čoraz bežnejší v moderných základných doskách UEFI a hardvéri strednej a vyššej triedy, umožňuje ukotvenie tajných údajov k stavu systému, meranie fáz zavádzania a automatické odomykanie šifrovaných zväzkov, keď je prostredie v očakávanom stave.

Systemd 260 túto integráciu ďalej vylepšuje pridaním nástrojov a služieb, ktoré pokrývajú rôzne fázy procesu zavádzania. Kľúčovým komponentom je systemd-tpm2-setup , ktorý je zodpovedný za prípravu infraštruktúry okolo koreňového kľúča úložiska (SRK) modulu TPM . Tento koreňový kľúč slúži ako kryptografický základ pre zabezpečenie komunikácie s čipom a pre bezpečné ukladanie ďalších tajomstiev.

Počas bootovania sa rozlišujú dve fázy: veľmi skorá v initrd a druhá v koreňovom systéme. V prvej fáze služba s názvom „Early TPM SRK Setup“ skontroluje, či TPM už má uložený SRK, a ak neexistuje, vytvorí ho a dočasne ho sprístupní v priečinku /run/systemd/tpm2-srk-public-key.* . Neskôr, po pripojení skutočného súborového systému, služba konsoliduje SRK a overí, či sa kľúč uložený v súbore /var/lib/systemd/tpm2-srk-public-key.pem zhoduje s kľúčom v TPM.

V dobre nakonfigurovaných scenároch sa zobrazia záznamy v denníku, ako napríklad „SRK je už uložený v TPM“ a správy, ktoré označujú, že stopa SRK zodpovedá očakávanej. Ak však prostredie nie je správne nakonfigurované (napríklad v nastaveniach používajúcich Yocto alebo na doskách ako Raspberry Pi s TPM založeným na SPI a vlastnými metódami bootovania, ako je U-Boot a merané bootovanie), môžu nastať situácie, keď systemd nedokáže vytvoriť tieto súbory v /var/lib/systemd, čo vyvoláva pochybnosti o tom, či bol SRK správne nakonfigurovaný.

Keď sa zmení stav TPM, upravia sa oddiely alebo sa zmení zavádzacia sekvencia, priradená politika už nemusí byť platná. V takýchto prípadoch niektorí správcovia odporúčajú vymazať slot alebo politiku TPM a znova zaregistrovať kľúč podľa postupov podobných tým, ktoré sú opísané v príručkách šifrovania diskov s TPM v prostrediach ako openSUSE, ktoré podrobne opisujú, ako znovu vytvoriť politiku PCR a znova prepojiť zväzok.

Okrem SRK je ďalším praktickým vylepšením zavedenie interného nástroja s názvom tpm2_id v udev . Tento integrovaný nástroj sa spustí, keď systém zistí zariadenie TPM2 a automaticky extrahuje identifikátor výrobcu a modelu . To zjednodušuje inventarizáciu bezpečnostného hardvéru, čo je veľmi užitočné vo verejnej správe, regulovaných spoločnostiach alebo kritických infraštruktúrach, kde je nevyhnutné presne vedieť, ktoré moduly TPM sú nasadené.

Integráciu s infraštruktúrou merania zavádzania ďalej posilňujú špecifické jednotky, ako napríklad systemd-pcrextend , ktoré zaznamenávajú udalosti ako „enter-initrd“, „leave-initrd“, „sysinit“ a „ready“ v rôznych PCR (napr. PCR 11). Táto postupnosť rozšírení umožňuje TPM zhromaždiť kryptograficky overiteľný záznam o toku zavádzania, ktorý sa potom môže použiť pre politiky dôveryhodného zavádzania alebo pre UKI (Unified Kernel Images) na overenie stavu počítača pred uvoľnením kľúčov.

Bezpečnostné opatrenia a sandbox služieb so systemd

Systemd nielenže spúšťa procesy, ale ponúka aj komplexnú sadu sandboxových direktív na izoláciu služieb a obmedzenie škôd v prípade kompromitácie. Tento prístup „hĺbkovej obrany“ sa spolieha na cgroups, menné priestory, možnosti jadra a filtre systémových volaní (seccomp).

Na posúdenie bezpečnosti konkrétnej služby obsahuje systemd bezpečnostný nástroj systemd-analyze . Jeho spustením sa vygeneruje správa so skóre expozície na stupnici od 0 do 10, kde nižšie skóre je lepšie. Správa rozoberá, ktoré ochrany sú povolené alebo zakázané (izolácia siete, prístup k súborovému systému, prístup k zariadeniam atď.), čo uľahčuje identifikáciu chýbajúcich nastavení a overenie, či zmeny skutočne zlepšujú skóre.

Namiesto úpravy pôvodnej jednotky – ktorá by sa pri budúcich aktualizáciách balíkov stratila – sa odporúča vytvoriť potlačenie en /etc/systemd/system/mi-servicio.service.d/ napríklad so súborom, sandbox.confPo úprave jednoducho znova načítajte konfiguráciu pomocou systemctl daemon-reload a reštartujte službu, aby sa nové obmedzenia prejavili.

Na úrovni súborového systému je jednou z najdôležitejších možností OchranaSystému=Hodnoty ako napríklad strict, full o true Rôzne časti stromu pripájajú v režime iba na čítanie. Zvyčajnou praxou, ak je to možné, je použiť ProtectSystem=prísneVďaka tomu sú adresáre /usr, /boot, /efi a /etc pre službu dostupné iba na čítanie. Ak aplikácia potrebuje zapisovať do konkrétnych adresárov, môže tak urobiť pomocou ReadWritePaths=/cesta v jednote.

Pre ďalšie zvýšenie súkromia sa odporúča obmedziť prístup k používateľským adresárom pomocou parametra `ProtectHome=true` , ktorý zabráni službe v čítaní adresárov `/home`, `/root` alebo `/run/user`. Okrem toho, parametra `PrivateTmp=true` vytvára izolované priestory `/tmp` a `/var/tmp`, čím zabraňuje vzájomnej viditeľnosti dočasných súborov medzi procesmi.

V zariadeniach `PrivateDevices=true` skryje skutočný strom `/dev` a nahradí ho minimálnou sadou bezpečných pseudo-zariadení (null, zero, random atď.). Ak disk potrebuje špecifické zariadenie (napríklad sériový port alebo blok disku), je možné ho udeliť pomocou `DeviceAllow=/dev/xxx rw` alebo v režime iba na čítanie.

Sieť je tiež kľúčovým vektorom. S SúkromnáSieť=true Vytvorí sa izolovaný sieťový menný priestor, pričom zostane iba spätná slučka; služba neuvidí fyzické rozhrania a nebude môcť komunikovať s vonkajším svetom. Prípadne môžete obmedziť, ktoré adresné rodiny môže používať, a to ObmedziťRodinyAdres=povolenie iba AF_INET a AF_INET6 pre IPv4/IPv6, AF_UNIX pre lokálne sockety alebo dokonca none plne japonizovať sieťové možnosti.

Pokiaľ ide o privilégiá, direktíva `NoNewPrivileges=true` je jednou z najúčinnejších: bráni procesu v získavaní nových privilégií prostredníctvom binárnych súborov setuid alebo zmien schopností. Stručne povedané, aj keď služba spustí zraniteľný kód, nemala by byť schopná eskalovať na root prostredníctvom tradičných mechanizmov. V kombinácii s `CapabilityBoundingSet=` , ktorá definuje presný zoznam povolených schopností (napríklad iba `CAP_NET_BIND_SERVICE` na počúvanie na portoch s nízkou úrovňou oprávnení), je minimalizovaná plocha pre útok.

Aby sme zašli ešte ďalej, systemd umožňuje filtrovanie systémových volaní pomocou FilterSystémovýchVolaní=Namiesto manuálneho udržiavania zoznamu systémových volaní sa používajú preddefinované skupiny, ako napríklad @system-service, @network-io, @basic-io alebo odmietnuť skupiny ako ~@privileged. S systemd-analyze syscall-filter Je možné skontrolovať, ktoré konkrétne volania patria do každej skupiny. To umožňuje vytvorenie veľmi obmedzeného profilu vykonávania, podobne ako by ponúkal vyhradený sandbox.

Medzi ďalšie relevantné nastavenia patrí `ProtectKernelTunables=true` , ktoré blokuje úpravu parametrov jadra v `/proc/sys` a `/sys`; `ProtectKernelModules=true` , ktoré bráni načítavaniu alebo vykladaniu modulov; `ProtectKernelLogs=true` , ktoré bráni čítaniu protokolov jadra; a `ProtectControlGroups=true` , ktoré blokuje zápisy do hierarchie cgroups. Toto všetko bezproblémovo funguje s novými možnosťami izolácie používateľov, ako napríklad ` PrivateUsers=full` , ktorá je vo verzii 260 aktualizovaná tak, aby mapovala celý rozsah ID používateľov, čím sa eliminujú predchádzajúce riešenia potrebné pre vnorené prostredia systemd.

PrivateUsers, xaccess a nové ovládacie prvky prístupu zariadení

Mechanizmus PrivateUsers , navrhnutý tak, aby umožňoval spúšťanie služieb v izolovanom priestore ID používateľov, je v systemd 260 konsolidovaný. Možnosť PrivateUsers=full teraz mapuje celý rozsah identifikátorov, čo zjednodušuje veci v kontajneroch a na systémoch s vnorenými inštanciami systemd založenými na starších verziách (pred verziou 257). Toto vylepšenie eliminovalo hacky, ktoré sa predtým používali na detekciu týchto starších inštancií.

Súbežne s tým komponenty ako systemd-logind a systemd-udevd zaviedli koncept xaccess . Tento mechanizmus dopĺňa klasickú logiku uaccess , ktorý udeľuje prístup k určitým zariadeniam (napríklad zvuku alebo videu) používateľom s grafickými reláciami v popredí na lokálnom počítači. Pomocou xaccess je možné delegovať povolenia vzdialeným používateľom so špeciálne označenými reláciami , takže napríklad používateľ pripojený prostredníctvom vzdialenej plochy môže pristupovať k lokálnym vykresľovacím zariadeniam GPU bez udelenia širokých povolení celému systému.

Konfigurácia týchto relácií zahŕňa premenné prostredia sprístupnené prostredníctvom PAM, konkrétne PAMXDG_SESSION_EXTRA_DEVICE_ACCESS= , ktoré umožňujú definovať, ktoré konkrétne zariadenia sú zahrnuté v tejto logike. Tento prístup je vo veľkej miere v súlade s požiadavkami Európskej únie na dodržiavanie predpisov a ochranu údajov, kde sa vyžaduje granularita a sledovateľnosť prístupu k citlivému hardvéru.

mstack, systemd-mstack a nové nástroje pre kontajnery

V oblasti kontajnerizácie zavádza systemd 260 funkcionalitu zásobník m a pridružený príkaz, systemd-mstackMyšlienkou mstacku je umožniť definovanie OverlayFS na základe štruktúry špeciálneho adresára s názvom .mstack/, ktorý sa riadi špecifickou špecifikáciou pre organizáciu svojich vrstiev.

Nový nástroj príkazového riadka systemd-mstack uľahčuje interaktívnu prácu s týmito zásobníkmi súborových systémov a zvyšuje flexibilitu pri nastavovaní vrstvených prostredí pre kontajnery alebo vysoko izolované služby. Táto funkcionalita je tiež spojená s vylepšeniami v systemd-importd , ktorý rozširuje svoju podporu pre sťahovanie a správu obrazov OCI , čím posilňuje úlohu systemd ako nástroja na kontajnerizáciu a sandboxing, čo je veľmi bežné medzi európskymi poskytovateľmi cloudu a modernými hostingovými platformami.

Sieť: Integrácia s ModemManagerom a nové možnosti výkonu

Na sieťovej vrstve systemd-networkd naďalej získava na význame. Jednou z pozoruhodných nových funkcií je jeho integrácia s ModemManagerom prostredníctvom protokolu „simple connect“ , ktorý umožňuje spravovať modemy a mobilné pripojenia priamo z networkd bez spoliehania sa na externé nástroje.

Na podporu tohto toku sa pridáva nová sekcia. do konfiguračných súborov s parametrami ako napríklad APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=To uľahčuje nasadenie v vidiecke oblasti alebo prostredia s pripojením založeným na mobilných sieťach, veľmi prítomný v určitých územiach Európy, kde nie je vždy k dispozícii optické vlákno alebo kvalitné pevné linky.

Pokiaľ ide o výkon, súbory .link systemd-networkd obsahujú nové možnosti špeciálne pre ethernetové zariadenia. Patria sem ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList a GenericReceiveOffloadUDPForwarding . Tieto možnosti umožňujú jemné doladenie presunu práce na hardvér a ovládače, čo je kľúčové v podnikových sieťach, dátových centrách a u poskytovateľov služieb, ktorí potrebujú minimalizovať každú milisekundu latencie.

Rozhrania Varlink a JSON v systemd-networkd teraz dokážu hlásiť IP adresy v čitateľnom formáte (reťazce) a zároveň zachovať reprezentáciu ako celočíselné pole. To zjednodušuje integráciu s monitorovacími panelmi, skriptami pre správu alebo nástrojmi tretích strán, ktoré nechcú pracovať s neintuitívnymi číselnými formátmi.

Prenositeľnosť služieb, dočasné virtuálne počítače a neprivilegované služby

Komponent systemd-portabled , zodpovedný za správu „prenosných“ služieb zabalených v obrazoch, získava veľmi zaujímavú funkciu: teraz môže bežať ako služba na úrovni používateľa . To znamená, že neprivilegovaní používatelia môžu počas svojej bežnej relácie spúšťať a spravovať prenosné služby vo svojom vlastnom priestore bez použitia príkazu sudo alebo zvýšených privilégií.

Okrem toho, počnúc touto verziou, dokáže portabled generovať politiky a uzamknúť obraz priradený k prenosnej službe , čím zabráni úprave tohto obrazu bez jeho opätovného pripojenia. To umožňuje používateľom nastaviť samostatné prostredia s pridanými zárukami nemennosti, čo je obzvlášť atraktívna funkcia pre laboratóriá, vývojové prostredia a testovacie sandboxy.

Na druhej strane, systemd-vmspawn – nástroj určený na spúšťanie virtuálnych počítačov integrovaným spôsobom so systemd – rozširuje svoje možnosti registrácie so systemd-machined v rámci používateľskej relácie . Zavádza tiež možnosť „-ephemeral“ na vytváranie efemérnych počítačov, ktoré sa po ukončení ich používania zničia. Toto sa perfektne hodí pre CI/CD kanály, virtuálne učebne alebo európske vzdelávacie platformy, ktoré vyžadujú rýchle a kontrolované vytváranie a ničenie virtuálnych počítačov.

Jemne vyladené riadenie CPU, pamäte a plánovania pomocou SCHED_EXT a THP

Systemd 260 sa tiež ponára do riadenia výkonu pomocou nových politík. Možnosť služby Zásady plánovania CPU= teraz akceptujte hodnotu ext, ktorý aktivuje plánovač SCHED_EXTTento alternatívny plánovač otvára dvere k experimenty s rôznymi plánovacími politikami podľa štandardov jadra, čo by mohlo byť zaujímavé vo výskumných a vývojových laboratóriách alebo vo vysoko špecializovaných nasadeniach.

V oblasti pamäte nájdete parameter `MemoryTHP=` , ktorý vám umožňuje spravovať používanie transparentných obrovských stránok (THP) pre jednotlivé služby. Namiesto globálneho nastavenia v celom systéme sa môžete rozhodnúť, či má konkrétna jednotka používať THP, či ho má vypnúť alebo prijať prechodné režimy. Pre kritické aplikácie v bankovníctve, poisťovníctve alebo vláde môže táto podrobná kontrola znamenať významný rozdiel v latencii, spotrebe pamäte a výkone.

Nové príkazy v systemctl a rozšírené použitie Varlinku

Známy príkaz systemctl získava nový: enqueue-marked . Táto akcia interne volá metódu D-Bus EnqueueMarkedJobs() a umožňuje prácu s frontami vopred označených úloh a služieb. Aj keď sa to môže zdať ako drobný detail, pre operačné tímy, ktoré riadia rozsiahle serverové farmy, je to ďalší nástroj na zdokonalenie pracovných postupov nasadzovania a automatizácie.

Súbežne projekt naďalej rozširuje používanie Varlinku ako komunikačného mechanizmu medzi komponentmi. Mnohé časti systemd sprístupňujú stabilné rozhrania Varlinku, ktoré uľahčujú integráciu s externými nástrojmi, vlastnými dashboardmi alebo monitorovacími agentmi, ktoré vyžadujú štruktúrovaný prístup k systémovým informáciám.

Polia identifikácie systému a používateľská skúsenosť

Zaujímavou, ale užitočnou novou funkciou pre niektoré distribúcie je zavedenie poľa FANCY_NAME= v archíve /etc/os-releaseToto pole sa podobá na pole PRETTY_NAME, ale povoľuje Sekvencie ANSI a zložitejšie znaky UnicodeVďaka tomu môžu byť konkrétne distribúcie a edície prezentované s pútavejšími alebo výraznejšími názvami.

Hodnotu FANCY_NAME je možné zobraziť prostredníctvom správcu systemd pomocou systemd-hostnamed alebo dotazom hostnamectl . Hoci ide o malú zmenu, v desktopových prostrediach a grafických administračných paneloch môže byť užitočná na rýchlu identifikáciu spravovaného systému , najmä pri práci s mnohými odvodenými variantmi.

Špecifická dokumentácia pre agentov AI a asistovaný pracovný postup kontroly

Jedným z najzaujímavejších znakov smerovania vývoja systemd je objavenie sa dokumentácie špeciálne zameranej na agentov umelej inteligencie . Repozitár obsahuje súbor AGENTS.md , ktorý má pomôcť nástrojom na analýzu kódu a programátorským asistentom, ako aj niektoré technologické príručky lepšie pochopiť architektúru projektu, štýl, postup vývoja a pokyny pre prispievanie.

Tento dokument popisuje komponenty, spôsoby zostavenia, spôsob spúšťania testov a integrácií a pokyny na generovanie prijateľných záplat. Zámerom je poskytnúť agentom umelej inteligencie, ktorí kontrolujú kód alebo vykonávajú zmeny, dôkladné pochopenie toho, ako je systém systemd organizovaný , a tým znížiť počet chýb a nesprávne umiestnené návrhy.

Vedľa súboru AGENTS.md sa nachádza súbor s názvom CLAUDE.md , ktorý explicitne odkazuje na prvý súbor a je určený na riadenie nástroja Claude Code, jedného z najpoužívanejších vývojových asistentov založených na umelej inteligencii. Týmto spôsobom projekt explicitne začleňuje umelú inteligenciu do svojho vývojového cyklu.

Okrem toho je súčasťou balenia aj konfiguračný súbor. claude-review.ymlkde je definované, ako by sa mal s pomocou Claude Code kontrolovať proces analýzy žiadostí o zmenu (žiadostí o stiahnutie). V tejto súvislosti sa od príspevkov, ktoré využívali umelú inteligenciu, vyžaduje, aby zahŕňali štítky s informáciami ako Co-developed-by v záplatách, čo zanecháva dôkazy o tom, že na tvorbe kódu sa podieľal automatizovaný nástroj.

Vďaka tejto komplexnej sade zmien – vyčisteniu staršej podpory, zdokonaleniu sandboxu, vylepšeniu TPM2 a SRK, pokročilej sieťovej integrácii, novým funkciám prenositeľnosti a dokumentácii navrhnutej pre inteligentných agentov – systemd 260 posilňuje svoju ústrednú úlohu v modernom ekosystéme Linuxu. Pre administrátorov a vývojárov v Španielsku a Európe spočíva bezprostredná výzva v revízii jadier, prispôsobení konfigurácií zavádzania a služieb a využití týchto funkcií na vybudovanie bezpečnejších a automatizovanejších infraštruktúr, ktoré sú v súlade so súčasným používaním systému.