Parte da preocupação de que você deseja que o kernel administre a inicialização segura em um nível baixo é porque as chaves da Microsoft podem ser usadas para hackear o sistema e, se isso acontecer, eles temem que a Microsoft desative a chave e, portanto, os PCs com Linux. corra com essa chave (e ninguém quer isso).
Tudo começou com uma solicitação de pull de David Howells que permitiu que chaves binárias assinadas pela Microsoft fossem carregadas dinamicamente no kernel em execução no modo de inicialização seguro. Quem estava com o cobertor achou que era besteira e que seria melhor melhorar o analisador X.509. Matthew Garrett responde que existe apenas uma autoridade de assinatura e que eles assinam apenas binários PE (executáveis portáteis). E aqui Linus solta sua língua afiada e diz:
Caras, isso não é um concurso de chupar pau. Se você deseja analisar binários PE, vá em frente. Se a Red Hat quiser perguntar a você garganta profunda para a Microsoft, é * seu * problema. Não tem nada a ver com o kernel que mantenho. É trivial para você ter uma máquina de assinatura que irá analisar o binário PE, verificar as assinaturas e assinar as chaves resultantes com sua própria chave. Já escreveram o código, por Deus, está nessa ordem maldita. Por que eu deveria me importar? Por que o kernel deveria se importar como "nós apenas assinamos binários PE"? Oferecemos suporte para X.509, que é o padrão para assinatura. Faça isso do lado do usuário em uma máquina confiável. Não há desculpa para fazer isso no kernel.
Matthew responde:
Os vendedores desejam trazer chaves assinadas por terceiros de confiança. Agora, o único que está à altura é a Microsoft, porque aparentemente a única coisa que os fornecedores amam mais do que firmware de baixa qualidade é seguir as especificações da Microsoft. O equivalente não é apenas Red Hat (ou qualquer outra coisa) assinar novamente essas chaves programaticamente, é assinar novamente essas chaves com uma chave confiável pelo kernel upstream. Você estaria disposto a carregar uma chave confiável por padrão se um membro da sociedade confiável hospedasse um serviço de nova assinatura? Ou presumimos que quem quer lançar módulos externos é um idiota e merece ser um miserável?
Linus responde que duvida que alguém se importe. Que já é estúpido assinar módulos do kernel com uma chave da Microsoft. Além disso, a Red Hat ASSINARÁ os módulos binários NVIDIA e AMD. Peter Jones diz que não, que a Red Hat não assinará nenhum módulo construído por outro. Garret acrescenta que o RHEL acabará contando com as chaves da NVIDIA e da AMD e que é muito provável que sejam baseadas no serviço de assinatura da Microsoft.
E é aqui que faço uma pausa e faço um resumo parcial e brutal para quem não quer entrar em detalhes técnicos:
Todo o desenvolvimento em torno da inicialização segura enlouqueceu, mas porque os fornecedores de hardware (pelo menos os maiores) ainda querem aprofundar a Microsoft.
Então Linus decidiu fazer as seguintes sugestões, para que parassem de foder ……:
Corte com medo.
Isso é o que eu sugeriria e é baseado em VERDADEIRA SEGURANÇA e em COLOQUE O USUÁRIO PRIMEIRO em vez de sua abordagem "vamos satisfazer a Microsoft fazendo merda".
Então, em vez de agradar à Microsoft, vamos tentar ver como podemos realmente adicionar segurança:
- uma distro deve assinar seus próprios módulos E NADA MAIS por padrão. E também não deve permitir que nenhum outro módulo seja carregado por padrão, porque por que deveria? E o que diabos uma empresa de microsoft tem a ver com qualquer outra coisa?
- antes de carregar qualquer outro módulo de terceiros, certifique-se peça permissão ao usuário. No console. Sem usar chaves. Nada disso. As chaves ficarão comprometidas. Tente limitar o dano, mas, mais importante, deixe o usuário ter o controle.
- Anime coisas como chaves aleatórias por host - com verificações de UEFI estúpidas desativadas, se necessário. Eles quase definitivamente serão mais seguros, dependendo de alguma raiz maluca de confiança baseada em uma grande empresa, com autoridades de assinatura que confiam em qualquer pessoa que tenha um cartão de crédito. Tente ensinar essas coisas às pessoas. Incentive as pessoas a criar suas próprias chaves (aleatórias) e adicioná-las às configurações de UEFI (ou não: tudo sobre UEFI é mais sobre controle do que segurança) e se esforce para fazer coisas como uma assinatura única com a chave privada descartada. Em outras palavras, experimente animar esse tipo de segurança como "certifique-se de perguntar ao usuário explicitamente com grandes avisos e criar sua própria chave para esse módulo específico." Segurança real, não segurança "nós controlamos o usuário".
Claro, os usuários também vão estragar tudo. Eles vão querer carregar módulos binários NVIDIA e toda essa porcaria. Mas deixe estar SU decisão, e sob SU controle, em vez de dizer ao mundo como isso deve ser abençoado pela Microsoft.
Porque isso não deve ser sobre as bênçãos da MS, mas sobre o usuário abençoando os módulos do kernel.
Honestamente, você é o que as pessoas loucas anti-chave temem. Você vende o shitware "controle, não segurança". Todo o "MS possui sua máquina" é apenas a maneira errada de usar senhas.
A partir daí o fio se acalmou ... e não vale a pena seguir.
Amigos de DesdeLinux. Hoje estou comemorando meu primeiro aniversário como escritor em um blog linux, apesar de não ter estreado como tal aqui, mas no blog de frannoe, que então se chamava Ubuntu Cosillas e que hoje é LMDE Cosillas. E foi lá no dia 2 de março, quando escrevi o primeiro capítulo desta saga de firmware, que continuei aqui. Gostaria de agradecer a todos que me lêem e me lêem, especialmente Frannoe e toda a equipe do Desdelinux por terem criado um lugar para mim. Se não fosse por ter feito aquele curso de Programação Funcional Avançada, e um colega que sugeriu que eu usasse um linux para trabalhar com ghc, eu certamente ainda importaria 3 pepinos todo linux.
Vou terminar com esta frase: "Se você não gritar sua ignorância, ninguém sairá para corrigi-lo e, portanto, você estará certo estando errado"
Postagens relevantes da lista de e-mails do kernel:
https://lkml.org/lkml/2013/2/21/196
https://lkml.org/lkml/2013/2/21/228
https://lkml.org/lkml/2013/2/21/275
https://lkml.org/lkml/2013/2/25/487