Como uma universidade foi banida do kernel Linux

14

Na noite de 6 de abril, um estudante enviado por email um patch para uma lista de desenvolvedores. Quinze dias depois, a Universidade de Minnesota foi banido de contribuir para o kernel do Linux.

“Eu sugiro que você encontre uma comunidade diferente para fazer experimentos”, escreveu Greg Kroah-Hartman, colega 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 semana passada investigando este mundo – os jogadores, o jargão, a turbulenta história da universidade com software de código aberto, a comunidade do kernel Linux dedicada e baseada em princípios. Nenhum dos pesquisadores da Universidade de Minnesota falaria comigo sobre esta história. Mas entre os outros personagens principais – os desenvolvedores Linux – não houve essa hesitação. Esta era uma comunidade ansiosa para falar; foi uma comunidade traída.


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

A pesquisa de Lu, por sua local na rede Internet, diz respeito à "interseção de segurança, sistemas operacionais, análise de programa e compiladores". Mas Lu estava de olho no Linux – a maioria de seus artigos envolve o kernel do 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 no qual está sendo executado. Um usuário Linux não interage com o kernel, mas é essencial para fazer as coisas – ele gerencia o uso da memória, grava coisas no 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 publicamente disponíveis para qualquer pessoa ver e contribuir.

Bem, "qualquer um". Colocar um patch nos computadores das pessoas não é uma tarefa fácil. Um envio precisa passar por uma grande rede de desenvolvedores e “mantenedores” (milhares de voluntários, que são responsáveis ​​pela manutenção de diferentes partes do kernel) antes que ele acabe no repositório principal. Uma vez lá, ele passa por um longo período de teste antes de ser eventualmente incorporado à “versão estável”, que irá para os sistemas operacionais convencionais. É um sistema rigoroso projetado para eliminar tanto os atores mal-intencionados quanto os incompetentes. Mas – como é sempre o caso com operações crowdsourced – há espaço para erro humano.

Alguns dos trabalhos recentes de Lu giram em torno do estudo desse potencial de erro humano e da redução de sua influência. Ele é proposto sistemas para detectar automaticamente vários tipos de bugs em código aberto, usando o kernel do Linux como caso de teste. Esses experimentos tendem a envolver relatar bugs, enviar patches aos mantenedores do kernel do Linux e relatar suas taxas de aceitação. Dentro um jornal de 2019, por exemplo, Lu e dois de seus alunos de doutorado, Aditya Pakki e Qiushi Wu, apresentaram um sistema (“Crix”) para detectar uma determinada classe de bugs em kernels do sistema operacional. O trio encontrou 278 desses bugs com o 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 mirou não no kernel em si, mas em sua comunidade.


Em "Sobre a viabilidade de introduzir furtivamente vulnerabilidades em software de código aberto via hipócrita", Lu e Wu explicado que eles foram capazes de introduzir vulnerabilidades no kernel do Linux, enviando patches que pareciam corrigir bugs reais, mas também introduziam problemas sérios. O grupo chamou essas apresentações de “compromissos hipócritas”. (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 site do departamento.)

O objetivo explícito desse experimento, como os pesquisadores enfatizaram desde então, era melhorar a segurança do kernel do Linux, demonstrando aos desenvolvedores como um agente malicioso pode escapar de sua rede. Pode-se argumentar que seu processo foi semelhante, em princípio, ao de hack de chapéu branco: brinque com o software, encontre bugs e informe os desenvolvedores.

Mas a reação mais forte que o jornal recebeu, no Twitter e em toda a comunidade Linux, não foi de gratidão – foi o 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 teve pouco a ver com os próprios compromissos hipócritas. Em seu artigo, Lu e Wu alegaram que nenhum de seus bugs tinha realmente chegado ao kernel do Linux – em todos os seus casos de teste, eles eventualmente retiraram seus patches ruins e forneceram os reais. Kroah-Hartman, da Linux Foundation, contesta isso – ele disse The Verge aquele patch do estudo chegou aos repositórios, embora ele observe que não acabou causando nenhum dano.

Ainda assim, o jornal atingiu vários nervos em uma comunidade muito apaixonada (e muito online) quando Lu compartilhou seu resumo pela primeira vez no Twitter. Alguns desenvolvedores ficaram zangados porque a universidade desperdiçou intencionalmente o tempo dos mantenedores – o que é uma diferença fundamental entre o trabalho de Minnesota e um hacker de chapéu branco fuçando no aplicativo Starbucks em busca de uma recompensa por bug. “Os pesquisadores cruzaram uma linha que não deveriam ter cruzado”, diz Scott. “Ninguém contratou esse grupo. Eles apenas escolheram fazer isso. E muitas pessoas passaram muito tempo avaliando seus patches. ”

