Разработчики системного менеджера systemd намерены интегрировать в состав пакета поддержку загрузчика gummiboot для обеспечения верификации процесса загрузки на системах с UEFI Secure Boot. Верификация загрузки позволит гарантировать отсутствие посторонней активности во время начальной загрузки, в том числе даст возможность присечь попытки запуска подконтрольных злоумышленникам приложений, например, внедрённых для перехвата ввода паролей к зашифрованным разделам.

Ранее поддержка верификации, как правило, ограничивалась проверкой загрузчика или верификацией загрузки ядра и связанных с ним модулей. Разработчики systemd предлагают расширить число проверяемых компонентов, дав возможность пользователю разрешить загрузку только специально подписанных системных образов начальной загрузки (initramfs). Даже получив доступ к системе атакующие не смогут внести изменения в initramfs чтобы запустить кейлоггер и перехватить ввод пароля к зашифрованному корневому разделу.

Загрузчик gummiboot выбран так как он является разработкой Red Hat, изначально поддерживает интеграцию с systemd и не требует специальной настройки — он автоматически выявляет конфигурацию ядра и наличие на диске заверенных цифровой подписью EFI-образов и добавляет их в меню загрузки.

Дополнительно можно отметить публикацию тезисов выступления Леннарта Поттеринга (Lennart Poettering) на конференции FOSDEM, в котором он рассказал о последних тендерция в разработке systemd и планах на ближайшее будущее.

Некоторые интересные выдержки из доклада:

• В systemd появится поддержка перезапуска сервисов без потери состояния — каждый демон сможе сохранять на диске своё минимальное состояние и после перезапуска восстановить исходное состояние (systemd сохранит открытые сокеты и файловые дескрипторы и после перезапуска передаст их сервису).
• Ожидается минимальная поддержка средств управления межсетевым экраном в привязке к сервисам, а не номерам портов. Например, вместо определения правил доступа к 80 порту, можно будет привязать правила к http-серверу apache, без оглядки на то, на каком порту он принимает соединения.
• Приоритетным остаётся подход, при котором большая часть подсистем systemd, за исключением journald, не являются обязательными и могут быть отключены;
• Практически доведена на конца работа над компонентами пространства пользователя для dbus;
• Nspawn вырос из системы тестирования системы инициализации без перезагрузки в систему управления изолированными контейнерами, поддерживающую RAW-образы и docker-подобные контейнеры. Под впечатлением от концепции Solaris zone развивается machined — менеджер регистрации виртуальных машин;
• В будущем ожидается появление новых возможностей, связанных с изолированными контейнерами. В конечном счёте, целью является обеспечение работы всех инструментов systemd с оглядкой на контейнеры, например, journald может показывать как логи/сообщения основного хоста, так и всех работающих на нём контейнеров;
• В следующем выпуске systemd появится дополнительная поддержка Btrfs (подразделы и снапшоты Btrfs планируется использовать для изоляции отдельных приложений);
• В consoled появится поддержка экранов high DPI и Unicode;
• Утилиты systemctl-cat и systemctl-edit позволят отобразить и отредактировать файл конфигурации выбранного юнита (например, «systemctl-cat apache2.service»), без необходимости определения пути.
• Команда «ping gateway» позволит автоматически определить все доступные сетевые интерфейсы и проверить их работу утилитой ping;
• Развитие networkd и средств для автоматической настройки сетевой конфигурации в изолированных контейнерах. Создание собственной библиотеки для работы с DHCP (dhcpv4 и dhcpv6);
• Создание средств для проведения системного аудита, например, для ведения полного лога системных вызовов, связанных с /etc/passwd. Добавление средств аудита в journald и реализация в audit-tools возможности чтения сохранённых в journald логов;
• Обеспечение работы систем, не сохраняющих своё состояние (stateless). Генерация содержимого /etc и /var для таких систем.
• Возможность journald-remoting для передачи бинарных логов на удалённый хост с использованием HTTP вместо протокола syslog. Поддержка в journald моделей pull и push: при pull выполняется запрос HTTP GET для получения потока JSON, а при push данные передаются в другой экземпляр journald при помощи HTTP POST. Поддержка данных режимов позволит существенно упросить отправку логов из различных программ, вместо поддержки syslog в которых достаточно будет отправить запрос по HTTP.
• Возможность определения минимальных пространств имён и sandbox-изоляции для сервисов, например, для выбранных сервисов можно будет сделать доступ к /usr и /home в режиме только на чтение или вообще скрыть или запретить доступ. Возможность использования отдельных директорий /tmp для определённых сервисов. Возможность ограничения доступа к файлам устройств /dev/*, с сохранением возможности работы с /dev/zero, /dev/null и т.п.
• Развитие простого ntp-клиента timesyncd в качестве минималистичной альтернативы ntpd;
• Автоматическое определение разделов GPT (GUID Partition Table) без их явного перечисления в etc/fstab;