Como uma universidade foi banida do kernel Linux

O caminho da Universidade de Minnesota para o banimento foi longo, turbulento e cheio de emoção

Na noite de 6 de abril, um estudante enviou um patch para uma lista de desenvolvedores. Quinze dias depois, a Universidade de Minnesota foi proibida de contribuir para o kernel Linux.

“Sugiro que você encontre uma comunidade diferente para fazer experimentos”, escreveu greg Kroah-Hartman, membro da Linux Foundation, em um e-mail lívido. “Você não é bem-vindo aqui.”

Como um e-mail levou a uma proibição em toda a universidade? Passei a última semana investigando este mundo – os jogadores, o jargão, a história turbulenta da universidade com software de código aberto, a devotada e com princípios da comunidade de kernel Linux. Nenhum dos pesquisadores da Universidade de Minnesota falaria comigo por esta história. Mas entre os outros personagens principais – os desenvolvedores do Linux – não houve tal hesitação. Esta era uma comunidade ansiosa para falar; era uma comunidade traída.


A história começa em 2017, quando um pesquisador de segurança de sistemas chamado Kangjie Lu tornou-se professor assistente na Universidade de Minnesota.

A pesquisa de Lu, segundo seu site,diz respeito à “interseção de segurança, sistemas operacionais, análise de programas e compiladores”. Mas Lu estava de olho no Linux — a maioria de seus trabalhos envolve o kernel Linux de alguma forma.

O kernel Linux é, em um nível básico, o núcleo de qualquer sistema operacional Linux. É a ligação entre o sistema operacional e o dispositivo em que está funcionando. Um usuário de Linux não interage com o kernel, mas é essencial fazer as coisas — ele gerencia o uso da memória, escreve coisas para o disco rígido e decide quais tarefas podem usar a CPU quando. O kernel é de código aberto, o que significa que seus milhões de linhas de código estão disponíveis publicamente para qualquer pessoa ver e contribuir.

OBTER UM PATCH NOS COMPUTADORES DAS PESSOAS NÃO É TAREFA FÁCIL

Bem, “qualquer um”. Colocar um remendo nos computadores das pessoas não é tarefa fácil. Uma submissão precisa passar por uma grande rede de desenvolvedores e “mantenedores”(milhares de voluntários, que são cada um responsável pela manutenção de diferentes partes do kernel) antes que ele finalmente acabe no repositório principal. Uma vez lá, ele passa por um longo período de testes antes de eventualmente ser incorporado à “versão estável”, que irá para os principais sistemas operacionais. É um sistema rigoroso projetado para eliminar atores maliciosos e incompetentes. Mas — como sempre acontece com operações de crowdsourced — há espaço para erros humanos.

Alguns dos trabalhos recentes de Lu giram em torno de estudar esse potencial de erro humano e reduzir sua influência. Ele propôs sistemas para detectar automaticamente vários tipos de bugs em código aberto, usando o kernel Linux como um caso de teste. Esses experimentos tendem a envolver reportar bugs, enviar patches para os mantenedores de kernel do Linux e relatar suas taxas de aceitação. Em um artigo de 2019, por exemplo, Lu e dois de seus alunos de doutorado, Aditya Pakki e Qiushi Wu, apresentaram um sistema (“Crix”) para detectar uma certa classe de bugs nos kernels do SO. O trio encontrou 278 desses bugs com crix e enviou patches para todos eles — o fato de os mantenedores aceitarem 151 significava que a ferramenta era promissora.

No geral, foi um trabalho útil. Então, no final do ano passado, Lu apontou não para o núcleo em si, mas para sua comunidade.


