Contêineres baseados em imagens Ubuntu Pro 22.04 FIPS falhavam silenciosamente em kernels mainline, os mesmos usados por ambientes de Kubernetes gerenciado como AWS EKS e Fargate. O caso foi reportado à Canonical durante uma migração para FedRAMP, e o diagnóstico não apontava para erro de configuração.
A flag que não existe no kernel mainline
A causa raiz estava em uma dependência fixa do pacote libgcrypt20-fips em GRND_RESEED_ONLY, uma flag de kernel específica do Ubuntu introduzida na implementação FIPS da Canonical. Essa flag não existe nos kernels mainline padrão do Linux.
Quando o libgcrypt20-fips chamava getrandom() com GRND_RESEED_ONLY, a syscall retornava erro nesses kernels e o contêiner morria. A imagem estava idêntica a uma que funcionava em kernel Jammy FIPS, e o host era totalmente compatível com FIPS, mas o pacote chamava uma syscall que o kernel de baixo não suportava.
O cliente chegou a esse diagnóstico por conta própria, com apoio de relatórios públicos de bug e testes internos, e levou à Canonical nomes de pacotes e condições de erro específicas, incluindo o bug 2055825 no Launchpad.
Por que isso afeta mais do que um cliente
Essa arquitetura é comum em ambientes sob exigências de FedRAMP, FISMA ou DoD que rodam imagens Ubuntu Pro FIPS sobre Kubernetes gerenciado com kernels mainline. A suposição de que uma imagem certificada FIPS se comporta igual independentemente do kernel de base é razoável, mas antes da correção não era confiável.
O problema só aparece na interação entre camadas: o contêiner parecia correto, o host cumpria FIPS e a falha surgia exatamente no ponto em que a suposição do pacote encontrava um kernel sem suporte à flag.
Escalação e o patch
O suporte da Canonical escalou o caso para o time de FIPS, e o engenheiro Matthew conduziu a investigação técnica. O desafio era atender duas condições ao mesmo tempo: fazer libgcrypt20-fips, gnutls28 e ubuntu-fips funcionarem em kernels padrão sem GRND_RESEED_ONLY, e preservar a conformidade FIPS sem disparar uma recertificação completa.
Certificação FIPS não se altera de leve. Mudanças em pacotes criptográficos podem invalidar a certificação e exigir meses de revalidação pelo processo CMVP do NIST (National Institute of Standards and Technology). Uma correção que quebrasse a certificação apenas trocaria um bloqueio por outro para quem tem obrigações de compliance ativas.
O patch de Matthew modificou o comportamento dos pacotes quando GRND_RESEED_ONLY não está disponível, permitindo o fallback correto sem comprometer as garantias criptográficas que sustentam o FIPS. Vale registrar que essa era a restrição real: não bastava fazer o contêiner subir.
Teste e liberação dos pacotes
A Canonical entregou os pacotes corrigidos ao cliente por um PPA privado para validação, e os contêineres foram testados nos ambientes de destino. Depois da confirmação de que a correção funcionava, os pacotes foram publicados nos repositórios jammy-fips-updates e noble-fips-updates.
Quem roda imagens FIPS de contêiner do Ubuntu Pro 22.04 ou 24.04 sobre kernels padrão de nuvem precisa garantir que o sistema puxa pacotes de jammy-fips-updates ou noble-fips-updates, respectivamente. A verificação é a mesma de qualquer repositório apt: checar a origem do pacote instalado e não apenas a versão.
Conclusão
O caso mostra que conformidade FIPS em ambientes cloud native depende da interação entre pacotes certificados e o kernel de base, não apenas do uso de imagens certificadas. A correção preservou a certificação e foi publicada nos repositórios fips-updates do Jammy e do Noble. Para quem opera sob FedRAMP ou FISMA, vale conferir de qual repositório os pacotes criptográficos realmente vêm.
Fonte: https://ubuntu.com/blog/fixing-fips-kernel-flag