No Diolinux Responde de hoje, abordamos o polêmico problema com o XZ, a saída de usuários do Slackware e as decisões do KDE que afetam os usuários. Quer participar enviando suas perguntas? Torne-se membro do canal!
O mundo do Linux foi abalado pelo problema no XZ?
Recentemente, abordamos o problema no XZ no Linux, sendo um dos primeiros sites em português a comentar sobre o assunto. Também há um tópico em nosso fórum sobre o assunto, onde a comunidade compartilhou vídeos de outros criadores e fontes.
No entanto, é importante não se deixar levar pelo alarde de “Linux tem uma mega falha”, que causou pânico e ignorância sobre o que realmente aconteceu. Além disso, estamos comprometidos em responder todas as perguntas enviadas por nossos membros para este quadro. Ao se tornar membro do canal Diolinux, você terá acesso a vídeos e benefícios exclusivos, além de poder participar do Diolinux Responde!
Em resumo, no final de março, foi descoberto que a biblioteca XZ Utils, usada em várias distribuições Linux para compactação de arquivos, estava infectada com um malware que poderia acessar dados do SSH, permitindo o login remoto e acesso não autorizado ao sistema.
O XZ é mantido de forma comunitária e tem seu código aberto, e a descoberta do problema foi creditada a um funcionário da Microsoft. O backdoor parece ter sido inserido propositalmente por um suposto colaborador do projeto, criando a sensação de que foi algo premeditado, um plano de longo prazo.
Este problema foi encontrado em versões específicas do XZ, a 5.6 e 5.6.1, então, em tese, distros que usavam essas versões poderiam ser alvos de ataque. Como fica o mundo do open source com isso?
Como disse Linus Torvalds, “O importante não é criar um sistema sem falhas, isso é impossível, humanos as fazem, o importante é a velocidade na qual você corrige essas falhas.”
Essa não é a primeira vez que um CVE de classe 10 afetou sistemas Linux, nem será a última. A quantidade de atenção dada ao assunto pode ter exagerado a gravidade do problema.
As únicas distribuições que poderiam ser afetadas foram as versões em desenvolvimento do Fedora e do Debian. Também o Kali Linux, se atualizado entre os dias 26 e 29 de março, o openSUSE Rolling Release e o MicroOS, se atualizados entre 7 e 28 de março.
Em resumo, versões em desenvolvimento que poucas pessoas utilizam, e as vítimas ainda precisariam estar com o SSH ativo, expostos para a internet com um firewall que permitisse tráfego de IPs não autorizados, sem considerar outras possíveis camadas de segurança, tanto domésticas, mas principalmente empresariais.
Red Hat, Ubuntu, Debian estável, CentOS, Alma Linux, Rocky Linux, openSUSE Leap e derivados diretos são os principais sistemas usados em servidores, nenhum deles foi afetado, e mesmo que fossem, ainda precisariam de certas circunstâncias para a conexão poder ocorrer. Sem considerar os patches de segurança que alguns sistemas lançaram horas depois da descoberta.
O próprio Arch Linux, que por ser rolling release poderia ter sido afetado, não foi por uma tecnicalidade da construção do sistema. Mesmo assim, o Arch fez a correção do software e mandou atualizações, como era de se esperar.
Esse CVE é de classe 10 porque poderia criar a condição de um ataque com controle remoto completo, mesmo que a probabilidade de acontecer fosse baixa. Dias depois, se você olhar a pontuação, a probabilidade de alguém explorar tem nota 3.9 de 10. Os mais impressionados talvez não tenham se dado conta, mas falhas de segurança aparecem no mundo Linux e open source o tempo todo, na verdade, elas chegam em todo tipo de software!
Quando o software é open source, elas tendem a ser mais frequentes, já que é possível consultar diretamente o código-fonte, ficando mais fácil encontrar os problemas, que foi exatamente o que aconteceu no caso do XZ.
Se um backdoor desse tipo tivesse sido colocado em um software proprietário, de código fechado, são grandes as chances das coisas irem para produção sem ninguém perceber até ser tarde demais. Dessa vez foi por pouco, e quem diria, foi alguém da Microsoft que ajudou a tornar o Linux mais seguro dessa vez.
Talvez já existiram problemas que você até pudesse ser afetado de alguma forma, que nunca ficou sabendo e foram embora numa atualização de sistema feita de forma descompromissada. Isso não quer dizer que o Linux está menos seguro agora, essas coisas acontecem desde sempre, sempre foi assim. Para ter uma visão mais ampla da segurança no Linux, recomendamos o nosso podcast especial sobre o assunto.
Mas se tem uma coisa interessante desse caso do XZ em particular que pode ser tirado como aprendizado: A lembrança de que softwares open source não são invulneráveis, a gente precisa continuar prestando atenção no código, além de não negligenciar as regras básicas de segurança.
Esse problema também mostrou a agilidade dos desenvolvedores em corrigir potenciais falhas importantes, o modelo open source de desenvolvimento tem esse ponto forte, uma vez que a falha é descoberta, ela tende a ser corrigida rapidamente.
Enquanto problemas assim no Linux virarem notícia, significa que eles são raros o suficiente, o que é uma coisa boa. Além disso, como a falha parece ter sido intencionalmente inserida por um colaborador, ajudou as comunidades a lembrarem de reverem as suas políticas de segurança para com os colaboradores e softwares comunitários.
A dica é a mesma para todas as outras vezes que um bug ou malware foi encontrado em algum código de alguma distribuição que pudesse afetar alguém, mantenha o sistema atualizado, em pouco tempo, o problema vai embora.
Saída de usuários do Slackware
Slackjeff, conhecido por seu canal sobre Linux no YouTube e grande fã do Slackware, anunciou que deixará de usar a distro.
O Jeff também é professor de algumas das séries premium que oferecemos para membros Diolinux Play. Ao se tornar membro, você poderá assistir ao Slackjeff no nosso curso de Shell Script Avançado e no curso de Linux From Scratch.
A mudança de filosofia traria novos usuários ao Slackware? Um Slackware mais moderno não seria necessariamente mais amigável do que várias outras distros Linux existentes hoje em dia.
O Slackware parou no tempo, e há décadas de melhorias em usabilidade separando o que ele oferece do que os sistemas mais atuais proporcionam, especialmente em desktops. Vale a pena lembrar que vivemos em uma era onde o Ubuntu não é mais necessariamente a distro mais fácil de usar, o que dirá o Slackware.
Uma mudança de filosofia seria uma faca de dois gumes. O Slackware é interessante justamente por ser antiquado, acabou se tornando uma ferramenta de estudo, mais do que de produtividade.
Ele usa muitas tecnologias que não são usadas no mercado de trabalho hoje em dia. Certas coisas que as pessoas precisam para trabalhar não estão no Slackware, então ele acaba servindo mais para ver como um sistema funciona por baixo dos panos, não tanto para aprender o Linux de mercado atual.
Talvez um Slackware um pouco mais vanguardista não angariasse muitos novos usuários, já que existem várias outras distros que oferecem mais praticidade. Mas uma versão mais moderna poderia ajudar a manter os poucos usuários fiéis, como é o caso do Slackjeff.
Mas como tudo na vida, existe também um fim para projetos lendários assim, ainda não é a vez do Slackware, mas pode estar muito mais próximo disso do que de uma grande volta por cima. Não seria o primeiro sistema a ficar na história.
Decisões do KDE e consistência de design
Por que distros com o KDE Plasma, como o Manjaro, têm tantos aplicativos estranhos e sem consistência no design? Isso não depõe contra a interface? Por outro lado, como o Fedora consegue entregar uma experiência mais consistente?
Consistência de design é sempre bem-vinda, e embora as pessoas possam tolerar inconsistências, ninguém nunca reclamará de um design coeso.
O diferencial do Fedora com KDE é que ele não faz muitos ajustes na interface, basicamente empacota sem muitas modificações. Enquanto o Manjaro faz alterações mais intrusivas nos padrões do Plasma, e talvez o pessoal do Manjaro seja ruim em UX e UI. Isso acontece em todas as interfaces que eles usam, não é exclusividade do Plasma.
Se você quiser ver como é o Plasma sem o dedo de ninguém, exceto dos desenvolvedores do KDE, utilize o KDE Neon numa VM, o Plasma é aquilo. O Fedora KDE, com poucas modificações, fica bem perto.
Essa questão de mudar as coisas demais, ou mudar as coisas de menos, é uma balança difícil de equilibrar. Os desenvolvedores de todos esses projetos colocam as coisas da forma que eles acham que seria melhor.
Conforme você conhece as ideias e os contextos desses projetos, alguns porquês das decisões começam a ficar mais claros, mesmo que a gente não concorde.
Espero que isso ajude! Se precisar de mais alguma coisa, é só chamar.