Em “Sobre a viabilidade de introduzir furtivamente vulnerabilidades em software de código aberto via Hypocrite Commits”, Lu e Wu explicaram que eles foram capazes de introduzir vulnerabilidades no kernel Linux, enviando patches que pareciam corrigir bugs reais, mas também introduziram problemas sérios. O grupo chamou essas submissões de “hipócritas cometidos”. (Wu não respondeu a um pedido de comentário para esta história; Lu me encaminhou para Mats Heimdahl, o chefe do departamento de ciência da computação e engenharia da universidade, que me encaminhou para o “Sobre a viabilidade de introduzir furtivamente vulnerabilidades em software de código aberto via Hypocrite Commits”, Lu e Wu .)

O objetivo explícito deste experimento, como os pesquisadores enfatizaram desde então, era melhorar a segurança do kernel Linux, demonstrando aos desenvolvedores como um ator mal-intencionado poderia escapar através de sua rede. Pode-se argumentar que seu processo era semelhante, em princípio, ao de hacking de chapéu branco: brincar com software, encontrar bugs, avisar os desenvolvedores.

Mas a reação mais alta que o jornal recebeu, no Twitter e em toda a comunidade Linux, não foi gratidão – foi um clamor.

“Esse papel, é apenas um monte de porcaria”, diz Greg Scott, um profissional de TI que trabalha com software de código aberto há mais de 20 anos.

“Na minha opinião pessoal, foi completamente antiético”, diz o pesquisador de segurança Kenneth White, que é codiretor do Open Crypto Audit Project.

A frustração tinha pouco a ver com o hipócrita se compromete. Em seu artigo, Lu e Wu alegaram que nenhum de seus bugs tinha realmente chegado ao kernel Linux – em todos os seus casos de teste, eles eventualmente puxaram seus patches ruins e forneceram os reais. Kroah-Hartman, da Linux Foundation, contesta isso — ele disse que um patch do estudo fez com que ele se transformasse em repositórios, embora ele note que não acabou causando nenhum dano.

“NA MINHA OPINIÃO PESSOAL, FOI COMPLETAMENTE ANTIÉTICO.”

Ainda assim, o jornal atingiu uma série de nervos entre uma comunidade muito apaixonada (e muito online) quando Lu compartilhou seu resumo pela primeira vez no Twitter. Alguns desenvolvedores ficaram irritados porque a universidade havia desperdiçado intencionalmente o tempo dos mantenedores – o que é uma diferença fundamental entre o trabalho de Minnesota e um hacker de chapéu branco bisbilhotando o aplicativo Starbucks para uma recompensa por bugs. “Os pesquisadores cruzaram uma linha que não deveriam ter atravessado”, diz Scott. “Ninguém contratou esse grupo. Eles escolheram fazer isso. E um monte de gente passou muito tempo avaliando seus patches.”

“Se eu fosse um voluntário colocando meu tempo pessoal em compromissos e testes, e então eu descobrisse que alguém estava experimentando, eu ficaria infeliz”, acrescenta Scott.

Então, há a questão mais dita de se um experimento como este equivale à experimentação humana.

Não, de acordo com o Conselho de Revisão Institucional da Universidade de Minnesota. Lu e Wu pediram aprovação em resposta ao clamor, e eles receberam uma carta formal de isenção.

Os membros da comunidade com quem falei não acreditaram. “Os pesquisadores tentaram obter aprovação retroativa do Conselho de Revisão Institucional sobre suas ações que eram, na melhor das hipóteses, descontroladamente ignorantes dos inquilinos das proteções básicas dos seres humanos, que normalmente são ensinadas pelo último ano das instituições de graduação”, diz White.

“Geralmente não é considerado uma coisa boa tentar fazer ‘pesquisa’ em pessoas que não sabem que você está fazendo pesquisa”, diz Kroah-Hartman. “Ninguém nos perguntou se era aceitável.”

“ESSE PAPEL É SÓ MUITA PORCARIA.”

