Systemd 260: TPM2, sandboxing e novas funcionalidades no Linux

Guia de Hardware » Guias de Compra » Systemd 260: TPM2, sandbox e novos recursos no Linux

Com a chegada do systemd 260, as distribuições Linux dão mais um passo importante rumo a um ecossistema mais moderno e seguro, voltado para ambientes de nuvem, virtualização e automação. Esta versão não se limita a aprimorar detalhes: ela introduz mudanças significativas na inicialização, gerenciamento de serviços, redes, uso do TPM2 para integridade e criptografia, e recursos de sandbox em nível de unidade.

Ao mesmo tempo, o projeto está aprimorando sua documentação e sua abordagem para trabalhar com agentes de inteligência artificial , deixando claro que o systemd é um pilar fundamental ao qual um número crescente de ferramentas de desenvolvimento e observabilidade está se conectando. Se você gerencia sistemas Linux em servidores, na nuvem, em desktops corporativos ou em laboratórios, vale a pena dedicar um momento para revisar todos esses novos recursos e planejar atualizações e ajustes de configuração.

Um adeus definitivo ao System V e à dependência total de discos rígidos nativos.

Uma das mudanças mais marcantes no systemd 260 é a remoção completa do suporte a scripts do System V. O processo de inicialização clássico baseado em /etc/init.d já vinha sendo descontinuado há anos, mas agora ele desaparece efetivamente do código do systemd.

Isso significa que os componentes responsáveis ​​pela ponte entre scripts SysV e unidades nativas foram removidos: systemd-rc-local-generator, rc-local.service, systemd-sysv-generator e systemd-sysv-install não existem mais. Como resultado, qualquer serviço que ainda dependa desses mecanismos legados simplesmente não será iniciado em sistemas que adotam o systemd 260.

Durante o processo de limpeza, várias opções de compilação do Meson foram marcadas como obsoletas ou removidas. As flags -Drc-local=, -Dsysvinit-path= e -Dsysvrcnd-path= foram relegadas aos arquivos, enquanto outras, como -Dintegration-tests= e -Dcryptolib=, foram removidas completamente. Isso envia uma mensagem clara: tudo agora deve ser gerenciado por unidades nativas e pela infraestrutura moderna do systemd.

Para muitas infraestruturas europeias que ainda dependem de componentes antigos, essa mudança exige uma revisão de serviços internos, scripts personalizados e implantações legadas. Migrar para arquivos de unidade bem definidos não é mais apenas recomendado; é obrigatório se você quiser continuar executando serviços em distribuições que integram o systemd 260.

Requisitos de kernel mais elevados e foco em ambientes atuais

A nova versão eleva o padrão para o kernel: a partir de agora, a versão mínima do Linux suportada é a 5.10 , deixando para trás versões muito antigas como a 5.4. Além disso, o projeto indica que, idealmente, os usuários devem trabalhar com um kernel 5.14 ou superior , e recomenda especialmente a série 6.6 para aproveitar ao máximo todos os recursos disponíveis.

Esse aumento nos requisitos geralmente não é um problema em distribuições modernas, mas pode complicar as coisas em ambientes muito conservadores ou em soluções embarcadas mantidas por muitos anos. Antes de atualizar para o systemd 260, é recomendável verificar qual kernel está sendo usado, especialmente em data centers europeus com implantações de longo prazo ou imagens personalizadas.

No extremo oposto do espectro, distribuições rolling release como Arch Linux ou openSUSE Tumbleweed, muito populares entre aqueles que desejam os recursos mais recentes, tendem a incorporar rapidamente novos kernels e novas versões do systemd. Outras, como o Fedora, mantêm um certo grau de estabilidade na versão principal do systemd ao longo do ciclo de vida de cada lançamento, o que permite um pouco mais de tempo para planejar migrações.

TPM2, integridade de inicialização e suporte avançado a SRK

Uma das áreas em que o systemd está evoluindo mais é na sua integração com o TPM2 (Trusted Platform Module 2.0) . Este chip, cada vez mais comum em placas-mãe UEFI modernas e em hardware de gama média e alta, permite ancorar segredos ao estado do sistema, medir as fases de inicialização e desbloquear automaticamente volumes criptografados quando o ambiente estiver como esperado.

