Systemd 260: TPM2, sandboxing a nové funkce v Linuxu

Průvodce hardwarem » Nákupní průvodci » Systemd 260: TPM2, sandboxing a nové funkce v Linuxu

S příchodem systemd 260 činí linuxové distribuce další důležitý krok směrem k modernějšímu a bezpečnějšímu ekosystému zaměřenému na cloudová prostředí, virtualizaci a automatizaci. Tato verze nejen vylepšuje detaily: zavádí významné změny v bootování, správě služeb, sítích, používání TPM2 pro integritu a šifrování a v možnostech sandboxu na úrovni disků.

Zároveň projekt posiluje svou dokumentaci a přístup k práci s agenty umělé inteligence , což jasně ukazuje, že systemd je klíčovým pilířem, ke kterému se připojuje stále více vývojových a pozorovatelných nástrojů. Pokud spravujete linuxové systémy na serverech, v cloudu, na firemních počítačích nebo v laboratořích, stojí za to si věnovat chvíli procházení všech těchto nových funkcí a plánovat aktualizace a úpravy konfigurace.

Konečné sbohem Systemu V a naprostá závislost na nativních discích

Jednou z nejvýraznějších změn v systemd 260 je úplné odstranění podpory skriptů System V. Klasický bootovací proces založený na /etc/init.d byl postupně ukončen po léta, ale nyní z kódu systemd fakticky zmizel.

To znamená, že komponenty zodpovědné za propojení mezi skripty SysV a nativními jednotkami byly odstraněny: systemd-rc-local-generator, rc-local.service, systemd-sysv-generator a systemd-sysv-install již neexistují. V důsledku toho se jakákoli služba, která je stále závislá na těchto starších mechanismech, jednoduše nespustí na systémech, které používají systemd 260.

Během procesu čištění bylo několik možností sestavení Meson označeno jako zastaralé nebo odstraněno. Příznaky -Drc-local=, -Dsysvinit-path= a -Dsysvrcnd-path= byly přesunuty do archivů, zatímco jiné, jako například -Dintegration-tests= a -Dcryptolib=, byly zcela odstraněny. To vysílá jasný signál: vše musí být nyní zpracováno nativními jednotkami a moderní infrastrukturou Systemd.

Pro mnoho evropských infrastruktur, které stále spoléhají na starší komponenty, tato změna vyžaduje revizi interních služeb, vlastních skriptů a starších nasazení. Migrace na dobře definované soubory jednotek se již nejen doporučuje; je povinná, pokud chcete i nadále provozovat služby na distribucích, které integrují systemd 260.

Vyšší požadavky na jádro a zaměření na aktuální prostředí

Nová verze zvyšuje laťku pro jádro: od nynějška je minimální podporovaná verze Linuxu 5.10 , čímž se vyhýbá velmi starým větvím, jako je 5.4. Projekt dále naznačuje, že by uživatelé měli v ideálním případě pracovat na jádře 5.14 nebo vyšším , a zejména doporučuje řadu 6.6 , aby mohli plně využít všechny dostupné funkce.

Toto zvýšení požadavků obvykle nepředstavuje problém v moderních distribucích, ale může to situaci zkomplikovat ve velmi konzervativních prostředích nebo u embedded řešení udržovaných po mnoho let. Před upgradem na systemd 260 je vhodné ověřit, které jádro se používá, zejména v evropských datových centrech s dlouhodobým nasazením nebo vlastními obrazy.

Na opačném konci spektra se nacházejí distribuce s postupným vydáváním verzí, jako je Arch Linux nebo openSUSE Tumbleweed, velmi oblíbené mezi těmi, kteří chtějí nejnovější funkce, které obvykle rychle začleňují jak nová jádra, tak nové větve systemd. Jiné, jako například Fedora, si udržují určitou míru stability v hlavní verzi systemd po celou dobu životního cyklu každého vydání, což umožňuje o něco více času na plánování migrací.

TPM2, integrita spouštění a pokročilá podpora SRK

Jednou z oblastí, kde se systemd nejvíce vyvíjí, je jeho integrace s TPM2 (Trusted Platform Module 2.0) . Tento čip, stále běžnější v moderních základních deskách s UEFI a hardwaru střední a vyšší třídy, umožňuje ukotvení tajných informací ke stavu systému, měření fází spouštění a automatické odemykání šifrovaných svazků, když je prostředí v pořádku.

