Systemd 260: TPM2, пясъчник и нови възможности в Linux

Ръководство за хардуер » Ръководства за купуване » Systemd 260: TPM2, sandboxing и нови възможности в Linux

С появата на systemd 260, Linux дистрибуциите правят още една важна стъпка към по-модерна и сигурна екосистема, насочена към облачни среди, виртуализация и автоматизация. Тази версия не само усъвършенства детайлите: тя въвежда значителни промени в зареждането, управлението на услугите, работата в мрежа, използването на TPM2 за целостност и криптиране, както и възможности за изолация на ниво устройство.

В същото време проектът укрепва документацията и подхода си към работа с агенти с изкуствен интелект , което ясно показва, че systemd е критичен стълб, към който се свързват все повече инструменти за разработка и наблюдение. Ако управлявате Linux системи на сървъри, в облака, на корпоративни настолни компютри или в лаборатории, си струва да отделите малко време, за да прегледате всички тези нови функции, за да планирате актуализации и корекции в конфигурацията.

Окончателно сбогуване със System V и пълна зависимост от вградените дискове

Една от най-поразителните промени в systemd 260 е пълното премахване на поддръжката за скриптове на System V. Класическият процес на зареждане, базиран на /etc/init.d, беше постепенно премахнат от години, но сега той ефективно изчезва от кода на systemd.

Това означава, че компонентите, отговорни за свързването между SysV скриптовете и нативните модули, са премахнати: systemd-rc-local-generator, rc-local.service, systemd-sysv-generator и systemd-sysv-install вече не съществуват. В резултат на това всяка услуга, която все още зависи от тези стари механизми, просто няма да стартира на системи, които приемат systemd 260.

По време на процеса на почистване, няколко опции за компилация на Meson също бяха маркирани като остарели или премахнати. Флаговете -Drc-local=, -Dsysvinit-path= и -Dsysvrcnd-path= бяха преместени в архивите, докато други, като -Dintegration-tests= и -Dcryptolib=, бяха премахнати напълно. Това изпраща ясно послание: всичко вече трябва да се обработва от нативните модули и модерната systemd инфраструктура.

За много европейски инфраструктури, които все още разчитат на по-стари компоненти, тази промяна налага преглед на вътрешните услуги, персонализираните скриптове и наследените внедрявания. Мигрирането към добре дефинирани файлове с модули вече не е само препоръчително; то е задължително, ако искате да продължите да изпълнявате услуги на дистрибуции, които интегрират systemd 260.

По-високи изисквания към ядрото и фокус върху текущите среди

Новата версия вдига летвата за ядрото: отсега нататък минималната поддържана версия на Linux е 5.10 , оставяйки зад гърба си много стари клонове като 5.4. Освен това, проектът посочва, че в идеалния случай потребителите трябва да работят с ядро ​​5.14 или по-нова версия и особено препоръчва серията 6.6, за да се възползват максимално от всички налични функции.

Това увеличение на изискванията обикновено не е проблем в съвременните дистрибуции, но може да усложни нещата в много консервативни среди или вградени решения, поддържани в продължение на много години. Преди да надстроите до systemd 260, е препоръчително да проверите кое ядро ​​се използва, особено в европейски центрове за данни с дългосрочни внедрявания или персонализирани образи.

В противоположния край на спектъра, дистрибуциите с постоянно обновяване като Arch Linux или openSUSE Tumbleweed, много популярни сред тези, които искат най-новите функции, са склонни бързо да включват както нови ядра, така и нови клонове на systemd. Други, като Fedora, поддържат известна степен на стабилност в основната версия на systemd през целия жизнен цикъл на всяко издание, което позволява малко повече време за планиране на миграции.

TPM2, интегритет на зареждане и разширена поддръжка на SRK

Една от областите, в които systemd се развива най-много, е интеграцията му с TPM2 (Trusted Platform Module 2.0) . Този чип, все по-често срещан в съвременните UEFI дънни платки и хардуер от среден и висок клас, позволява закрепване на секрети към състоянието на системата, измерване на фазите на зареждане и автоматично отключване на криптирани томове, когато средата е според очакванията.

