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 , отвечающий за подготовку инфраструктуры вокруг корневого ключа хранилища TPM (SRK) . Этот корневой ключ служит криптографической основой для защиты связи с чипом и для безопасного хранения других секретов.

В процессе загрузки различают две фазы: очень раннюю, в initrd, и еще одну, уже в корневой системе. На первой фазе служба под названием "Ранняя настройка SRK TPM" проверяет, есть ли у 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 и измеренная загрузка), могут возникнуть ситуации, когда systemd не сможет создать эти файлы в /var/lib/systemd, что вызовет сомнения в правильности настройки SRK.

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

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

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

Меры безопасности и изоляция сервисов с помощью systemd

Systemd не только запускает процессы, но и предлагает полный набор директив песочницы для изоляции служб и ограничения ущерба в случае компрометации. Такой подход «многоуровневой защиты» основан на группах cgroup, пространствах имен, возможностях ядра и фильтрах системных вызовов (seccomp).

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

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

На уровне файловой системы одним из наиболее важных параметров является ProtectSystem=Значения, такие как strict, full o true Они монтируют различные части дерева в режиме только для чтения. Обычно, по возможности, используется следующий подход: ProtectSystem=strictЭто делает каталоги /usr, /boot, /efi и /etc доступными только для чтения для данной службы. Если приложению необходимо записывать данные в определенные каталоги, оно может сделать это, используя ReadWritePaths=/path в единстве.

Для дальнейшего повышения уровня конфиденциальности рекомендуется также ограничить доступ к пользовательским каталогам с помощью параметра `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-analyze syscall-filter Можно проверить, какие именно вызовы относятся к каждой группе. Это позволяет создать очень ограниченный профиль выполнения, аналогичный тому, что предлагает выделенная песочница.

К другим важным параметрам относятся `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 представляет функциональность мстек и связанная с ней команда, systemd-mstackИдея mstack заключается в том, чтобы позволить определить ОверлейФС основано на структуре специального каталога, называемого .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 также углубляется в управление производительностью с помощью новых политик. Опция обслуживания. CPUSchedulingPolicy= теперь примите значение 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где определено, как следует проводить анализ запросов на изменения (pull requests) с помощью Claude Code. В этом контексте от разработчиков, внесших вклад в разработку с использованием ИИ, требуется включить следующие элементы: Информационные этикетки в качестве Co-developed-by в этих патчах, оставляя следы того, что в создании кода участвовал автоматизированный инструмент.

Благодаря этому всеобъемлющему набору изменений — улучшению поддержки устаревших систем, усовершенствованию песочницы, улучшению TPM2 и SRK, расширенной интеграции с сетью, новым возможностям переносимости и документации, разработанной для интеллектуальных агентов — systemd 260 укрепляет свою центральную роль в современной экосистеме Linux. Для администраторов и разработчиков в Испании и Европе первоочередная задача состоит в пересмотре ядер, адаптации конфигураций загрузки и служб, а также в использовании этих функций для создания более безопасных, автоматизированных инфраструктур, соответствующих текущему использованию системы.