Discussão iniciada ontem acerca da ausência de assinaturas no kernel do Ubuntu, hoje trago a vocês a conclusão dessa complexa história. E essa conclusão é igualmente complexa!
| 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.
Introdução
Conforme noticiado ontem, eu trouxe á tona o fato de que a Canonical não estava mais assinando os kerneis do repositório do Ubuntu. – Caso não tenha lido, clique aqui!
Lamento que eu tenha tido um tom alarmista, mas sempre avisando de que tudo são hipóteses, uma vez que a Canonical ainda não se pronunciou a respeito do assunto!
Hoje, trago uma conclusão para isso, o que está acontecendo, o que os usuários devem saber e como isso vai impacta-los a longo prazo. E mais uma vez, sem respaldo da Canonical. Porém, a resposta está nos próprios sistemas Ubuntu, mais precisamente no momento da instalação deles: O Ubiquity. Mas para abordá-lo, teremos que ir um pouco mais fundo, aonde o “problema” surgiu: o UEFI.
UEFI Secure Boot
Já abordamos em nosso site as vantagens do UEFI para iniciar um computador, em detrimento do BIOS.
Clique aqui caso tenha perdido a postagem!
Mas e o Secure Boot?
O Secure Boot é um adicional ao UEFI que traz consigo chaves de assinatura que permitem que o sistema seja reconhecido como válido e inicie. Inicialmente, á época do lançamento do Windows 8, a Microsoft foi tida como vilã pois nos computadores com hardware casado com software, com Windows instalado nativo, o Secure Boot impedia que sistemas Linux iniciassem.
O caso foi tão sério que a Linux Foundation precisou recorrer a adquirir uma chave padrão de destrave para implementar um recurso paliativo, o Shim Bootloader, que carrega durante o processo de boot em sistemas UEFI, reconhece a chave da Microsoft, depois reconhece a chave (genérica) do seu sistema Linux e aí sim inicia. Tudo isso contido no kernel de maneira sublime. Logo mais detalharei isso, no tópito do Ubiquity.
O imbróglio deu dor de cabeça em meados dos anos 2011-2012 mas hoje isso foi resolvido.
Chaves
Isso, isso, isso!
As chaves são mais complexas do que se imagina, envolvidas no processo que chamamos de Chain of Trust.
Essa “cadeia de confiança” mantem uma série entrelaçada de chaves que começa no hardware e termina no bootloader. Sem ater a detalhes, pois não será o foco dessa postagem, as chaves geram confiança para o sistema iniciar e, após isso, carregar módulos verificados no kernel. O objetivo é trazer segurança pois somente módulos verificados e assinados deveriam rodar no kernel Linux, evitando que malwares embutidos nos módulos se instalem no kernel – como é o caso dos rootkits.
Se quiser saber mais detalhes sobre como é a Chain of Trust, recomendo a leitura deste artigo.
Ubiquity
Durante o processo de instalação do Ubuntu 18.04 LTS, qualquer sabor, lhe é perguntado sobre o desejo de instalar módulos de terceiros como unRar, .mp3, e outros. Se você instalar o Ubuntu como EFI, particionamento GPT, você terá a mesma opção. Porém o sistema lhe convidará “forçadamente” a desativar o SecureBoot!
Se seu sistema está iniciado como EFI, ele vai desativar o Secure Boot e as chaves dos módulos como consequência.
Se seu sistema está iniciado como EFI, ele vai desativar o Secure Boot e as chaves dos módulos como consequência.Com o Shim bootloader, após a instalação, você vai colocar a senha criada na instalação e desativar o SecureBoot definitivamente. O UEFI continuará ali, apenas sem o recurso de segurança.
Como diz Anthony Wong, quando você instala um pacote DKMS, você mesmo está compilando o pacote de forma automática, no entanto, a Canonical não pode assinar o módulo para você nem garantir a procedência do mesmo.
Portanto, você pode definitivamente usar o Secure Boot, porém este é exatamente o caso de uso em que o Secure Boot está tentando protegê-lo de si mesmo: ele não sabe se você confia em um módulo ou não. Então o Secure Boot é desativado.
Oras, se o SecureBoot é desativado e suas chaves também, não interessa se o kernel é assinado:
A assinatura fica inútil, toda a cadeia de confiança será quebrada e seu PC estará “vulnerável”.
Implicações
O kernel recusará quaisquer módulos ou módulos não assinados com uma chave que não possa ser verificada por meio da cadeia de confiança. E isso ocorre somente se você instala o sistema sem módulos de terceiros mas sim com módulos open source!
- Ah eu uso só módulos assinados, não deveria me preocupar.
O problema é que os drivers da NVIDIA, os oficiais da Intel, drivers de Wifi como o famoso dkms-r8168 e o VirtualBox só executam sem chave! A Canonical não respalda nenhum deles. A menos que você não vai usar absolutamente nenhum desses módulos, o secure boot não vai funcionar para que eles funcionem.
Nesse cenário, o firmware UEFI carregará o carregador de inicialização shim confiável, assinado pela Microsoft para a Canonical – e este tem custos! O shim loader foi configurado para permitir a execução de código não assinado, permitindo módulos de terceiros, mas também quebrando a cadeia de confiança supracitada.
Consequências
O Ubuntu possui um dos mais abrangentes acervos de compatibilidade do mercado justamente por ser assim: Permitir módulos de terceiros e dar desempenho a aplicações. Ninguem que joga no Ubuntu vai querer usar o driver aberto Nouveau, se você pode muito bem usar o driver oficial da NVIDIA e tirar melhor proveito de seu caro hardware. Assim como quem usa Intel não vai querer os drivers Oibaf, se os oficiais são muito melhores.
O problema é que a instalação livre, leve e solta de módulos não assinados – e não verificados – também abre portas para alguns malwares. Motivo pelo qual alguns sistemas mais engessados, conservadores, impedem o uso arbitrário de módulos de terceiros.
Kernel Não Assinado
Chegamos ao cerne da questão. E o tal kernel-unsigned que a Canonical liberou desde a versão 18.04?
Este kernel está apenas sem as chaves do SecureBoot. A Canonical apenas mantem as chaves do kernel atualmente mantido dentro do pacote kernel-image-generic que vem por padrão nas distribuições Ubuntu.
Entenda:
- A Canonical PAGA pela manutenção das chaves da Microsoft no Ubuntu. Há custos. Vivemos no capitalismo e não dá pra escapar disso.
- A Canonical não vai assinar kerneis do repositório pois não há necessidade.
Implica que, se você troca o kernel, sabe o que está fazendo e provavelmente usa módulos de terceiros também. - Você usuário comum baixa e instala o Ubuntu.
- Este Ubuntu, não importa o sabor, virá com o kernel 4.15 – até a data desta postagem.
- O kernel 4.15 possui todas as assinaturas necessárias: Da Canonical Corp. e da Microsoft.
- Uma vez instalado e devidamente configurado, você já terá removido o SecureBoot usando as chaves nativas e portanto as assinaturas serão inúteis!
- Com seu sistema pronto e configurado, você poderá tranquilamente instalar outro kernel do repositório, unsigned, e continuar usando seu sistema normalmente.
- Conforme relatado recentemente – aqui – logo mais teremos detalhes sobre o uso do Ubuntu e com certeza veremos que, parte do sucesso do Ubuntu, se deve a sua ampla permissividade quanto á instalação de drivers e módulos de terceiros.
Algumas Questões:
- Você poderá ter sérios problemas se precisa das chaves do SecureBoot – implicando que você não usa módulos de terceiros, nem MP3, nem Flash Player, Java, Virtualbox, NVIDIA nada disso! – e quiser trocar de kernel.
A Canonical deu a entender em sua MailList Oficial (aqui) que a chave fica registrada e é herdada entre kerneis, portanto a chave do 4.15 servirá para os demais ao serem instalados.
Isso também implica que, dependendo do seu GRUB, se ele corromper, você perderá as chaves e terá que usar o kernel 4.15 para recuperá-las.
- Você estará sem uma camada de segurança. Portanto mais cuidado ao usar seu sistema e com os pacotes .deb que você instala! Afinal, se nem no Windows a segurança plena nos permite desleixar de instalar qualquer .exe que aparece por aí, você também deve estar atento ás fontes do seu .deb.
- O Ubuntu assim permite que .deb não-assinados possam ser instalados. Se o .deb trouxer consigo um módulo com malware, ele vai direto pro kernel. Cuidado!
Assine você mesmo!
A Canonical curiosamente não recomenda – neste link – que você use as assinaturas nativas que eles fornecem!
De acordo com eles, apesar das assinaturas estarem presentes e serem oficiais da Canonical e da Microsoft, a melhor medida de segurança é evitá-las, criando as suas. Assim um malware com assinatura “oficial” não se instala na sua máquina caso você descuide, somente você tem as chaves.
Caso você queira tentar assinar seu próprio kernel, você deve seguir o tutorial informado neste link.
Esse tutorial serve também para o Ubuntu 18.04 LTS.
Conclusão
Os usuários do Ubuntu podem ficar tranquilos?
Depende.
- Se você é conservador e não usa módulos proprietários – lembrando, NVIDIA, Intel, Flash, Java, VirtualBox e etc – não precisa se preocupar, você possui todas as chaves dos módulos e não poderá instalar nada não-assinado em seu sistema.
Se você baixar um .deb infectado, se o módulo infectado não tiver chave, ele não vai instalar. E você deve ter malícia de perceber que aquele pacote está infectado, se você achar que é frescura do sistema e instalar forçadamente, de nada adiantou ter segurança se você quebrou ela! - Se você for como 90% da população Ubunteira que possui o Secure Boot desativado – assim como este que vos fala! – você deve seguir aquelas recomendações que todo mundo deveria seguir:
- Não instale módulos sem saber a procedência dos mesmos.
- Não instale pacotes .deb sem saber a procedência dos mesmos.
- Atento ao seu sistema se não há nada anormal com ele. Um rootkit pode roubar dados ou fazer alterações substanciais, atenção é vital!
Este, meus amigos, é o preço da liberdade.
Você terá todos os drivers e máxima compatibilidade em seu sistema mas em troca, estará mais sujeito a ser infectado por pacotes e módulos de fontes maliciosas. Portanto, cuidado amigos Ubunteiros! E isso vale pra qualquer sabor!
#UrbanCompassPony
Agradeço cordialmente ao Gabriel Longo que me ajudou a elucidar a questão.
Fontes:
Wiki.Ubuntu: UEFI Secure Boot
Ask.Ubuntu: Disable Secure Boot for 3rd Party Modules
ComputerLinguist: DKMS
PCWorld: Linux Fountation Adquire Chave Microsoft
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.