Systemd 260 допълнително подобрява тази интеграция, като добавя инструменти и услуги, които обхващат различни етапи от процеса на зареждане. Ключов компонент е systemd-tpm2-setup , отговорен за подготовката на инфраструктурата около Storage Root Key (SRK) на TPM . Този root key служи като криптографска основа за осигуряване на комуникацията с чипа и за сигурно съхранение на други тайни.

По време на зареждане се разграничават две фази: много ранна в initrd и друга в кореновата система. В първата, услуга, наречена "Early TPM SRK Setup", проверява дали TPM вече има съхранен SRK и, ако такъв не съществува, го създава и го прави временно достъпен в /run/systemd/tpm2-srk-public-key.* . По-късно, след като истинската файлова система бъде монтирана, услугата ще консолидира SRK и ще провери дали ключът, съхранен в /var/lib/systemd/tpm2-srk-public-key.pem, съвпада с този в TPM.

В добре конфигурирани сценарии ще се показват записи в журнала, като например „SRK вече е съхранен в TPM“ и съобщения, показващи, че отпечатъкът на SRK съответства на очаквания. Ако обаче средата не е правилно конфигурирана (например в конфигурации, използващи Yocto, или на платки като Raspberry Pi с базиран на SPI TPM и персонализирани методи за зареждане, като U-Boot и measured boot), могат да възникнат ситуации, в които systemd не успява да създаде тези файлове в /var/lib/systemd, което поражда съмнения относно правилното конфигуриране на SRK.

Когато състоянието на TPM се промени, дяловете са модифицирани или последователността на зареждане е променена, свързаната политика може вече да не е валидна. В такива случаи някои администратори препоръчват изчистване на TPM слота или политиката и повторно регистриране на ключа , следвайки процедури, подобни на описаните в ръководствата за криптиране на дискове с TPM в среди като openSUSE, които подробно описват как да се пресъздаде PCR политиката и да се отключи отново томът.

Освен SRK, друго практично подобрение е въвеждането на вътрешна помощна програма, наречена tpm2_id в udev . Този интегриран инструмент се стартира, когато системата открие TPM2 устройство и автоматично извлича идентификатора на производителя и модела . Това опростява инвентаризацията на хардуера за сигурност, което е много полезно в публичните администрации, регулираните компании или критичните инфраструктури, където е важно да се знае точно кои TPM модули са разположени.

Интеграцията с инфраструктурата за измерване на зареждането е допълнително подсилена от специфични модули като systemd-pcrextend , които регистрират събития като "enter-initrd", "leave-initrd", "sysinit" и "ready" в различни PCR (напр. PCR 11). Тази последователност от разширения позволява на TPM да натрупа криптографски проверим запис на потока на зареждане, който след това може да се използва за политики за надеждно зареждане или за UKI (Unified Kernel Images) за валидиране на състоянието на машината преди освобождаване на ключове.

Мерки за сигурност и пясъчник на услугите със systemd

Systemd не само стартира процеси, но и предлага цялостен набор от директиви за пясъчник , за да изолира услугите и да ограничи щетите в случай на компрометиране. Този подход на „защита в дълбочина“ разчита на cgroups, namespaces, възможности на ядрото и филтри за системни повиквания (seccomp).

За да оцени сигурността на конкретна услуга, systemd включва инструмента за сигурност systemd-analyze . Стартирането му генерира отчет с оценка на експозицията по скала от 0 до 10, където по-ниската оценка е по-добра. Отчетът анализира кои защити са активирани или деактивирани (изолация на мрежата, достъп до файловата система, достъп до устройства и др.), което улеснява идентифицирането на липсващите настройки и проверката дали промените действително подобряват оценката.

Вместо да редактирате оригиналния модул, който би бил загубен при бъдещи актуализации на пакета, се препоръчва да създадете Постоянна en /etc/systemd/system/mi-servicio.service.d/ с файл, например, sandbox.confСлед като го промените, просто презаредете конфигурацията с systemctl демон-презареждане и рестартирайте услугата, за да влязат в сила новите ограничения.

На ниво файлова система, една от най-важните опции е Защитна система=Ценности като strict, full o true Те монтират различни части от дървото в режим само за четене. Обичайната практика, когато е възможно, е да се използва ProtectSystem=строгТова прави /usr, /boot, /efi и /etc само за четене за услугата. Ако дадено приложение трябва да записва в определени директории, е позволено да го направи, използвайки ReadWritePaths=/път в единство.