Systemd 260 tuto integraci dále vylepšuje přidáním nástrojů a služeb, které pokrývají různé fáze procesu spouštění. Klíčovou součástí je systemd-tpm2-setup , která je zodpovědná za přípravu infrastruktury kolem kořenového klíče úložiště (SRK) modulu TPM . Tento kořenový klíč slouží jako kryptografický základ pro zabezpečení komunikace s čipem a pro bezpečné ukládání dalších tajných informací.

Během bootování se rozlišují dvě fáze: velmi raná v initrd a druhá v kořenovém systému. V první služba s názvem „Early TPM SRK Setup“ zkontroluje, zda TPM již má uložený SRK, a pokud neexistuje, vytvoří jej a dočasně jej zpřístupní v /run/systemd/tpm2-srk-public-key.* . Později, jakmile je skutečný souborový systém připojen, služba konsoliduje SRK a ověří, zda klíč uložený v /var/lib/systemd/tpm2-srk-public-key.pem odpovídá klíči v TPM.

V dobře nakonfigurovaných scénářích se zobrazí záznamy v žurnálu, jako například „SRK je již uložen v TPM“ a zprávy označující, že stopa SRK odpovídá očekávané. Pokud však prostředí není správně nakonfigurováno (například v nastaveních používajících Yocto nebo na deskách jako Raspberry Pi s TPM založeným na SPI a vlastními metodami spouštění, jako je U-Boot a měřené spouštění), mohou nastat situace, kdy systemd tyto soubory v adresáři /var/lib/systemd nevytvoří, což vyvolává pochybnosti o tom, zda byl SRK správně nakonfigurován.

Pokud se změní stav TPM, upraví se oddíly nebo se změní spouštěcí sekvence, příslušná zásada již nemusí být platná. V takových případech někteří správci doporučují vymazat slot TPM nebo zásadu a znovu zaregistrovat klíč podle postupů podobných těm, které jsou popsány v průvodcích šifrováním disků s TPM v prostředích, jako je openSUSE, které podrobně popisují, jak znovu vytvořit zásadu PCR a znovu propojit svazek.

Kromě SRK je dalším praktickým vylepšením zavedení interního nástroje s názvem tpm2_id v udev . Tento integrovaný nástroj se spustí, když systém detekuje zařízení TPM2, a automaticky extrahuje identifikátor výrobce a modelu . To zjednodušuje inventuru bezpečnostního hardwaru, což je velmi užitečné ve veřejné správě, regulovaných společnostech nebo kritické infrastruktuře, kde je nutné přesně vědět, které moduly TPM jsou nasazeny.

Integraci s infrastrukturou pro měření bootování dále posilují specifické jednotky, jako je systemd-pcrextend , které zaznamenávají události jako „enter-initrd“, „leave-initrd“, „sysinit“ a „ready“ v různých PCR (např. PCR 11). Tato sekvence rozšíření umožňuje TPM shromažďovat kryptograficky ověřitelný záznam o toku bootování, který lze poté použít pro politiky důvěryhodného bootování nebo pro UKI (Unified Kernel Images) k ověření stavu počítače před uvolněním klíčů.

Bezpečnostní opatření a sandbox služeb se systemd

Systemd nejen spouští procesy, ale také nabízí komplexní sadu direktiv pro sandboxing , které izolují služby a omezují škody v případě kompromitace. Tento přístup „hloubkové obrany“ se opírá o cgroups, jmenné prostory, možnosti jádra a filtry systémových volání (seccomp).

Pro posouzení zabezpečení konkrétní služby obsahuje systemd bezpečnostní nástroj systemd-analyze . Jeho spuštěním se vygeneruje zpráva se skóre expozice na stupnici od 0 do 10, kde nižší skóre je lepší. Zpráva rozebírá, které ochrany jsou povoleny nebo zakázány (izolace sítě, přístup k souborovému systému, přístup k zařízení atd.), což usnadňuje identifikaci chybějících nastavení a ověření, zda změny skutečně zlepšují skóre.

Místo úpravy původní jednotky – která by se v budoucích aktualizacích balíčků ztratila – se doporučuje vytvořit potlačení en /etc/systemd/system/mi-servicio.service.d/ se souborem, například sandbox.confPo úpravě jednoduše znovu načtěte konfiguraci pomocí systemctl daemon-reload a restartujte službu, aby se nová omezení projevila.

Na úrovni souborového systému je jednou z nejdůležitějších možností OchranaSystému=Hodnoty jako například strict, full o true Různé části stromu připojují v režimu pouze pro čtení. Obvyklá praxe, pokud je to možné, je použití ProtectSystem=strictDíky tomu jsou adresáře /usr, /boot, /efi a /etc pro službu pouze pro čtení. Pokud aplikace potřebuje zapisovat do konkrétních adresářů, může tak učinit pomocí ReadWritePaths=/cesta v jednotě.

