Microsoft mostra em vídeo como UEFI, secure boot e TPM protegem o computador

Eu não tenho nada contra você simplificar sua vida saindo do default para coreboot. Entretanto UEFI continua apenas sendo uma especificação/tecnologia, secure boot não é nem mandatório na especificação, faz mais sentido você ficar com ódio da fabricante que implementa a especificação junto de parceiras donas de OSes que decidem não aceitar implementações divergentes. Fosse coreboot a indústria desceria a mesma ladeira torcendo o padrão como lhes agrada, símbolo disso é que coreboot nunca vai se livrar de blobs proprietários em sistemas populares.

Não, definitivamente as pessoas não podendo saber se há um MITM em uma conexão HTTP não faria a internet um lugar melhor, e um dos pontos fundamentais para evitar esse tipo de ataque é ter um terceiro confiável envolvido para facilitar a sustentação do sigilo da chave privada no servidor.

Sandboxing como o implementado por sistemas snap ainda é a única forma capaz de oferecer uma solução para leigos que conteineriza componentes enraizados no sistema a nível de módulo de kernel, também é a única solução que funciona em sistemas de arquivos simples como fat ou exfat já que selinux demanda labels, também é a única solução que não está em uma condição cabeluda envolvendo user namespaces como é o caso do bubblewrap. Alias fica a questão, neste caso tudo bem advogar pela “complexidade desnecessária” do selinux ou colocar uma terceira solução na mesa? Enfim cada tecnologia teve seus acertos e erros, ambas são úteis e não faz, novamente, sentido odiar uma

Eu continuo podendo bootar depois de substituir facilmente e eliminar quaisquer resquícios do journald ou logind do meu sistema… Será que eu posso eliminar o sh ou bash completamente sem deixar vestígios e ainda bootar? Será que é tão simples quanto trocar uma tecnologia por outra? Parece que não…

Quando eu me refiro ao empilhamento de shells não estou me referindo ao empilhamento de ambientes mas sim de sabores de shell, distros não decidiram intencionalmente acoplar fortemente diversos subsistemas em suas distros ao redor do sh e bash e fazer de conta que esse tipo de monólito vale.

São as mesmíssimas coisas… Ninguém se rasga ao meio por causa da Kronos, agora UEFI… Apesar de ambos terem implementações totalmente open-source. A verdade é que não existe tecnologia nesse mundo que não possa ser implementada de forma a prejudicar uma parte e dar vantagem a outra.

Coreboot é uma tentativa nobre de melhorar essa questão e concordo que tem pontos bons quando a fabricante não caga, mas no tangente a lama que vemos nas implementações não trazem benefício nenhum para a mesa.

Muita tempestade no copo d’água.

1 curtida

Que soluciona só problemas que ele mesmo cria…

Você acha que isso vai ser vedade até quando?

Existem outras formas de criptografia entre dois pontos que não precisam de todo o overhead e ineficiência do SSL. A única razão pela qual essas formas não são implementadas é, pasme, dinheiro.

A outra forma, um processo de desenvolvimento que faz sentido, com uso de pacotes distribuidos e compartilhados, sem todos os problemas que foram trazidos pela introdução forçada de uma ferramenta mal-desenvolvida (Vamos fazer o linux lidar com programas da mesma forma que Windows, everyone!) ainda é a forma mais sã de gerenciar software.
Snap é uma ferramenta boa para compatibilidade (Sandboxing com versões ~muito~ mais antigas de certos pacotes, por razão A ou B).

Mas eu não estava falando do SELinux. Um sistema sem SELinux ainda é capaz de bootar e ser funcional (Assumindo que você é capaz de configurar suas permissões corretamente, ou se você usar o AppArmor, que é mais fácil, mas traz toda outra série de probleminhas.) Enquanto sistemas proprietários estão fazendo cada vez mais o uso de tecnologias restritivas…

E você quer que seu teminal use o quê? /COMMAND.COM?
… Tá. Mas falando sério agora: O sistema usa shells para funcionar, você quer fazer o sistema funcionar sem shells como?