Esse tópico percorreu muitas das respostas que recebi dos desenvolvedores — que, independentemente dos malefícios ou benefícios resultantes de sua pesquisa, a universidade estava brincando não apenas com os membros da comunidade, mas com a filosofia subjacente da comunidade. Quem usa um sistema operacional coloca algum grau de confiança nas pessoas que contribuem e mantêm esse sistema. Isso é especialmente verdade para pessoas que usam software de código aberto, e é um princípio que alguns usuários de Linux levam muito a sério.

“Por definição, o código aberto depende de uma comunidade animada”, diz Scott. “Tem que haver pessoas naquela comunidade para submeter coisas, pessoas na comunidade para documentar coisas, e as pessoas para usá-lo e criar todo esse ciclo de feedback para torná-lo constantemente mais forte. Esse loop depende de muitas pessoas, e você tem que ter um nível de confiança nesse sistema… Se alguém viola essa confiança, isso estraga as coisas.”

Após o lançamento do artigo, ficou claro para muitos desenvolvedores de kernel linux que algo precisava ser feito sobre a Universidade de Minnesota — submissões anteriores da universidade precisavam ser revistas. “Muitos de nós colocamos um item em nossa lista de tarefas que dizia: ‘Vá e audite todas as umn.edu submissões'”, disse Kroah-Hartman, que estava, acima de tudo, irritado por o experimento ter colocado outra tarefa em seu prato. Mas muitos mantenedores de kernel são voluntários com trabalhos diurnos, e um processo de revisão em larga escala não se concretizou. Pelo menos, não em 2020.


Em 6 de abril de 2021, Aditya Pakki, usando seu próprio endereço de e-mail, enviou um patch.

Houve uma breve discussão de outros desenvolvedores sobre a cadeia de e-mails, que se esvaiu em poucos dias. Então Kroah-Hartman deu uma olhada. Ele já estava em alerta máximo por código ruim da Universidade de Minnesota, e o endereço de e-mail de Pakki disparou alarmes. Além disso, o patch que Pakki apresentou não pareceu útil. “É preciso muito esforço para criar uma mudança que pareça correta, mas que faça algo errado”, disse Kroah-Hartman. “Essas submissões se encaixam nesse padrão.”

Então, em 20 de abril, Kroah-Hartman colocou o pé no chão.

“Por favor, pare de enviar patches conhecidos inválidos”, escreveu ele a Pakki. “Seu professor está brincando com o processo de revisão para conseguir um trabalho de alguma forma estranha e bizarra.”

O mantenedor Leon Romanovsky então chimed em: ele tinha dado uma olhada em quatro patches previamente aceitos de Pakki e descobriu que três deles adicionaram “várias gravidades” vulnerabilidades de segurança.HÁ A QUESTÃO MAIS DITA DE SE UM EXPERIMENTO COMO ESTE EQUIVALE À EXPERIMENTAÇÃO HUMANA

Kroah-Hartman esperava que seu pedido fosse o fim do caso. Mas então Pakki revidou. “Peço respeitosamente que cessem e desistam de fazer acusações selvagens que beiram a calúnia”, escreveu ele a Kroah-Hartman no que parece ser uma mensagem privada.

Kroah-Hartman respondeu. “Você e seu grupo admitiram publicamente o envio de patches conhecidos para ver como a comunidade do kernel reagiria a eles, e publicaram um artigo baseado nesse trabalho. Agora você submete uma série de patches obviamente incorretos novamente, então o que eu devo pensar de tal coisa?”, escreveu ele na manhã de 21 de abril.

Mais tarde naquele dia, Kroah-Hartman oficializou. “Futuras submissões de qualquer pessoa com um endereço umn.edu devem ser rejeitadas a menos que determinadas de outra forma sejam realmente uma correção válida”, escreveu ele em um e-mail para vários mantenedores, bem como Lu, Pakki e Wu. Kroah-Hartman reverteu 190 submissões de afiliados de Minnesota — 68 não puderam ser revertidas, mas ainda precisavam de revisão manual.

Não está claro de que experiência o novo patch fazia parte, e Pakki se recusou a comentar esta história. O site da Lu inclui uma breve referência a “patches supérfluos de Aditya Pakki para um novo projeto de busca de bugs”.