За да се подобри допълнително поверителността, се препоръчва също така да се ограничи достъпът до потребителски директории, използвайки `ProtectHome=true` , което предотвратява четенето на `/home`, `/root` или `/run/user` от услугата. Освен това, `PrivateTmp=true` създава изолирани пространства `/tmp` и `/var/tmp`, предотвратявайки кръстосаната видимост на временните файлове между процесите.

В устройствата, `PrivateDevices=true` скрива действителното дърво `/dev` и го замества с минимален набор от безопасни псевдо-устройства (null, zero, random и т.н.). Ако даден диск се нуждае от специфично устройство (например сериен порт или дисков блок), то може да бъде предоставено чрез `DeviceAllow=/dev/xxx rw` или в режим само за четене.

Мрежата е също ключов вектор. С PrivateNetwork=true Създава се изолирано мрежово пространство от имена, оставяйки само обратната връзка; услугата няма да вижда физически интерфейси и няма да може да комуникира с външния свят. Като алтернатива, можете да ограничите кои семейства адреси може да използва, като RestrictAddressFamilies=позволявайки само AF_INET и AF_INET6 за IPv4/IPv6, AF_UNIX за локални сокети или дори none за пълно японизиране на мрежовите възможности.

Що се отнася до привилегиите, директивата `NoNewPrivileges=true` е една от най-мощните: тя предотвратява придобиването на нови привилегии от процеса чрез setuid двоични файлове или промени в възможностите. Накратко, дори ако услугата изпълнява уязвим код, тя не би трябвало да може да ескалира до root чрез традиционни механизми. В комбинация с `CapabilityBoundingSet=` , която определя точния списък с разрешени възможности (например, само `CAP_NET_BIND_SERVICE` да слуша на ниски портове), повърхността за атака е сведена до минимум.

За да стигнем още по-далеч, systemd позволява филтриране на системни повиквания с SystemCallFilter=Вместо да се поддържа ръчен списък със системни извиквания, се използват предварително дефинирани групи, като например @system-service, @network-io, @basic-io или да отхвърлят групи като ~@privileged, с systemd-анализ syscall-филтър Възможно е да се провери кои конкретни повиквания принадлежат към всяка група. Това позволява изграждането на много ограничен профил на изпълнение, подобен на това, което би предложила специална пясъчник (sandbox).

Други важни настройки включват `ProtectKernelTunables=true` , която блокира модифицирането на параметрите на ядрото в `/proc/sys` и `/sys`; `ProtectKernelModules=true` , която предотвратява зареждането или разтоварването на модули; `ProtectKernelLogs=true` , която предотвратява четенето на лог файлове на ядрото; и `ProtectControlGroups=true` , която блокира записите в йерархията на cgroups. Всичко това работи безпроблемно с нови възможности за изолиране на потребители, като например ` PrivateUsers=full` , която във версия 260 е актуализирана, за да картографира пълния набор от потребителски идентификатори, елиминирайки предишните заобиколни решения, необходими за вложени systemd среди.

PrivateUsers, xaccess и нови контроли за достъп на устройства

Механизмът PrivateUsers , предназначен да позволи на услугите да работят в изолирано пространство от потребителски идентификатори, е консолидиран в systemd 260. Опцията PrivateUsers=full вече картографира пълния набор от идентификатори, опростявайки нещата в контейнери и в системи с вложени systemd инстанции, базирани на по-стари версии (преди 257). Това подобрение елиминира хакове, които преди това са били използвани за откриване на тези по-стари инстанции.

Успоредно с това, компоненти като systemd-logind и systemd-udevd въведоха концепцията за xaccess . Този механизъм допълва класическата логика на uaccess , който предоставя достъп до определени устройства (например аудио или видео) на потребители с графични сесии на преден план на локалната машина. С xaccess разрешенията могат да бъдат делегирани на отдалечени потребители със специално маркирани сесии , така че например потребител, свързан чрез отдалечен работен плот, да има достъп до локални устройства за рендиране с GPU, без да предоставя широки разрешения на цялата система.