Pro další zvýšení soukromí se doporučuje omezit přístup k uživatelským adresářům pomocí parametru `ProtectHome=true` , který službě zabrání ve čtení adresářů `/home`, `/root` nebo `/run/user`. Parametr `PrivateTmp=true` navíc vytváří izolované prostory `/tmp` a `/var/tmp`, čímž zabraňuje vzájemné viditelnosti dočasných souborů mezi procesy.

V zařízeních `PrivateDevices=true` skryje skutečný strom `/dev` a nahradí ho minimální sadou bezpečných pseudo-zařízení (null, zero, random atd.). Pokud disk potřebuje specifické zařízení (například sériový port nebo blok disku), lze mu ho udělit pomocí `DeviceAllow=/dev/xxx rw` nebo v režimu pouze pro čtení.

Síť je také klíčovým vektorem. S PrivateNetwork=true Vytvoří se izolovaný jmenný prostor sítě, zůstane pouze zpětná smyčka; služba neuvidí fyzická rozhraní a nebude moci komunikovat s okolním světem. Případně můžete omezit, které adresní rodiny může používat, a to RestrictAddressFamilies=povolení pouze AF_INET a AF_INET6 pro IPv4/IPv6, AF_UNIX pro lokální sockety nebo dokonce none plně japonizovat síťové funkce.

Pokud jde o oprávnění, direktiva `NoNewPrivileges=true` je jednou z nejúčinnějších: brání procesu v získávání nových oprávnění prostřednictvím binárních souborů setuid nebo změn schopností. Stručně řečeno, i když služba spustí zranitelný kód, neměla by být schopna eskalovat do rootu prostřednictvím tradičních mechanismů. V kombinaci s direktivou `CapabilityBoundingSet=` , která definuje přesný seznam povolených schopností (například pouze `CAP_NET_BIND_SERVICE` pro naslouchání na portech s nízkou úrovní oprávnění), je minimalizována plocha pro útok.

Abychom šli ještě dál, systemd umožňuje filtrování systémových volání pomocí SystemCallFilter=Místo ručního udržování seznamu systémových volání se používají předdefinované skupiny, jako například @system-service, @network-io, @basic-io nebo odmítnout skupiny jako ~@privileged. S systemd-analyze syscall-filter Je možné kontrolovat, která konkrétní volání patří do každé skupiny. To umožňuje vytvořit velmi omezený profil provádění, podobný tomu, co by nabízel specializovaný sandbox.

Mezi další relevantní nastavení patří `ProtectKernelTunables=true` , které blokuje úpravu parametrů jádra v `/proc/sys` a `/sys`; `ProtectKernelModules=true` , které brání načítání nebo uvolňování modulů; `ProtectKernelLogs=true` , které brání čtení protokolů jádra; a `ProtectControlGroups=true` , které blokuje zápisy do hierarchie cgroups. To vše bezproblémově funguje s novými možnostmi izolace uživatelů, jako je ` PrivateUsers=full` , která je ve verzi 260 aktualizována tak, aby mapovala celý rozsah uživatelských ID, čímž se eliminují předchozí alternativní řešení vyžadovaná pro vnořená prostředí systemd.

PrivateUsers, xaccess a nové ovládací prvky přístupu k zařízením

Mechanismus PrivateUsers , navržený tak, aby umožňoval službám běžet v izolovaném prostoru uživatelských ID, je v systemd 260 konsolidován. Možnost PrivateUsers=full nyní mapuje celý rozsah identifikátorů, což zjednodušuje práci v kontejnerech a na systémech s vnořenými instancemi systemd založenými na starších verzích (před verzí 257). Toto vylepšení eliminovalo hacky, které se dříve používaly k detekci těchto starších instancí.

Souběžně s tím komponenty jako systemd-logind a systemd-udevd zavedly koncept xaccess . Tento mechanismus doplňuje klasickou logiku uaccess , který uděluje přístup k určitým zařízením (například zvuku nebo videu) uživatelům s grafickými relacemi v popředí na lokálním počítači. S xaccess lze delegovat oprávnění vzdáleným uživatelům se speciálně označenými relacemi , takže například uživatel připojený přes vzdálenou plochu může přistupovat k lokálním vykreslovacím zařízením GPU, aniž by musel udělovat široká oprávnění celému systému.