“Se eu fosse um voluntário investindo meu tempo pessoal em commits e testes e descobrisse que alguém está experimentando, ficaria infeliz”, acrescenta Scott.

Então, há a questão mais complicada de saber se um experimento como este equivale a experimentação humana. Isso não acontece, de acordo com o Comitê de Revisão Institucional da Universidade de Minnesota. Lu e Wu solicitaram aprovação em resposta ao clamor e receberam uma carta formal de isenção.

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

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

Esse tópico percorreu muitas das respostas que recebi dos desenvolvedores – que, independentemente dos danos ou benefícios que resultaram de sua pesquisa, a universidade estava mexendo não apenas com os membros da comunidade, mas com a filosofia subjacente da comunidade. Qualquer pessoa que use um sistema operacional deposita algum grau de confiança nas pessoas que contribuem e mantêm esse sistema. Isso é especialmente verdadeiro 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 ativa”, diz Scott. “Tem que haver pessoas nessa comunidade para enviar coisas, pessoas na comunidade para documentar coisas e pessoas para usá-las e configurar todo esse ciclo de feedback para torná-lo constantemente mais forte. Esse ciclo depende de muitas pessoas, e você tem que ter um nível de confiança nesse sistema … Se alguém violar essa confiança, isso bagunça as coisas. ”

Após o lançamento do artigo, ficou claro para muitos desenvolvedores do kernel Linux que algo precisava ser feito em relação à Universidade de Minnesota – as submissões anteriores da universidade precisavam ser revisadas. “Muitos de nós colocamos um item em nossa lista de tarefas que dizia: 'Vá e audite todos os envios de umn.edu'”, disse Kroah-Hartman, que estava, acima de tudo, incomodado com o fato de o experimento ter colocado outra tarefa em seu placa. Mas muitos mantenedores do kernel são voluntários com trabalhos diários, e um processo de revisão em grande escala não se materializou. 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 na cadeia de e-mail, que acabou em poucos dias. Então Kroah-Hartman deu uma olhada. Ele já estava em alerta máximo por código inválido da Universidade de Minnesota, e o endereço de e-mail de Pakki disparou o alarme. Além do mais, o patch enviado por Pakki não pareceu útil. “É preciso muito esforço para criar uma mudança que pareça correta, mas que faça algo errado”, disse-me Kroah-Hartman. “Todos esses envios se enquadram nesse padrão.”

Então, em 20 de abril, Kroah-Hartman bateu o pé.

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

O mantenedor Leon Romanovsky então se intrometeu: ele deu uma olhada em quatro patches previamente aceitos de Pakki e descobriu que três deles adicionavam vulnerabilidades de segurança de “várias gravidades”.

Kroah-Hartman esperava que seu pedido encerrasse o caso. Mas então Pakki atacou de volta. “Eu respeitosamente peço que você pare e desista de fazer acusações selvagens que estão beirando a calúnia”, ele escreveu a Kroah-Hartman no que parece ser uma mensagem privada.

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

Mais tarde naquele dia, Kroah-Hartman tornou isso oficial. “Submissões futuras de qualquer pessoa com um endereço umn.edu devem ser rejeitadas por padrão, a menos que seja determinado de outra forma como uma correção válida”, escreveu ele em um o email para vários mantenedores, bem como Lu, Pakki e Wu. Kroah-Hartman reverteu 190 envios de afiliados de Minnesota – 68 não puderam ser revertidos, mas ainda precisavam de revisão manual.

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

O que está claro é que as palhaçadas de Pakki finalmente colocaram o processo de revisão atrasado em movimento; Os desenvolvedores Linux começaram a vasculhar todos os patches que os afiliados da universidade haviam enviado no passado. Jonathan Corbet, fundador e editor-chefe da LWN.net, recentemente forneceu uma atualização sobre esse processo de revisão. De acordo com sua avaliação, “a maioria dos patches suspeitos acabou sendo aceitável, se não ótimo”. Dos mais de 200 patches sinalizados, 42 ainda estão definidos para serem removidos do kernel.


Independentemente de sua reação ser justificada, a comunidade Linux decide se os afiliados da Universidade de Minnesota podem contribuir com o kernel novamente. E essa comunidade deixou suas demandas claras: a escola precisa convencê-los de que seus patches futuros não serão uma perda de tempo de ninguém.