Конфигурацията на тези сесии включва променливи на средата, достъпни чрез PAM, по-специално PAMXDG_SESSION_EXTRA_DEVICE_ACCESS= , което позволява да се дефинира кои конкретни устройства са включени в тази логика. Този подход е в тясно съответствие с изискванията за съответствие с регулаторните органи и защита на данните на Европейския съюз, където се изискват гранулираност и проследимост за достъп до чувствителен хардуер.

mstack, systemd-mstack и нови инструменти за работа с контейнери

В областта на контейнеризацията, systemd 260 въвежда функционалността стек от m и свързана с нея команда, systemd-mstackИдеята зад mstack е да позволи дефинирането на OverlayFS базирана на структурата на специална директория, наречена .mstack/, който следва специфична спецификация за организиране на слоевете си.

Новият инструмент за команден ред, systemd-mstack, улеснява интерактивната работа с тези стекове на файлови системи, добавяйки гъвкавост при настройване на слоести среди за контейнери или силно изолирани услуги. Тази функционалност е свързана и с подобрения в systemd-importd , който разширява поддръжката си за изтегляне и управление на OCI изображения , като по този начин засилва ролята на systemd като двигател за контейнеризация и пясъчник, нещо много често срещано сред европейските доставчици на облачни услуги и съвременните хостинг платформи.

Мрежа: Интеграция с ModemManager и нови опции за производителност

На мрежовото ниво, systemd-networkd продължава да набира значение. Една от забележителните нови функции е интеграцията му с ModemManager чрез протокола "simple connect" , който позволява управлението на модеми и мобилни връзки директно от networkd, без да се разчита на външни инструменти.

За да се подпомогне този поток, е добавен нов раздел. към конфигурационните файлове, с параметри като APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=Това улеснява внедряването в селски райони или среди със свързаност, базирана на мобилни мрежи, силно разпространени в определени територии на Европа, където не винаги има оптичен интернет или качествени стационарни телефони.

По отношение на производителността, .link файловете на systemd-networkd включват нови опции, специално предназначени за Ethernet устройства. Те включват ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList и GenericReceiveOffloadUDPForwarding . Тези опции позволяват фина настройка на разтоварването на работата към хардуера и драйверите, което е от решаващо значение в корпоративни мрежи, центрове за данни и доставчици на услуги, които трябва да минимизират всяка милисекунда латентност.

Освен това, интерфейсите Varlink и JSON на systemd-networkd вече могат да докладват IP адреси в четлив за човек формат (низове), като същевременно запазват представянето като целочислен масив. Това опростява интеграцията с табла за мониторинг, скриптове за управление или инструменти на трети страни, които не искат да работят с неинтуитивни числови формати.

Преносимост на услуги, ефимерни виртуални машини и непривилегировани услуги

Компонентът systemd-portabled , отговорен за управлението на „преносими“ услуги, пакетирани в образи, получава много интересна възможност: вече може да се изпълнява като услуга на потребителско ниво . Това означава, че непривилегированите потребители, в нормалната си сесия, могат да стартират и управляват преносими услуги в собственото си пространство, без да прибягват до sudo или повишени привилегии.

Освен това, започвайки с тази версия, portabled може да генерира политики и да заключва образа, свързан с преносима услуга , предотвратявайки промяната на този образ без повторното му прикачване. Това позволява на потребителите да създават самостоятелни среди с добавени гаранции за непроменливост, особено привлекателна функция за лаборатории, среди за разработка и тестови пясъчникови среди.

От друга страна, systemd-vmspawn — инструментът, предназначен за стартиране на виртуални машини по интегриран начин със systemd — разширява възможностите си за регистрация със systemd-machined в рамките на потребителската сесия . Той също така въвежда опцията `-ephemeral` за създаване на ефимерни машини, които се унищожават след приключване на употребата им. Това е идеално за CI/CD конвейери, виртуални класни стаи или европейски образователни платформи, които изискват бързо и контролирано създаване и унищожаване на виртуални машини.

Фино настроен контрол на процесора, паметта и планирането с SCHED_EXT и THP