Konfigurace těchto relací zahrnuje proměnné prostředí zpřístupněné prostřednictvím PAM, konkrétně PAMXDG_SESSION_EXTRA_DEVICE_ACCESS= , což umožňuje definovat, která konkrétní zařízení jsou do této logiky zahrnuta. Tento přístup je vysoce v souladu s požadavky Evropské unie na dodržování předpisů a ochranu dat, kde je pro přístup k citlivému hardwaru vyžadována granularita a sledovatelnost.

mstack, systemd-mstack a nové nástroje pro kontejnery

V oblasti kontejnerizace zavádí systemd 260 funkcionalitu zásobník m a související příkaz, systemd-mstackMyšlenkou mstacku je umožnit definování OverlayFS na základě struktury speciálního adresáře s názvem .mstack/, který se řídí specifickou specifikací pro organizaci svých vrstev.

Nový nástroj příkazového řádku systemd-mstack usnadňuje interaktivní práci s těmito zásobníky souborových systémů a zvyšuje flexibilitu při nastavování vrstvených prostředí pro kontejnery nebo vysoce izolované služby. Tato funkce je také spojena s vylepšeními v nástroji systemd-importd , který rozšiřuje podporu pro stahování a správu obrazů OCI , a tím posiluje roli systemd jakožto kontejnerizačního a sandboxového enginu, což je velmi běžné u evropských poskytovatelů cloudových služeb a moderních hostingových platforem.

Síť: Integrace s ModemManagerem a nové možnosti výkonu

Na síťové vrstvě získává systemd-networkd stále na významu. Jednou z pozoruhodných nových funkcí je jeho integrace s ModemManagerem prostřednictvím protokolu „simple connect“ , který umožňuje spravovat modemy a mobilní připojení přímo z networkd bez nutnosti spoléhat se na externí nástroje.

Pro podporu tohoto toku je přidána nová sekce. do konfiguračních souborů s parametry, jako například APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=To usnadňuje nasazení v venkovské oblasti nebo prostředí s konektivitou založenou na mobilních sítích, velmi rozšířený v některých oblastech Evropy, kde není vždy k dispozici optické vlákno nebo kvalitní pevné linky.

Co se týče výkonu, soubory .link v rámci systemd-networkd obsahují nové možnosti určené speciálně pro ethernetová zařízení. Patří mezi ně ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList a GenericReceiveOffloadUDPForwarding . Tyto možnosti umožňují jemné doladění přesměrování práce na hardware a ovladače, což je klíčové v podnikových sítích, datových centrech a u poskytovatelů služeb, kteří potřebují minimalizovat každou milisekundu latence.

Rozhraní Varlink a JSON v systemd-networkd nyní navíc dokáží hlásit IP adresy v lidsky čitelném formátu (řetězce) a zároveň zachovat reprezentaci jako celočíselné pole. To zjednodušuje integraci s monitorovacími dashboardy, skripty pro správu nebo nástroji třetích stran, které nechtějí pracovat s neintuitivními číselnými formáty.

Přenositelnost služeb, dočasné virtuální počítače a neprivilegované služby

Komponenta systemd-portabled , která je zodpovědná za správu „přenosných“ služeb zabalených v obrazech, získává velmi zajímavou funkci: nyní může běžet jako služba na uživatelské úrovni . To znamená, že neprivilegovaní uživatelé mohou ve své běžné relaci spouštět a spravovat přenosné služby ve svém vlastním prostoru, aniž by museli používat sudo nebo zvýšená oprávnění.

Navíc, počínaje touto verzí, může portabled generovat zásady a uzamknout obraz přidružený k přenosné službě , čímž zabrání úpravě tohoto obrazu bez jeho opětovného připojení. To umožňuje uživatelům nastavit samostatná prostředí s přidanými zárukami neměnnosti, což je obzvláště atraktivní funkce pro laboratoře, vývojová prostředí a testovací sandboxy.

Na druhou stranu, systemd-vmspawn – nástroj určený ke spouštění virtuálních strojů integrovaným způsobem se systemd – rozšiřuje své možnosti registrace u systemd-machined v rámci uživatelské relace . Zavádí také volbu `-ephemeral` pro vytváření efemérních strojů, které jsou po dokončení jejich používání zničeny. To se perfektně hodí pro CI/CD pipelines, virtuální učebny nebo evropské vzdělávací platformy, které vyžadují rychlé a kontrolované vytváření a ničení virtuálních strojů.

Jemně vyladěné ovládání CPU, paměti a plánování pomocí SCHED_EXT a THP

