Systemd 260: TPM2, пісочниця та нові можливості в Linux

Посібник з обладнання » Посібники покупця » Systemd 260: TPM2, «пісочниця» та нові можливості в 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 , який відповідає за підготовку інфраструктури навколо кореневого ключа сховища (SRK) TPM . Цей кореневий ключ служить криптографічною основою для захисту зв'язку з чіпом та безпечного зберігання інших секретів.

Під час завантаження розрізняють дві фази: дуже ранню в 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 з TPM на основі SPI та користувацькими методами завантаження, такими як 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 не лише запускає процеси, але й пропонує повний набір директив «пісочниці » для ізоляції служб та обмеження шкоди у разі компрометації. Цей підхід «глибинного захисту» спирається на контрольні групи, простори імен, можливості ядра та фільтри системних викликів (seccomp).

Для оцінки безпеки певного сервісу systemd містить інструмент безпеки systemd-analyze . Його запуск генерує звіт з оцінкою ризику за шкалою від 0 до 10, де нижчий бал кращий. У звіті детально описано, які засоби захисту ввімкнено або вимкнено (ізоляція мережі, доступ до файлової системи, доступ до пристроїв тощо), що дозволяє легко виявити відсутні налаштування та перевірити, чи зміни дійсно покращують оцінку.

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

На рівні файлової системи одним із найважливіших параметрів є ProtectSystem=Такі цінності, як 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` або в режимі лише для читання.

Мережа також є ключовим вектором. З ПриватнаМережа=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-фільтр Можна перевірити, які конкретні виклики належать до кожної групи. Це дозволяє створити дуже обмежений профіль виконання, подібний до того, що пропонує спеціальна пісочниця.

Інші відповідні налаштування включають `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 дозволи можна делегувати віддаленим користувачам зі спеціально позначеними сеансами , так що, наприклад, користувач, підключений через віддалений робочий стіл, може отримати доступ до локальних пристроїв рендерингу на графічному процесорі, не надаючи широких дозволів для всієї системи.

Конфігурація цих сеансів включає змінні середовища, що надаються через PAM, зокрема PAMXDG_SESSION_EXTRA_DEVICE_ACCESS= , що дозволяє визначити, які саме пристрої включені до цієї логіки. Цей підхід тісно відповідає вимогам Європейського Союзу щодо відповідності нормативним вимогам та захисту даних, де для доступу до конфіденційного обладнання потрібна детальність та відстежуваність.

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

В області контейнеризації, systemd 260 вводить функціональність стек м та пов'язана команда, systemd-mstackІдея mstack полягає в тому, щоб дозволити визначення OverlayFS на основі структури спеціального каталогу під назвою .mstack/, який відповідає певній специфікації для організації своїх шарів.

Новий інструмент командного рядка systemd-mstack спрощує інтерактивну роботу з цими стеками файлових систем, додаючи гнучкості під час налаштування багаторівневих середовищ для контейнерів або високоізольованих сервісів. Ця функціональність також пов'язана з покращеннями в systemd-importd , який розширює підтримку завантаження та керування образами OCI , тим самим посилюючи роль systemd як механізму контейнеризації та «пісочниці», що дуже поширено серед європейських постачальників хмарних послуг та сучасних хостингових платформ.

Мережа: Інтеграція з ModemManager та нові параметри продуктивності

На мережевому рівні systemd-networkd продовжує набувати на важливості. Однією з помітних нових функцій є його інтеграція з ModemManager через протокол "простого підключення" , що дозволяє керувати модемами та мобільними з'єднаннями безпосередньо з 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 , розроблений, щоб допомогти інструментам аналізу коду та помічникам програмування, а також деякі технологічні посібники краще зрозуміти архітектуру, стиль, процес розробки та правила внеску проекту.

У цьому документі описано компоненти, шляхи збірки, способи проведення тестів та інтеграцій, а також рекомендації щодо створення прийнятних патчів. Мета полягає в тому, щоб надати агентам ШІ, які переглядають код або вносять зміни, чітке розуміння того, як організовано systemd , зменшуючи кількість помилок та недоречних пропозицій.

Поряд із AGENTS.md є файл під назвою CLAUDE.md , який явно посилається на перший і призначений для керівництва інструментом Claude Code, одним із найпоширеніших помічників розробки на основі штучного інтелекту. Таким чином, проєкт явно інтегрує штучний інтелект у свій цикл розробки.

Крім того, додається файл конфігурації. claude-review.ymlде визначено, як слід переглядати процес аналізу запитів на зміни (запитів на зняття) за допомогою Claude Code. У цьому контексті внески, що використовували штучний інтелект, повинні включати розкриття інформації як Co-developed-by у виправленнях, залишаючи докази того, що у створенні коду брав участь автоматизований інструмент.

Завдяки цьому комплексному набору змін — очищенню застарілої підтримки, вдосконаленню «пісочниці», покращенню TPM2 та SRK, розширеній мережевій інтеграції, новим можливостям перенесення та документації, розробленій для інтелектуальних агентів — systemd 260 посилює свою центральну роль у сучасній екосистемі Linux. Для адміністраторів та розробників в Іспанії та Європі нагальним завданням є перегляд ядер, адаптація конфігурацій завантаження та служб, а також використання цих функцій для створення більш безпечних, автоматизованих інфраструктур, що відповідають поточному використанню системи.