O que será necessário para fazer isso? Em um comunicado divulgado no mesmo dia da proibição, o departamento de ciência da computação da universidade suspendeu suas pesquisas sobre segurança do kernel do Linux e anunciado que investigaria o método de pesquisa de Lu e Wu.

Mas isso não foi suficiente para a Linux Foundation. Mike Dolan, SVP e GM de projetos da Linux Foundation, escreveu uma carta para a universidade em 23 de abril, que The Verge viu. Dolan fez quatro exigências. Ele pediu que a escola liberasse “todas as informações necessárias para identificar todas as propostas de código vulnerável conhecido de qualquer experimento da Universidade do MN” para ajudar no processo de auditoria. Ele pediu que o artigo sobre os cometimentos de hipócritas fosse retirado de publicação. Ele pediu que a escola garantisse que os experimentos futuros passassem pela revisão do IRB antes de começar, e que as revisões futuras do IRB garantissem que os sujeitos dos experimentos fornecessem consentimento, "de acordo com as normas e leis usuais de pesquisa"

Duas dessas demandas já foram atendidas. Wu e Lu têm retraído o papel e tem liberado todos os detalhes de seu estudo.

O status da universidade na terceira e quarta contagens não é claro. Em um carta enviado para a Linux Foundation em 27 de abril, Heimdahl e Loren Terveen (chefe do 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 com seres humanos “tem uma definição técnica precisa regulamentos federais … e esta 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, entretanto, se comprometem a fornecer mais treinamento ético para o corpo docente do departamento. Obtido para comentar, o porta-voz da universidade Dan Gilchrist me indicou o site do departamento de ciência da computação e engenharia.

Enquanto isso, Lu, Wu e Pakki pediram desculpas à comunidade Linux no último sábado em um carta aberta para a lista de discussão do kernel, que continha algumas desculpas e algumas defesas. “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 ficariam à procura de patches hipócritas ”, escreveram os pesquisadores, antes de reiterar que não haviam colocado nenhuma vulnerabilidade no kernel do Linux , e que seus outros patches não estavam relacionados à pesquisa de commits hipócritas.

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

Coronavírus em Minnesota

Foto de Glen Stubbe / Star Tribune via Getty Images

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

Algum desenvolvedores rejeitou a perspectiva dos pesquisadores da Universidade de Minnesota, alegando que o fato de que é possível enganar os mantenedores deveria ser óbvio para qualquer pessoa familiarizada com software de código aberto. “Se uma pessoa suficientemente motivada e inescrupulosa pode se colocar em uma posição confiável para atualizar softwares essenciais, honestamente há pouco que pode ser feito para impedi-la”, 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 na comunidade Linux, por mais ira que o experimento atraiu, seu argumento sobre os commits hipócritas parece ter sido bem entendido. O incidente gerou conversas sobre políticas de aceitação de patch e como os mantenedores devem lidar com os envios de novos contribuidores, por meio do Twitter, listas de e-maile fóruns. “A demonstração desse tipo de 'ataque' já era muito esperada e deu início a uma discussão muito importante”, escreveu o mantenedor Christoph Hellwig em um tópico de e-mail com outros mantenedores. “Acho que eles merecem uma medalha de honra.”

“Esta pesquisa foi claramente antiética, mas deixou claro que o modelo de desenvolvimento OSS é vulnerável a comissões de má-fé”, escreveu um usuário em um postagem 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 publicar sobre o incidente. “Se não pudermos institucionalizar um processo mais cuidadoso, continuaremos a ver muitos bugs, e realmente não importa se foram inseridos intencionalmente ou não”, escreveu ele.

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

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 conhecemos. Mas porque pegamos este, é menos provável que não saibamos sobre os outros. Porque temos algo pronto para pegá-lo. ”

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

“Os desenvolvedores de kernel ficam felizes em ver novas ferramentas criadas e – se as ferramentas derem bons resultados – usá-las. Eles também ajudarão no teste dessas ferramentas, mas não ficarão satisfeitos por receberem patches inspirados em ferramentas que carecem de uma 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 restaurar essa confiança desculpando-se sinceramente, e não desculpas falsas, e talvez enviando muita cerveja para as pessoas certas”, diz Scott. “Vai demorar um pouco para restaurar a confiança deles. Então, espero que eles estejam preparados. "

Fonte: The Verge