sh, bash, csh, zsh, e todas os outros “sabores” de shell são simplesmente formas de interagir com o sistema. Não são só programas mas também linguagens de programação, o C é um “monolito”? Se tem uma coisa que segue a filosofia Unix é o sh.

Colocar TUDO em GPLv3 é um bom começo pra lidar com tivoização. Eu admito que não é uma solução de verdade, e como pouca que se define, é um tanto barbárico.
Mas hey, se as empresas querem usar de pratícas anti-consumidor, a gente pode usar de práticas anti-empresas, né?

Antes do UEFI métodos de segurança contra ataques físicos eram muito mais limitados que hoje, eu gostaria que essa tecnologia não tivesse entrado nessa bola de neve entre fabricantes, vendedores de OS e gente irracional puritana que quer mais um terceiro, quarto, milésimo padrão, para que pudéssemos desfrutar em paz de um sistema mais resistente a adulterações físicas e de software in-loco, dentre outras coisas.

Medo irracional… Vai ficar assim enquanto existir alguém querendo tocar projetos abertos como Tianocore, a especificação mudar não vai mudar isso… Você acha o que? Se gigantes da indústria se unirem em torno do Coreboot para torcer a especificação, o resultado vai ser o mesmo, algumas boards compatíveis com a implementação open, outras não e implementações entupidas de blobs e travas proprietárias.

Ah é? Aponta uma para servidores públicos que não seja SSL/TLS… A esmagadora maioria das outras é para conexões privadas e autenticadas como é o caso de protocolos como SSH e afins que não garantem que um intermediário não possa interceptar a troca inicial de chaves e tornam praticamente impossível uma conexão anônima.

SSL tem o trunfo de não transferir dados sigilosos desprotegidos em nenhum momento entre os envolvidos através da mesma conexão, nem exigir chaves únicas e fixas que possam identificar clientes recorrentemente.

Ué, mas não existem distros sem systemd também completamente bootáveis? Mais contradição à vista. Acho que você já entendeu que eu não tenho crítica nenhuma apenas a essas contradições né?

O que eu quero é que as pessoas sejam mais racionais. Na mesma filosofia UNIX eu poderia remover o systemd ou subcomponentes e trocar por outros que fazem o mesmo papel em uma distro. Eu posso remover e colocar outro shell lugar do sh e bash nas distros hoje? Por exemplo Fish, Xonsh, zsh, etc? Não… No máximo empilhar uma dessas como meu shell de login enquanto eu ainda tenho que conviver com Bash por baixo.

Você quer comparar uma linguagem compilada cujo o resultado que você obtém é linguagem de máquina universal, com uma linguagens interpretadas que precisam carregar um interpretador consigo onde quer que vá? A mesma crítica pode ser ditar de python, Java, Javascript, etc, em nível até pior, muitas distros também se emaranham com estes componentes a ponto de serem irremovíveis, e essa é a mesmíssima reclamação hipócrita que as pessoas fazem ao Systemd mas não a essas ferramentas, que fica mais irracional ainda quando você percebe que pode remover completamente praticamente todos os componentes e substituir por outros.

É um bom final, você quer dizer? Se tem algo que mata o software livre tanto quanto empresas é o radicalismo da “liberdade imposta”, duvido que Coreboot teria saído de uma lista de meia dúzia de belos protótipos sendo puramente GPL3.

Acho que ajuda mais nós mudarmos o mindset, quem está perdendo são essas empresas e as pessoas que demonizam tecnologias. Tem muitas coisas incríveis se dermos uma chance para o que está na visão periférica. Se olharmos para o lado e não formos tão extremistas, surgem apertos de mão como a Valve e Linux, etc.

Eu não quero mais um terceiro, quarto padrão. Pra mim tava bom um só: BIOS. Com sistemas de defesa dentro do S.O. para impedir que ataques acontecessem. O vetor de ataque de um sistema aumenta exponencialmente com sua complexidade - Daí meu problema com UEFI.