Systemd 260 също така се задълбочава в контрола на производителността с нови политики. Опцията за обслужване Политика за планиране на процесора = сега приемете стойността ext, което активира планировчика SCHED_EXTТози алтернативен планер отваря вратата към експерименти с различни политики за планиране към стандартите на ядрото, нещо, което може да представлява интерес за научноизследователски и развойни лаборатории или за високоспециализирани внедрявания.

В областта на паметта ще намерите `MemoryTHP=` , което ви позволява да управлявате използването на прозрачни огромни страници (THP) за всяка услуга. Вместо глобална настройка за цялата система, можете да решите дали дадено устройство трябва да използва THP, да го деактивира или да приеме междинни режими. За критични приложения в банковото дело, застраховането или правителството, този подробен контрол може да окаже значително влияние върху латентността, консумацията на памет и производителността.

Нови команди в systemctl и разширено използване на Varlink

Познатата команда systemctl получава нова: enqueue-marked . Това действие вътрешно извиква D-Bus метода EnqueueMarkedJobs() и позволява работа с опашки от предварително маркирани задачи и услуги. Макар че може да изглежда като незначителен детайл, за оперативните екипи, организиращи големи сървърни ферми, това е друг инструмент за усъвършенстване на работните процеси за внедряване и автоматизация.

Успоредно с това, проектът продължава да разширява използването на Varlink като механизъм за комуникация между компонентите. Много части на systemd предоставят стабилни Varlink интерфейси, които улесняват интеграцията с външни инструменти, персонализирани табла за управление или агенти за мониторинг, изискващи структуриран достъп до системна информация.

Полета за идентификация на системата и потребителско изживяване

Любопитна, но полезна нова функция за някои дистрибуции е въвеждането на полето FANCY_NAME= в архива /etc/os-releaseТова поле наподобява PRETTY_NAME, но позволява ANSI последователности и по-сложни Unicode символиБлагодарение на това, специфични дистрибуции и издания могат да бъдат представени с по-привличащи вниманието или отличителни имена.

Стойността на FANCY_NAME може да се види чрез systemd мениджъра, използвайки systemd-hostnamed или чрез заявка към hostnamectl . Въпреки че е малка промяна, в десктоп среди и графични панели за администриране тя може да бъде полезна за бързо идентифициране на управляваната система , особено при работа с много производни варианти.

Специфична документация за агенти с изкуствен интелект и работен процес с асистиран преглед

Един от най-интересните признаци за посоката на развитие на systemd е появата на документация, специално насочена към агенти с изкуствен интелект . Хранилището включва файл AGENTS.md , предназначен да помогне на инструментите за анализ на код и асистентите по програмиране, както и някои технологични ръководства , да разберат по-добре архитектурата, стила, процеса на разработка и насоките за принос на проекта.

Този документ описва компоненти, пътища за изграждане, как да се изпълняват тестове и интеграции, както и насоки за генериране на приемливи корекции. Целта е да се предостави на AI агентите, които преглеждат код или правят промени, солидно разбиране за това как е организиран systemd , намалявайки грешките и неуместните предложения.

Наред с AGENTS.md има файл, наречен CLAUDE.md , който изрично препраща към първия и е предназначен да насочва инструмента Claude Code, един от най-широко използваните асистенти за разработка, базирани на изкуствен интелект. По този начин проектът изрично включва изкуствен интелект в своя цикъл на разработка.

Освен това е включен конфигурационен файл. claude-review.ymlкъдето е дефинирано как трябва да се прегледа процесът на анализ на заявки за промени (заявки за изтегляне), с помощта на Claude Code. В този контекст, приносите, които са използвали изкуствен интелект, трябва да включват етикети за разкриване на информация като Co-developed-by в пачовете, оставяйки доказателства, че автоматизиран инструмент е участвал в създаването на кода.

С този цялостен набор от промени – почистване на остарялата поддръжка, усъвършенстване на пясъчната кутия, подобряване на TPM2 и SRK, разширена мрежова интеграция, нови възможности за преносимост и документация, предназначена за интелигентни агенти – systemd 260 засилва централната си роля в съвременната екосистема на Linux. За администраторите и разработчиците в Испания и Европа непосредственото предизвикателство е в прегледа на ядра, адаптирането на конфигурациите и услугите за зареждане и използването на тези функции за изграждане на по-сигурни, автоматизирани инфраструктури, съобразени с текущото използване на системата.