Systemd 260 se také ponořuje do řízení výkonu pomocí nových zásad. Možnost služby Zásady plánování CPU= nyní přijměte hodnotu ext, který aktivuje plánovač SCHED_EXTTento alternativní plánovač otevírá dveře k experimenty s různými plánovacími politikami podle standardů jádra, což by mohlo být zajímavé ve výzkumných a vývojových laboratořích nebo ve vysoce specializovaných nasazeních.

V oblasti paměti najdete parametr `MemoryTHP=` , který umožňuje spravovat používání transparentních obrovských stránek (THP) pro jednotlivé služby. Namísto globálního nastavení v celém systému se můžete rozhodnout, zda má konkrétní jednotka využívat THP, zda jej má zakázat, nebo zda má používat přechodné režimy. Pro kritické aplikace v bankovnictví, pojišťovnictví nebo státní správě může tato podrobná kontrola významně ovlivnit latenci, spotřebu paměti a výkon.

Nové příkazy v systemctl a rozšířené použití Varlinku

Známý příkaz systemctl získává nový: enqueue-marked . Tato akce interně volá metodu D-Bus EnqueueMarkedJobs() a umožňuje práci s frontami předem označených úloh a služeb. I když se to může zdát jako drobný detail, pro provozní týmy spravující rozsáhlé serverové farmy je to další nástroj pro zdokonalení pracovních postupů nasazení a automatizace.

Souběžně s tím projekt dále rozšiřuje využití Varlinku jako komunikačního mechanismu mezi komponentami. Mnoho částí systemd nabízí stabilní rozhraní Varlink, která usnadňují integraci s externími nástroji, vlastními dashboardy nebo monitorovacími agenty, které vyžadují strukturovaný přístup k systémovým informacím.

Pole pro identifikaci systému a uživatelská zkušenost

Zajímavou, ale užitečnou novou funkcí u některých distribucí je zavedení pole FANCY_NAME= v archivu /etc/os-releaseToto pole se podobá PRETTY_NAME, ale umožňuje Sekvence ANSI a propracovanější znaky UnicodeDíky tomu lze konkrétní distribuce a edice prezentovat s poutavějšími nebo výraznějšími názvy.

Hodnotu FANCY_NAME lze zobrazit prostřednictvím správce systemd pomocí příkazu systemd-hostnamed nebo dotazem na hostnamectl . I když se jedná o malou změnu, v desktopových prostředích a grafických administračních panelech může být užitečná pro rychlou identifikaci spravovaného systému , zejména při práci s mnoha odvozenými variantami.

Specifická dokumentace pro agenty AI a pracovní postup asistované kontroly

Jedním z nejzajímavějších znaků směru vývoje systemd je objevení dokumentace speciálně zaměřené na agenty umělé inteligence . Repozitář obsahuje soubor AGENTS.md , který má pomoci nástrojům pro analýzu kódu a programátorským asistentům, a také některé technologické průvodce k lepšímu pochopení architektury, stylu, vývojového postupu a pokynů pro přispívání projektu.

Tento dokument popisuje komponenty, cesty sestavení, jak spouštět testy a integrace a pokyny pro generování přijatelných záplat. Záměrem je poskytnout agentům umělé inteligence, kteří kontrolují kód nebo provádějí změny, důkladné pochopení toho, jak je systemd organizován , a tím snížit počet chyb a nesprávně umístěných návrhů.

Vedle souboru AGENTS.md existuje soubor s názvem CLAUDE.md , který explicitně odkazuje na první jmenovaný a je navržen tak, aby řídil nástroj Claude Code, jednoho z nejpoužívanějších vývojových asistentů založených na umělé inteligenci. Tímto způsobem projekt explicitně začleňuje umělou inteligenci do svého vývojového cyklu.

Dále je součástí konfigurační soubor. claude-review.ymlkde je definováno, jak by měl být proces analýzy žádostí o změny (pull requestů) kontrolován s pomocí Claude Code. V této souvislosti musí příspěvky, které využívají umělou inteligenci, zahrnovat štítky pro zveřejnění informací jak Co-developed-by v záplatách, což zanechává důkazy o tom, že se na tvorbě kódu podílel automatizovaný nástroj.

Díky této komplexní sadě změn – vyčištění starší podpory, zdokonalení sandboxu, vylepšení TPM2 a SRK, pokročilá síťová integrace, nové funkce přenositelnosti a dokumentace navržená pro inteligentní agenty – posiluje systemd 260 svou ústřední roli v moderním ekosystému Linuxu. Pro administrátory a vývojáře ve Španělsku a Evropě spočívá bezprostřední výzva v revizi jader, úpravě konfigurací spouštění a služeb a využití těchto funkcí k budování bezpečnějších a automatizovanějších infrastruktur odpovídajících současnému využití systému.