O Systemd 260 aprimora ainda mais essa integração, adicionando ferramentas e serviços que abrangem diferentes estágios do processo de inicialização. Um componente essencial é o systemd-tpm2-setup , responsável por preparar a infraestrutura em torno da Chave Raiz de Armazenamento (SRK) do TPM . Essa chave raiz serve como base criptográfica para proteger a comunicação com o chip e para armazenar com segurança outros segredos.

Durante a inicialização, distinguem-se duas fases: uma inicial no initrd e outra no sistema raiz. Na primeira, um serviço chamado "Early TPM SRK Setup" verifica se o TPM já possui um SRK armazenado e, caso não exista, cria-o e o disponibiliza temporariamente em /run/systemd/tpm2-srk-public-key.* . Posteriormente, após a montagem do sistema de arquivos real, o serviço consolida o SRK e verifica se a chave armazenada em /var/lib/systemd/tpm2-srk-public-key.pem corresponde à chave no TPM.

Em cenários bem configurados, entradas de log como "SRK já está armazenado no TPM" e mensagens indicando que a pegada do SRK corresponde à esperada serão exibidas. No entanto, se o ambiente não estiver configurado corretamente (por exemplo, em configurações usando Yocto ou em placas como Raspberry Pi com TPM baseado em SPI e métodos de inicialização personalizados como U-Boot e inicialização medida), podem surgir situações em que o systemd não consegue criar esses arquivos em /var/lib/systemd, levantando dúvidas sobre se o SRK foi configurado corretamente.

Quando o estado do TPM é alterado, as partições são modificadas ou a sequência de inicialização é modificada, a política associada pode não ser mais válida. Nesses casos, alguns mantenedores recomendam limpar o slot ou a política do TPM e registrar novamente a chave , seguindo procedimentos semelhantes aos descritos nos guias de criptografia de disco com TPM em ambientes como o openSUSE, que detalham como recriar a política PCR e restabelecer o desbloqueio do volume.

Além do SRK, outra melhoria prática é a introdução de um utilitário interno chamado tpm2_id no udev . Essa ferramenta integrada é executada quando o sistema detecta um dispositivo TPM2 e extrai automaticamente o fabricante e o identificador do modelo . Isso simplifica o inventário de hardware de segurança, o que é muito útil em administrações públicas, empresas regulamentadas ou infraestruturas críticas onde é essencial saber precisamente quais módulos TPM estão implantados.

A integração com a infraestrutura de medição de inicialização é ainda mais reforçada por unidades específicas como o systemd-pcrextend , que registra eventos como "enter-initrd", "leave-initrd", "sysinit" e "ready" em vários PCRs (por exemplo, PCR 11). Essa sequência de extensões permite que o TPM acumule um registro criptograficamente verificável do fluxo de inicialização, que pode então ser usado para políticas de Inicialização Confiável ou para UKI (Unified Kernel Images) para validar o estado da máquina antes de liberar as chaves.

Medidas de segurança e isolamento de serviços com systemd

O Systemd não apenas inicia processos, mas também oferece um conjunto abrangente de diretivas de sandbox para isolar serviços e limitar danos em caso de comprometimento. Essa abordagem de "defesa em profundidade" se baseia em cgroups, namespaces, recursos do kernel e filtros de chamadas de sistema (seccomp).

Para avaliar a segurança de um serviço específico, o systemd inclui a ferramenta de segurança systemd-analyze . Ao executá-la, é gerado um relatório com uma pontuação de exposição em uma escala de 0 a 10, onde uma pontuação menor é melhor. O relatório detalha quais proteções estão habilitadas ou desabilitadas (isolamento de rede, acesso ao sistema de arquivos, acesso a dispositivos, etc.), facilitando a identificação de configurações ausentes e a verificação se as alterações realmente melhoram a pontuação.

Em vez de editar a unidade original — que seria perdida em futuras atualizações do pacote — recomenda-se criar uma override en /etc/systemd/system/mi-servicio.service.d/ com um arquivo, por exemplo, sandbox.confApós a modificação, basta recarregar a configuração com systemctl daemon-reload e reinicie o serviço para que as novas restrições entrem em vigor.

No nível do sistema de arquivos, uma das opções mais importantes é Sistema de proteção=Valores como strict, full o true Eles montam diferentes partes da árvore em modo somente leitura. A prática usual, quando possível, é usar ProtectSystem=strictIsso torna os diretórios /usr, /boot, /efi e /etc somente leitura para o serviço. Se um aplicativo precisar gravar em diretórios específicos, ele poderá fazê-lo usando Caminhos de leitura/gravação=/caminho na unidade.