Perdão, eu achei que você estava falando de protocolos de segurança implementáveis, não implementados. zk-STARK, por exemplo, é um protocolo zero-knowledge capaz de comunicação criptografada por dois pontos que é 100% transparente.
-Claro, ainda estamos nos primórdios dessas tecnologias, mas claramente SSL não vai ser uma base na nossa internet por muito mais tempo.

Mas eu não falei nada de errado com o systemD. Tanto é que, como você disse, existem várias distros que não o usam.

É claro que pode. Converta as calls corretamente (Faça POSIX, e o POSIX se fará), e todos os scripts feitos por outras pessoas por scripts feitos por você mesmo no shell que você quiser, que ele roda.
Vai ser fácil? Não.
É possível? Com certeza.

Você não precisa usar bash se quiser, só fazer as conversões necessárias (que são muitas, então você -ou eu- não vai fazer). Foi esse o meu argumento. Sh faz algo e faz bem, isso segue a filosofia Unix.

SystemD não é um monolito. Eu posso instalar certos pedaços do conjunto de ferramentas do systemd, mas não preciso de todas essas partes.
Você precisa de um shell rodando em userspace para fazer o seu sistema funcionar. Ele não precisa ser sh, bash, ou o que seja. Mas, se você quiser um sistema que não possui sh então você vai precisar escrever um monte de ferramenta que foi escrita em sh, no seu shell de preferência.

Se tem algo que mata o software livre é a tivoização de software livre, que é tomado pela sua capacidade e retorcido à tirania. GPLv3 foi uma forma de defender o desenvolvedor FOSS, que vê suas contribuições à sociedade absolutamente destroçadas e usadas em produtos proprietários de forma anti-competitiva.
Não existe “liberdade imposta”. Isso é uma contradição lexical enorme. Existe você ser livre para fazer o que quiser com seu software e hardware, e existe você não poder fazer o que quiser com seu software e hardware. A FSF e a LF querem o primeiro, a Microsoft e outras empresas querem o segundo.
Como eu disse, implementar GPLv3 em tudo seria barbárico, infazível. “Não é uma solução de verdade”, como eu disse. Stallman é completamente maluco, nenhuma novidade no campo de batalha. Mas a GPLv3 é simplesmente uma forma de defender código de empresas com histórico de péssimas práticas corporativas.

Eu não estou demonizando a tecnologia, eu só não acredito que esta seja necessária.

A Valve tem uma razão de mercado para querer apoiar o Linux, e isso não é uma crítica, mas dizer que é puramente da boa vontade do titio Gabe, seria meio ingênuo. (Não que tenha sido isso que você quis dizer, isso aqui é só um adendo ao meu ponto anterior sobre empresas com péssimo histórico de competitividade).

Acontece que esse sistema de defesa dentro do SO não protege o dispositivo de pessoas que queiram adulterá-lo para comprometer a segurança estando em posse do mesmo.

Todas as tecnologias de segurança adicionam alguma superfície de ataque, o importante é quanta superfície de ataque elas retiram, o padrão EFI reduz muito mais a superfície de ataque em comparação ao que adiciona, mesmo em comparação a full root encription, onde o GRUB vira um elefante de tantos drives embutidos.

Eu concordo que o UEFI poderia ser um pouco mais slim mas no tangente ao Coreboot, tirando quem se arrisca a flashear imagens custom e ter um tijolo digital, o bloatware continua o mesmo, os bugs idem e as incompatibilidades de OS também, basta dar uma olhadinha na realidade dos Chromebooks.

Se ainda continuássemos com BIOS, continuaríamos sem padrão nenhum, seria o caos do mundo ARM, pelo menos com UEFI ou Coreboot, diversas entidades se forçam a conversar e entrar em um mínimo acordo antes de sair lançando suas soluções sem ninguém perguntar. Dizer que BIOS estava bom é não entender o papel de especificações e padrões e não entender que a indústria não iría magicamente decidir toda em conjunto implementar suporte para apenas GPT, coreboot, etc.