O que está claro é que as travessuras de Pakki finalmente definiram o processo de revisão atrasado em andamento; Os desenvolvedores do Linux começaram a pesquisar todos os patches que as afiliadas da universidade haviam apresentado no passado. Jonathan Corbet, fundador e editor-chefe da LWN.net, forneceu recentemente uma atualização sobre esse processo de revisão. Segundo sua avaliação, “A maioria dos adesivos suspeitos se mostraram aceitáveis, se não ótimos.” Dos mais de 200 patches que foram sinalizados, 42 ainda estão programados para serem removidos do kernel.


Independentemente de sua reação ter sido justificada, a comunidade Linux decide se as afiliadas da Universidade de Minnesota podem contribuir para o kernel novamente. E essa comunidade deixou claras suas exigências: a escola precisa convencê-los de que seus futuros remendos não serão uma perda de tempo de ninguém.

O que é preciso para fazer isso? Em um comunicado divulgado no mesmo dia da proibição, o departamento de ciência da computação da universidade suspendeu sua pesquisa sobre a segurança do linux-kernel e anunciou que investigaria o método de pesquisa de Lu e Wu.

Mas isso não foi suficiente para a Fundação Linux. Mike Dolan, SVP da Linux Foundation e GM de projetos, escreveu uma carta à universidade em 23 de abril. Dolan fez quatro exigências. Ele pediu que a escola divulgasse “todas as informações necessárias para identificar todas as propostas de código conhecido-vulnerável de qualquer experimento U of MN” para ajudar no processo de auditoria. Ele pediu que o trabalho sobre os hipócritas fosse retirado da publicação. Ele pediu que a escola garantisse que os experimentos futuros passassem por uma revisão do IRB antes de começarem, e que futuras revisões do IRB garantam que os sujeitos de experimentos forneçam consentimento, “de acordo com as normas e leis de pesquisa usuais”.

A ESCOLA PRECISA CONVENCÊ-LOS DE QUE SEUS FUTUROS PATCHES NÃO SERÃO UMA PERDA DE TEMPO DE NINGUÉM.

Duas dessas exigências já foram atendidas. Wu e Lu retiraram o papel e divulgaram todos os detalhes de seu estudo.

O status da universidade na terceira e quarta contagens não está claro. Em uma carta enviada à Linux Foundation em 27 de abril, Heimdahl e Loren Terveen (chefe de departamento associado do departamento de ciência da computação e engenharia) afirmam que o IRB da universidade “agiu corretamente”, e argumenta que a pesquisa de seres humanos “tem uma definição técnica precisa de acordo com as regulamentações federais dos EUA … e essa definição técnica pode não estar de acordo com a compreensão intuitiva de conceitos como ‘experimentos’ ou mesmo ‘experimentos com pessoas’.”. Eles, no entanto, comprometem-se a fornecer mais treinamento ético para os professores do departamento. Procurado para comentar, o porta-voz da universidade Dan Gilchrist me encaminhou para o site do departamento de ciência da computação e engenharia.

Enquanto isso, Lu, Wu e Pakki se desculparam com a comunidade Linux no último sábado em uma carta aberta à lista de discussão do kernel, que continha alguns pedidos de desculpas e alguma defesa. “Cometemos um erro ao não encontrar uma maneira de consultar a comunidade e obter permissão antes de executar este estudo; fizemos isso porque sabíamos que não poderíamos pedir permissão aos mantenedores do Linux, ou eles estariam à procura de patches hipócritas”, escreveram os pesquisadores, antes de reiterar que eles não tinham colocado nenhuma vulnerabilidade no kernel linux, e que seus outros patches não estavam relacionados com a pesquisa de compromissos hipócritas.