Para aumentar ainda mais a privacidade, recomenda-se também restringir o acesso aos diretórios do usuário usando `ProtectHome=true` , o que impede que o serviço leia `/home`, `/root` ou `/run/user`. Além disso, `PrivateTmp=true` cria espaços isolados `/tmp` e `/var/tmp`, impedindo a visibilidade cruzada de arquivos temporários entre processos.

Em dispositivos, `PrivateDevices=true` oculta a árvore `/dev` real e a substitui por um conjunto mínimo de pseudodispositivos seguros (nulo, zero, aleatório, etc.). Se uma unidade precisar de um dispositivo específico (por exemplo, uma porta serial ou um bloco de disco), isso pode ser concedido usando `DeviceAllow=/dev/xxx rw` ou no modo somente leitura.

A rede também é um vetor fundamental. Com RedePrivada=verdadeiro É criado um espaço de nomes de rede isolado, deixando apenas o loopback; o serviço não verá as interfaces físicas e não poderá se comunicar com o mundo externo. Como alternativa, você pode restringir quais famílias de endereços ele pode usar. RestringirFamíliasDeEndereços=permitindo apenas AF_INET e AF_INET6 para IPv4/IPv6, AF_UNIX para sockets locais ou até mesmo none para totalmente "japonizar" as capacidades da rede.

Em relação aos privilégios, a diretiva `NoNewPrivileges=true` é uma das mais poderosas: ela impede que o processo adquira novos privilégios por meio de binários setuid ou alterações de capacidades. Resumindo, mesmo que o serviço execute código vulnerável, ele não deve conseguir escalar para root por meio de mecanismos tradicionais. Combinada com `CapabilityBoundingSet=` , que define a lista exata de capacidades permitidas (por exemplo, apenas `CAP_NET_BIND_SERVICE` para escutar em portas baixas), a superfície de ataque é minimizada.

Para ir ainda mais longe, o systemd permite filtrar chamadas de sistema com Filtro de Chamadas do Sistema=Em vez de manter uma lista manual de chamadas de sistema, são utilizados grupos predefinidos, como: @system-service, @network-io, @basic-io ou negar grupos como ~@privileged. com systemd-analyze syscall-filter É possível inspecionar quais chamadas específicas pertencem a cada grupo. Isso permite a construção de um perfil de execução muito limitado, semelhante ao que um ambiente de teste dedicado ofereceria.

Outras configurações relevantes incluem `ProtectKernelTunables=true` , que bloqueia a modificação de parâmetros do kernel em `/proc/sys` e `/sys`; `ProtectKernelModules=true` , que impede o carregamento ou descarregamento de módulos; `ProtectKernelLogs=true` , que impede a leitura de logs do kernel; e `ProtectControlGroups=true` , que bloqueia gravações na hierarquia de cgroups. Tudo isso funciona perfeitamente com novos recursos de isolamento de usuários, como ` PrivateUsers=full` , que na versão 260 foi atualizado para mapear toda a gama de IDs de usuário, eliminando as soluções alternativas anteriores necessárias para ambientes systemd aninhados.

Usuários privados, xaccess e novos controles de acesso a dispositivos

O mecanismo PrivateUsers , projetado para permitir que os serviços sejam executados em um espaço de ID de usuário isolado, foi consolidado no systemd 260. A opção PrivateUsers=full agora mapeia toda a gama de identificadores, simplificando as coisas em contêineres e em sistemas com instâncias aninhadas do systemd baseadas em versões mais antigas (anteriores à 257). Essa melhoria eliminou as soluções alternativas que eram usadas anteriormente para detectar essas instâncias mais antigas.

Em paralelo, componentes como systemd-logind e systemd-udevd introduziram o conceito de xaccess . Esse mecanismo complementa a lógica clássica do uaccess , que concede acesso a determinados dispositivos (por exemplo, áudio ou vídeo) a usuários com sessões gráficas em primeiro plano na máquina local. Com o xaccess, as permissões podem ser delegadas a usuários remotos com sessões especialmente marcadas , de modo que, por exemplo, um usuário conectado via área de trabalho remota possa acessar dispositivos de renderização de GPU locais sem conceder permissões amplas a todo o sistema.