E você acabou de me apontar uma tecnologia que tem um uso completamente diferente do SSL/TLS e seria inviável como substituto para SSL/TLS. Zero-Knowledge Proof apenas tem um objetivo, eu poder provar para você que eu sei que você é você, sem mostrar o segredo que prova que eu sei que você é você e só… Eu ainda preciso saber que você é você (o cliente ainda precisa saber que aquele servidor é o servidor fidedigno), e neste quesito você ainda precisa de uma autoridade certificadora que diga ao cliente o segredo que prova que o servidor é ele mesmo.

Existem usos de Zero-Knowledge Proof implementados, porém o uso é apenas para evitar transmitir o segredo diretamente. É possível implementar o protocolo SSL com Zero-knowledge proof para evitar que o servidor envie informações sobre o segredo para o cliente comprovar sua identidade, porém você ainda precisa de uma autoridade certificadora fonte do segredo que o cliente tem para validar o certificado.

E pelo mesmo princípio não deveria haver nada de errado no UEFI, boa parte dos problemas que as pessoas dizem existir no UEFI não são inevitáveis, assim como o UEFI, systemd é uma especificação bem ampla que pode ir de bootar o sistema, detectar dispositivos, montar drives, agendar tarefas, controlar sessões do sistema, etc, a apenas gerenciar o boot nenhum fabricante precisaria colocar o suporte a todos os protocolos e padrões sobre os quais a especificação discorre pois como o UEFI, systemd é modular. UEFI/systemd não tem culpa de a maioria das fabricantes/distros terem aderido a todas as funcionalidades por padrão. E não, o comitê responsável pelo UEFI não controla, vende ou certifica como cada um implementa a especificação

Ué porque reclamar da especificação do UEFI então? Tianocore está aí como um livro aberto assim como a especificação e ninguém para te proibir de mudar. A especificação é modular e você pode retirar praticamente tudo que não lhe sirva, você pode remover praticamente todos os protocolos e terminar com uma implementação bem básica, é só, como no caso do Coreboot, ter a documentação da sua motherboard ou os blobs proprietários.

Enfim, você sabe muito bem o que eu quis dizer. UEFI é tão monólito quando grandes padrões por ai, como POSIX, linguagem bash, etc e as pessoas são tão obrigadas quanto obrigar uma acomodação as especificações.

E você ou eu pode fazer os ajustes necessários num fork do Tianocore e terminar com uma imagem slim para nossas motherboards.

Essa linha de argumentação vale para absolutamente qualquer coisa inclusive o UEFI, esse é o ponto, a não ser que sua distro amarre as coisas tão bem que seja impossível um humano ter tempo para ter essa liberdade, a não ser que um fabricante de motherboard amarre tão bem tudo que há na especificação do UEFI ao seu funcionamento que seja impossível para um humano ter essa liberdade.

Isso foi a intenção, mas o remédio fez mais mal que ajudou o paciente aqui, GPLv3 é uma tentativa de resolver um problema de forma errada, foi apenas uma proposta do tipo “hey como podemos começar uma guerra?”. Tando que a maioria da comunidade livre rejeitou a licença. GPLv3 é um exercício de fraqueza anti-competitiva também, em vez da demonstração sólida superioridade do modelo aberto, como tem sido o caso, fazer as pessoas quererem usar código aberto e produzir código aberto porque isso lhes dá vantagem contra o competidor. De resto não existe liberdade imposta literal, porém a obrigação unânime da GPLv3 de tornar tudo aberto é uma falsa liberdade.

1 curtida

Só para complementar sobre o GPL3, ele foi feito de maneira incompatível com GPL2, por isso kernel Linux está na GPL2 até hoje. Por causa incompatibilidade entre licenças.

1 curtida

De fato, ao ponto de muitos nomes importantes na comunidade verem na GPLv3 uma licença anti-colaborativa ao promover a balcanização do universo open source.