Добавление в systemd загрузчика для UEFI Secure Boot и другие планы на будущее
Разработчики системного менеджера 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;
Полный текст статьи читайте на OpenNet