A configuração dessas sessões envolve variáveis ​​de ambiente expostas via PAM, especificamente PAMXDG_SESSION_EXTRA_DEVICE_ACCESS= , que permite definir quais dispositivos específicos estão incluídos nessa lógica. Essa abordagem está altamente alinhada com os requisitos de conformidade regulatória e proteção de dados da União Europeia, onde granularidade e rastreabilidade são exigidas para o acesso a hardware sensível.

mstack, systemd-mstack e novas ferramentas de contêiner

Na área de conteinerização, o systemd 260 introduz a funcionalidade pilha e um comando associado, systemd-mstackA ideia por trás do mstack é permitir a definição de um Sobreposição FS com base na estrutura de um diretório especial chamado .mstack/, que segue uma especificação específica para organizar suas camadas.

A nova ferramenta de linha de comando, systemd-mstack, facilita o trabalho interativo com essas pilhas de sistemas de arquivos, adicionando flexibilidade na configuração de ambientes em camadas para contêineres ou serviços altamente isolados. Essa funcionalidade também está ligada a melhorias no systemd-importd , que expande seu suporte para download e gerenciamento de imagens OCI , reforçando assim o papel do systemd como um mecanismo de conteinerização e isolamento de processos (sandboxing), algo muito comum entre provedores de nuvem europeus e plataformas de hospedagem modernas.

Rede: Integração com o ModemManager e novas opções de desempenho.

Na camada de rede, o systemd-networkd continua a ganhar importância. Uma das novas funcionalidades notáveis ​​é a sua integração com o ModemManager através do protocolo "simple connect" , que permite que modems e conexões móveis sejam gerenciados diretamente pelo networkd sem depender de ferramentas externas.

Para dar suporte a esse fluxo, uma nova seção foi adicionada. aos arquivos de configuração, com parâmetros como APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=Isso facilita as implantações em áreas rurais ou ambientes com conectividade baseada em redes móveis, muito presente em certos territórios da Europa onde nem sempre existe fibra ótica ou linhas telefônicas de qualidade.

Em termos de desempenho, os arquivos .link do systemd-networkd incluem novas opções específicas para dispositivos Ethernet. Estas incluem ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList e GenericReceiveOffloadUDPForwarding . Essas opções permitem o ajuste fino da transferência de tarefas para o hardware e os drivers, o que é crucial em redes corporativas, data centers e provedores de serviços que precisam minimizar cada milissegundo de latência.

Além disso, as interfaces Varlink e JSON do systemd-networkd agora podem reportar endereços IP em um formato legível por humanos (strings), mantendo a representação como um array de inteiros. Isso simplifica a integração com painéis de monitoramento, scripts de gerenciamento ou ferramentas de terceiros que não desejam lidar com formatos numéricos pouco intuitivos.

Portabilidade de serviços, máquinas virtuais efêmeras e serviços não privilegiados.

O componente systemd-portabled , responsável por gerenciar serviços "portáteis" empacotados em imagens, ganha uma capacidade muito interessante: agora ele pode ser executado como um serviço de nível de usuário . Isso significa que usuários sem privilégios, em sua sessão normal, podem iniciar e gerenciar serviços portáteis em seu próprio espaço sem recorrer ao sudo ou a privilégios elevados.

Além disso, a partir desta versão, o portabled pode gerar políticas e bloquear a imagem associada a um serviço portátil , impedindo a modificação dessa imagem sem que ela seja anexada novamente. Isso permite que os usuários configurem ambientes autocontidos com garantias adicionais de imutabilidade, um recurso particularmente atraente para laboratórios, ambientes de desenvolvimento e sandboxes de teste.

Por outro lado, o systemd-vmspawn — a ferramenta projetada para iniciar máquinas virtuais de forma integrada com o systemd — expande suas capacidades para se registrar no systemd-machined dentro da sessão do usuário . Ele também introduz a opção `-ephemeral` para criar máquinas efêmeras que são destruídas após o término de seu uso. Isso é perfeito para pipelines de CI/CD, salas de aula virtuais ou plataformas educacionais europeias que exigem a criação e destruição rápidas e controladas de máquinas virtuais.

Controle preciso de CPU, memória e agendamento com SCHED_EXT e THP.

O Systemd 260 também aprofunda o controle de desempenho com novas políticas. A opção de serviço Política de agendamento de CPU = agora aceite o valor ext, que ativa o agendador SCHED_EXTEste planejador alternativo abre as portas para experimentos com diferentes políticas de planejamento para os padrões do kernel, algo que pode ser de interesse em laboratórios de P&D ou em implantações altamente especializadas.

