Os kerneis Linux do repositório oficial, pré-compilados pela Canonical, estão vindo sem assinatura.
Veja como o usuário final pode ser impactado com tal decisão!
| Se você apoia nosso site, desative o AdBlock quando visitá-lo, inclusive em Mobile!
Os anúncios são poucos e não invasivos. Se quiser contribuir com nosso trabalho, clique em qualquer banner de sua preferência, exceto dos Parceiros. Mais detalhes clicando aqui.
ATUALIZAÇÃO (27/06/2018):
A Canonical já se pronunciou a respeito!
Leia na íntegra clicando aqui sobre o veredito do kernel não-assinado.
A seguir, a postagem original.
Nota: As informações a seguir possuem cunho estritamente hipotético, uma vez que nada foi oficializado por parte da Canonical. Portanto peço discrição ao ler as informações e argumentos abordados. Logo que tivermos mais informações, estarei publicando uma nova postagem com detalhes a respeito. Grato.
Poucos devem ter percebido a mudança sutil, mas desde o lançamento da versão 4.14.36 do kernel Linux pré-compilado pela Canonical, em 24/04/2018, o kernel está vindo não-assinado (unsigned) e com um pacote extra de módulos. Agora, quem baixa os pacotes .deb do kernel pelo repositório oficial (aqui!) deve baixar 4 arquivos:
linux-headers-4.x.y-*all.deb linux-headers-generic-4.x.y-*amd64.deb linux-image-unsigned-4.x.y-*-generic*amd64.deb linux-modules-4.x.y-*-generic*amd64.deb
Público
Toda a linha amd64 dos kerneis 4.14.36 ou superior, 4.16.4 ou superior e 4.17.0 ou superior estão vindo com o pacote linux-image-unsigned-4.x.y-*-generic*amd64.deb e isso significa que o kernel está não-assinado!
Observei um princípio de discussão em fóruns como o Reddit e infelizmente poucos usuários estão percebendo a mudança e mais: A Canonical não se pronunciou a respeito em nenhum de seus canais oficiais.
Nós da UNIX Universe tentamos entrar em contato com a equipe do Ubuntu Kernel Team (UKT) via IRC e e-mail. Até o fechamento dessa postagem eles ainda não haviam respondido nossos questionamentos.
Caso queira tentar a sorte, os seguintes contatos dos membros do UKT, de acordo com a wiki.ubuntu, estão entre colchetes:
- BradFigg [bjf] (Director)
- AndyWhitcroft [apw] (Kernel Engineer – Architect) blog: http://awhitcroft.blogspot.com/
- ColinKing [cking] (Kernel Engineer) blog: http://smackerelofopinion.blogspot.com/
- PaoloPisati [ppisati] (Kernel Engineer)
- SethForshee [sforshee] (Kernel Engineer)
- KamalMostafa [kamal] (Kernel Engineer)
- MarceloCerri [mhcerri] (Kernel Engineer)
- Khalid El Mously [kmously] (Kernel Engineer)
- Tyler Hicks [tyhicks] (Kernel Engineer)
- Alberto Milone [tseliot] (Kernel Engineer)
- StefanBader [smb, gnarl] (Kernel Engineer – Lead)
- KleberSouza [klebers] (Kernel Engineer)
- BenRomer [bromer] (Kernel Engineer)
- JosephSalisbury [jsalisbury] (Kernel Engineer)
- Thadeu Cascardo [cascardo] (Kernel Engineer)
- Juerg Haefliger [juergh] (Kernel Engineer)
Finalizando este tópico, no Ubuntu Lists, com os registros de mensagens do IRC dos membros, temos apenas 1 questionamento acerca do kernel Unsigned publicado em Maio/2018, aqui.
Nele, Seth respondeu o seguinte:
Você está perguntando sobre os pacotes não assinados?
Esse é o resultado de algumas mudanças de empacotamento que chegaram no 18.04 para que um único kernel assinado é instalado pelo pacote linux-image, em vez de um kernel não assinado por linux-image e um kernel assinado por linux-image-signed. Os servidores de pacotes não assinados da imagem linux possui dois fins: o primeiro é por ser uma compilação intermediária para finalmente produzir um pacote linux-image com o kernel assinado, e segundo, que isso nos dá algo para manusear ao construir kernels de teste.
Não muito esclarecedor, não é mesmo? Principalmente pelo fato de que muitos usuários usam o PPA para trocar as versões do kernel do Ubuntu. Se o que Seth afirma for categórico, isso quer dizer que os kerneis diferentes do principal via repositório estarão sem assinatura.
E qual o problema disso?
Vejamos mais abaixo o motivo da preocupação.
Problema
Como afirma a documentação oficial do kernel Linux neste link, nos é informado o seguinte:
O recurso de assinatura de módulo do kernel criptograficamente assina os módulos durante a instalação e, em seguida, verifica a assinatura ao carregar o módulo. Isso permite maior segurança do kernel, impedindo o carregamento de módulos não assinados ou módulos assinados com uma chave inválida. A assinatura de módulo aumenta a segurança, dificultando o carregamento de um módulo malicioso no kernel. A verificação da assinatura do módulo é feita pelo kernel para que não seja necessário ter bits confiáveis no espaço do usuário.
Esse recurso usa certificados padrão X.509 ITU-T para codificar as chaves públicas envolvidas. As assinaturas não são codificadas em nenhum tipo de padrão industrial. O recurso atualmente suporta apenas o padrão de criptografia de chave pública RSA (embora seja pluggable e permita que outros sejam usados). Os algoritmos de hash possíveis que podem ser usados são SHA-1, SHA-224, SHA-256, SHA-384 e SHA-512 (o algoritmo é selecionado pelos dados na assinatura).
Impacto
O problema em remover a assinatura dos módulos do kernel Linux, é que qualquer malware que entrar no sistema poderá não ser devidamente barrado pelas chaves de autorização e não ser percebido, por exemplo, no caso de rootkits! – Para saber mais sobre rootkits leia nossa matéria sobre malwares para Linux clicando aqui.
O que aumenta a suspeita da atitude da Canonical, é que seu pacote de módulos está vindo á parte desde a mudança. Antes, os módulos vinham embutidos no pacote image-signed, agora com o image-unsigned os módulos estão num pacote á parte. – por isso a necessidade de baixar 4 pacotes .deb em vez de 3 como antigamente.
Repercussão
Estive pesquisando a fundo o assunto, já que a Canonical não se pronunciou ainda a respeito.
Tirando a nota oficial do kernel.org – e preocupante se for o caso que estamos presenciando – também li informações e conversas de postagens do Reddit e do próprio Ubuntu Community.
Ignorando os absurdos – como que a Microsoft está cobrando $100 pelos módulos assinados e a Canonical está cortando gastos – e removendo os improváveis – como que, ao usar esse kernel não-assinado o sistema não vai mais iniciar em UEFI Seguro – por fim, fiquei com algumas opções:
- A Canonical está fazendo mudanças no código de seu kernel Linux pré-compilado e para isso precisou deixa-lo sem assinatura – mas compensou isso trazendo os módulos assinados em um pacote extra.
- A Canonical está com problemas ao compilar o kernel e não assiná-los libera o acesso e uso dos módulos habituais.
- A Canonical usa kerneis não-assinados para ter mais módulos disponíveis.
- A Canonical quer forçar os usuários a usarem apenas o kernel atualmente mantido no repositório (4.15) e não quer que usem o do PPA ou qualquer outro pelo Ubuntu Kernel Update Utility.
- O kernel da Canonical NUNCA foi assinado, apenas foi uma correção para que o kernel fique politicamente correto com a GPL e outras normas.
- O kernel NUNCA foi assinado, na verdade somente o kernel liberado no repositório via APT possui a mesma, ou seja, de toda a listagem do PPA, somente 1 versão possui assinatura.
Conclusão
Não importando o caso, os kerneis atuais estão vindo sem assinatura via PPA.
O mais curioso é que somente as imagens amd64 (x86_64) dele estão sem as assinaturas.
E precisamos saber das REAIS circunstâncias disso! Quais riscos os usuários estão sujeitos e se isso tudo é apenas um mero detalhe que em nada afeta na segurança dos kerneis pré-compilados da Canonical.
Aos usuários que estão utilizando um de seus kerneis unsigned e estão se sentindo inseguros – por terem trocado de kernel usando o Ubuntu Kernel Update Utility por exemplo – fica a opção de uso do 4.14.30 LTS relativamente recente que ainda está assinado. Aguardemos o desenrolar dessa história ou se a Canonical vai se pronunciar oficialmente a respeito. E se não o fizer, que ao menos explique sobre a mudança que, até segunda ordem, pode impactar na segurança dos sistemas Ubuntu e seus sabores.
Tópicos de Discussão Atuais:
#UrbanCompassPony
Autodidata, me aprofundei em sistemas operacionais baseados em UNIX®, principalmente Linux. Também procuro trazer assuntos correlacionados direta ou indiretamente, como automação, robótica e embarcados.