Después de cinco meses de desarrollo, se presenta el lanzamiento del gestor de sistemas systemd 252. La principal novedad de esta versión es la integración del soporte para un proceso de arranque modernizado, que permite verificar mediante firmas digitales no solo el núcleo y el cargador, sino también los componentes del entorno básico del sistema.
El método propuesto implica el uso de una imagen de núcleo unificada (UKI - Unified Kernel Image) durante el arranque, que combina el manejador para cargar el núcleo desde UEFI (UEFI boot stub), la imagen del núcleo de Linux y el entorno del sistema initrd que se carga en memoria y se utiliza para la inicialización inicial antes de montar el sistema de archivos raíz. La imagen UKI se presenta como un único archivo ejecutable en formato PE, que puede ser cargado mediante cargadores tradicionales o ser llamado directamente desde el firmware UEFI. Al ser llamado desde UEFI, se proporciona la posibilidad de verificar la integridad y autenticidad mediante firma digital no solo del núcleo, sino también del contenido de initrd.
Para el cálculo de los parámetros de los registros PCR (Platform Configuration Register del Módulo de Plataforma Confiable - TPM), que se utilizan para controlar la integridad y formar la firma digital de la imagen UKI, se ha incluido una nueva utilidad llamada systemd-measure. La clave pública utilizada en la firma y la información asociada sobre PCR pueden ser integradas directamente en la imagen de arranque UKI (la clave y la firma se guardan en un archivo en formato PE en los campos ' .pcrsig ' y ' .pcrkey ') y pueden ser extraídas por utilidades externas o internas.
También se han adaptado las utilidades systemd-cryptsetup, systemd-cryptenroll y systemd-creds para aprovechar esta información, permitiendo vincular particiones de disco encriptadas a un núcleo que ha sido verificado mediante firma digital (en este caso, el acceso a la partición encriptada solo se proporciona si la imagen UKI ha pasado la verificación de firma digital basada en los parámetros almacenados en el TPM).
Además, se ha incluido la utilidad systemd-pcrphase, que permite gestionar la vinculación de diferentes etapas del arranque a los parámetros almacenados en la memoria de los criptoprocesadores que soportan la especificación TPM 2.0 (por ejemplo, se puede hacer que la clave de descifrado de la partición LUKS2 sea accesible solo en la imagen initrd y bloquear su acceso en etapas posteriores del arranque).
Otros cambios incluyen:
- Se proporciona el uso predeterminado de la configuración regional C.UTF-8, a menos que se especifique otra en la configuración.
- Se ha implementado la posibilidad de realizar una operación de configuración completa de los servicios (‘systemctl preset’) durante el primer arranque. Para habilitar la preconfiguración durante el arranque, es necesaria una compilación con la opción ‘-Dfirst-boot-full-preset’, aunque en futuras versiones se planea activarla por defecto.
- En las unidades de gestión de usuarios se ha implementado un controlador de recursos CPU, lo que permite aplicar la configuración CPUWeight a todas las unidades slice utilizadas para dividir el sistema en partes (app.slice, background.slice, session.slice) para aislar recursos entre diversos servicios de usuario que compiten por recursos de CPU. En CPUWeight también se ha añadido soporte para el valor ‘idle’ para activar el modo correspondiente de provisión de recursos.
- En las unidades ‘transitarias’ y en la utilidad systemd-repart se permite la sobreescritura de configuraciones mediante la creación de archivos drop-in en el directorio /etc/systemd/system/nombre.d/.
- Para las imágenes del sistema se ha establecido la bandera de finalización del soporte (‘support-ended’), definiendo este hecho en función del valor del nuevo parámetro ‘SUPPORT_END=’ en el archivo /etc/os-release.
- Se han añadido las configuraciones ‘ConditionCredential=’ y ‘AssertCredential=’, que se pueden utilizar para ignorar o finalizar abruptamente unidades en caso de que ciertos credenciales no estén presentes en el sistema.
- En system.conf y user.conf se han añadido las configuraciones ‘DefaultSmackProcessLabel=’ y ‘DefaultDeviceTimeoutSec=’ para definir el nivel de seguridad SMACK y el tiempo de espera para la activación de unidades que se aplican por defecto.
- En las configuraciones ‘ConditionFirmware=’ y ‘AssertFirmware=’ se ha añadido la posibilidad de especificar campos individuales SMBIOS, por ejemplo, para activar una unidad solo si el campo /sys/class/dmi/id/board_name contiene el valor ‘Custom Board’, se puede especificar ‘ConditionFirmware=smbios-field(board_name = ‘Custom Board’).
- En el proceso de inicialización (PID 1) se ha añadido la posibilidad de importar credenciales desde campos SMBIOS (Tipo 11, ‘cadenas de proveedor OEM’) además de definirlas a través de qemu_fwcfg, lo que simplifica la provisión de credenciales máquinas virtuales y permite prescindir de herramientas externas como cloud-init e ignition.
- Durante el apagado, se ha cambiado la lógica de desmontaje de los sistemas de archivos virtuales (proc, sys) y se ha asegurado el registro de información sobre los procesos que bloquean el desmontaje de los sistemas de archivos.
- En el filtro de llamadas del sistema (SystemCallFilter) se permite por defecto el acceso a la llamada al sistema riscv_flush_icache.
- En el cargador sd-boot se ha añadido la opción de arranque en modo mixto, donde el núcleo de Linux de 64 bits se inicia desde un firmware de 32 bits UEFI. Se ha añadido una opción experimental para aplicar automáticamente las claves de SecureBoot desde archivos encontrados en la ESP (partición del sistema EFI).
- Se han añadido nuevas opciones a la utilidad bootctl como «—all-architectures» para instalar archivos binarios para todas las arquitecturas EFI compatibles, «—root=» y «—image=» para trabajar con un directorio o una imagen de disco, «—install-source=» para especificar la fuente para la instalación, y «—efi-boot-option-description=» para gestionar los nombres de las entradas de arranque.
- A la utilidad systemctl se ha añadido el comando ‘list-automounts’ para mostrar la lista de directorios montados automáticamente y la opción «—image=» para ejecutar comandos vinculados a una imagen de disco especificada. En los comandos ‘show’ y ‘status’ se han añadido las opciones «—state=» y «—type=».
- En systemd-networkd se han añadido las opciones «TCPCongestionControlAlgorithm=» para seleccionar el algoritmo de control de congestión TCP, «KeepFileDescriptor=» para preservar el descriptor de archivo de las interfaces TUN/TAP, «NetLabel=» para establecer etiquetas NetLabel, y «RapidCommit=» para acelerar la configuración a través de DHCPv6 (RFC 3315). En el parámetro «RouteTable=» se permite la especificación de nombres de tablas de enrutamiento.
- En systemd-nspawn se permite el uso de rutas de archivo relativas en las opciones «—bind=» y «—overlay=». A la opción «—bind=» se le ha añadido soporte para el parámetro ‘rootidmap’ que vincula el identificador de usuario root en el contenedor con el propietario del directorio montado en el sistema host.
- En systemd-resolved, se ha implementado el paquete OpenSSL como backend por defecto para el cifrado (el soporte para gnutls se ha mantenido como opción). Los algoritmos DNSSEC no soportados ahora se manejan como inseguros, en lugar de devolver un error (SERVFAIL).
- En systemd-sysusers, systemd-tmpfiles y systemd-sysctl se ha implementado la posibilidad de pasar configuraciones a través del mecanismo de almacenamiento de credenciales.
- A la utilidad systemd-analyze se le ha añadido el comando ‘compare-versions’ para comparar cadenas de números de versión (similar a ‘rpmdev-vercmp’ y ‘dpkg —compare-versions’). Al comando ‘systemd-analyze dump’ se le ha añadido la capacidad de filtrar unidades por una máscara.
- Al seleccionar el modo de suspensión de múltiples etapas (suspend-then-hibernate, transición a modo de suspensión después del modo de espera), el tiempo en modo de espera se basa en la predicción del tiempo restante de autonomía. La transición instantánea a modo de suspensión se realiza cuando queda menos del 5% de carga de la batería.
- Se ha agregado un nuevo modo de salida «-o short-delta» en ‘journalctl’, que muestra la diferencia de tiempo entre diferentes mensajes en el registro.
- Se añadió soporte en systemd-repart para crear particiones con el sistema de archivos Squashfs y particiones para dm-verity, incluidas las que tienen firmas digitales.
- Se agregó la configuración «StopIdleSessionSec=» en systemd-logind para finalizar la sesión inactiva después de que transcurra el tiempo de espera especificado.
- Se agregó la opción «—unlock-key-file=» en systemd-cryptenroll para extraer la clave de descifrado de un archivo, en lugar de solicitarla al usuario.
- Se ha habilitado la ejecución de la herramienta systemd-growfs en entornos sin udev.
- Se ha mejorado el soporte en systemd-backlight para sistemas con múltiples tarjetas gráficas.
- La licencia de los ejemplos de código presentados en la documentación ha sido cambiada de CC0 a MIT-0.
Cambios que rompen la compatibilidad:
- Al verificar el número de versión del núcleo utilizando la directiva ConditionKernelVersion, en los operadores ‘=’ y ‘!=’ ahora se aplica una comparación de cadenas simple, y si no se especifica ningún operador de comparación, se puede utilizar una coincidencia de glob con los caracteres ‘*’, ‘?’ y ‘[‘, ‘]’. Para comparar versiones al estilo de la función stverscmp(), se deben utilizar los operadores ‘’, ‘=’.
- La etiqueta SELinux utilizada para la verificación de acceso desde el archivo de unidad ahora se lee en la etapa de carga del archivo, en lugar de en el momento de la verificación de acceso.
- La condición «ConditionFirstBoot» ahora se activa en el primer arranque del sistema solo en la etapa de arranque y devuelve «false» al invocar unidades después de completar el arranque.
- En 2024, se planea que systemd deje de soportar el mecanismo de limitación de recursos cgroup v1, el cual ha sido clasificado como obsoleto desde el lanzamiento de systemd 248. Se recomienda a los administradores que se preparen con anticipación para la migración a cgroup v2 de los servicios que dependen de cgroup v1. La principal diferencia entre cgroups v2 y v1 es la utilización de una jerarquía común de cgroups para todos los tipos de recursos, en lugar de jerarquías separadas para la asignación de recursos de CPU, regulación del consumo de memoria y entrada/salida. Las jerarquías separadas crean dificultades en la organización de la interacción entre los manejadores y generan un costo adicional de recursos del núcleo al aplicar reglas para un proceso que se menciona en diferentes jerarquías.
- En la segunda mitad de 2023, se planea finalizar el soporte para jerarquías de directorios separadas, cuando /usr se monte por separado de la raíz o los directorios /bin y /usr/bin, /lib y /usr/lib estén separados.
Fuente: opennet.ru