Na área de memória, você encontrará `MemoryTHP=` , que permite gerenciar o uso de Páginas Grandes Transparentes (THP) por serviço. Em vez de uma configuração global para todo o sistema, você pode decidir se uma unidade específica deve utilizar THP, desativá-la ou adotar modos intermediários. Para aplicações críticas em bancos, seguradoras ou órgãos governamentais, esse controle granular pode fazer uma diferença significativa na latência, no consumo de memória e no desempenho.

Novos comandos no systemctl e uso expandido do Varlink

O conhecido comando systemctl ganha uma nova opção: enqueue-marked . Essa ação invoca internamente o método EnqueueMarkedJobs() do D-Bus e permite trabalhar com filas de tarefas e serviços pré-marcados. Embora possa parecer um detalhe menor, para equipes de operações que orquestram grandes conjuntos de servidores, trata-se de mais uma ferramenta para refinar os fluxos de trabalho de implantação e automação.

Em paralelo, o projeto continua a expandir o uso do Varlink como mecanismo de comunicação entre componentes. Muitas partes do systemd expõem interfaces Varlink estáveis, o que facilita a integração com ferramentas externas, painéis personalizados ou agentes de monitoramento que exigem acesso estruturado às informações do sistema.

Campos de identificação do sistema e experiência do usuário

Uma nova funcionalidade curiosa, mas útil, para algumas distribuições é a introdução do campo NOME_FANCY= no arquivo /etc/os-releaseEste campo se assemelha a PRETTY_NAME, mas permite Sequências ANSI e caracteres Unicode mais elaborados.Graças a isso, distribuições e edições específicas podem ser apresentadas com nomes mais chamativos ou distintos.

O valor de FANCY_NAME pode ser visualizado através do gerenciador do systemd, usando o systemd-hostnamed ou consultando o hostnamectl . Embora seja uma pequena alteração, em ambientes de desktop e painéis de administração gráfica, pode ser útil para identificar rapidamente o sistema que está sendo gerenciado, especialmente ao lidar com muitas variantes derivadas.

Documentação específica para agentes de IA e fluxo de trabalho de revisão assistida

Um dos sinais mais interessantes da direção do desenvolvimento do systemd é o surgimento de documentação voltada especificamente para agentes de inteligência artificial . O repositório inclui um arquivo AGENTS.md , projetado para ajudar ferramentas de análise de código e assistentes de programação, bem como alguns guias de tecnologia , a entender melhor a arquitetura, o estilo, o fluxo de desenvolvimento e as diretrizes de contribuição do projeto.

Este documento descreve componentes, caminhos de compilação, como executar testes e integrações, além de diretrizes para gerar patches aceitáveis. O objetivo é fornecer aos agentes de IA que revisam o código ou fazem alterações um sólido entendimento de como o systemd está organizado , reduzindo erros e sugestões inadequadas.

Junto ao arquivo AGENTS.md, existe um arquivo chamado CLAUDE.md , que faz referência explícita ao primeiro e foi projetado para orientar a ferramenta Claude Code, um dos assistentes de desenvolvimento baseados em IA mais utilizados. Dessa forma, o projeto incorpora explicitamente a IA em seu ciclo de desenvolvimento.

Além disso, um arquivo de configuração está incluído. claude-review.ymlonde se define como o processo de análise de solicitações de alteração (pull requests) deve ser revisado, com o auxílio de Claude Code. Nesse contexto, contribuições que utilizaram IA devem ser incorporadas. rótulos de divulgação como Co-developed-by nos patches, deixando evidências de que uma ferramenta automatizada participou da criação do código.

Com este conjunto abrangente de mudanças — incluindo a limpeza do suporte a sistemas legados, o aprimoramento do sandboxing, a melhoria do TPM2 e do SRK, a integração avançada de redes, novos recursos de portabilidade e documentação projetada para agentes inteligentes — o systemd 260 reforça seu papel central no ecossistema Linux moderno. Para administradores e desenvolvedores na Espanha e na Europa, o desafio imediato reside na revisão dos kernels, na adaptação das configurações de inicialização e dos serviços, e no aproveitamento desses recursos para construir infraestruturas mais seguras e automatizadas, alinhadas ao uso atual do sistema.