Kroah-Hartman não estava tendo. “A Linux Foundation e o Conselho Consultivo Técnico da Fundação Linux enviaram uma carta na sexta-feira à sua universidade”, respondeu ele. “Até que essas ações sejam tomadas, não temos mais nada para discutir.”

Do ponto de vista dos pesquisadores da Universidade de Minnesota, eles não se propus a trollar ninguém – eles estavam tentando apontar um problema com o processo de revisão dos mantenedores do kernel. Agora, a comunidade Linux tem que contar com as consequências de seu experimento e o que isso significa sobre a segurança do software de código aberto.

Alguns desenvolvedores rejeitaram a perspectiva dos pesquisadores da Universidade de Minnesota, alegando que é possível enganar os mantenedores deve ser óbvio para qualquer pessoa familiarizada com o software de código aberto. “Se uma pessoa suficientemente motivada e sem escrúpulos pode se colocar em uma posição confiável de atualização de software crítico, há honestamente pouco que pode ser feito para detê-los”, diz White, o pesquisador de segurança.

Por outro lado, é claramente importante estar atento a possíveis vulnerabilidades em qualquer sistema operacional. E para outros da comunidade Linux, por mais que o experimento tenha desenhado, seu ponto sobre os compromissos hipócritas parece ter sido um pouco bem tomado. O incidente desencadeou conversas sobre políticas de aceitação de patches e como os mantenedores devem lidar com submissões de novos colaboradores, através do Twitter, listas de e-mail e fóruns. “Demonstrar esse tipo de ‘ataque’ está muito atrasado e iniciou uma discussão muito importante”, escreveu o mantenedor Christoph Hellwig em um thread de e-mail com outros mantenedores. “Eu acho que eles merecem uma medalha de honra.”

“Esta pesquisa foi claramente antiética, mas ficou claro que o modelo de desenvolvimento da OSS é vulnerável a compromissos de má-fé”, escreveu um usuário em um post de discussão. “Agora parece provável que o Linux tenha algumas portas traseiras devastadoras.”

Corbet também pediu mais escrutínio em torno de novas mudanças em seu post sobre o incidente. “Se não pudermos institucionalizar um processo mais cuidadoso, continuaremos a ver muitos bugs, e não importará realmente se eles foram inseridos intencionalmente ou não”, escreveu.

“ESTE MÉTODO FUNCIONA.”

E mesmo para alguns dos críticos mais ardentes do jornal, o processo provou um ponto – embora, talvez, o oposto do que Wu, Lu e Pakki estavam tentando fazer. Demonstrou que o sistema funcionava.

Eric Mintz, que gerencia 25 servidores Linux, diz que essa proibição o deixou muito mais confiante na segurança do sistema operacional. “Tenho mais confiança no processo porque isso foi pego”, diz ele. “Pode haver compromissos que não sabemos. Mas como pegamos este, é menos provável que não saibamos sobre os outros. Porque temos algo no lugar para pegá-lo.

Para Scott, o fato de os pesquisadores terem sido pegos e banidos é um exemplo do sistema do Linux funcionando exatamente do jeito que deveria. “Esse método funcionou”, insiste. “O método SolarWinds, onde há uma grande corporação por trás disso, esse sistema não funcionou. Esse sistema funcionou.”

“Os desenvolvedores do Kernel estão felizes em ver novas ferramentas criadas e – se as ferramentas dão bons resultados – usá-las. Eles também ajudarão no teste dessas ferramentas, mas estão menos satisfeitos por serem destinatários de patches inspirados em ferramentas que carecem de revisão adequada”, escreve Corbet. A comunidade parece estar aberta ao feedback da Universidade de Minnesota — mas, como a Fundação deixou claro, cabe à escola fazer as pazes.

“A universidade poderia reparar essa confiança, sinceramente se desculpando, e não se desculpando falsamente, e talvez enviando muita cerveja para as pessoas certas”, diz Scott. “Vai ser preciso algum trabalho para restaurar sua confiança. Então, espero que eles estão até ele.