sudo-rs, implementação do sudo com segurança de memória, lança primeira versão estável

 (memorysafety.org)
1 pontos por GN⁺ 2023-11-07 | 1 comentários | Compartilhar no WhatsApp
  • sudo-rs, uma reimplementação em Rust do sudo, usado para transições de fronteira de privilégios, foi lançado em sua primeira versão estável
  • A estimativa de que cerca de um terço das falhas de segurança do sudo original envolvia problemas de gerenciamento de memória foi a principal motivação para a reescrita em Rust
  • O sudo-rs reduziu a superfície de ataque ao excluir recursos menos usados, e sua suíte de testes também é usada para encontrar bugs no sudo original
  • O Wolfi Linux OS já inclui o sudo-rs, e a Chainguard acredita que melhorias em ferramentas essenciais de segurança podem ter impacto em todo o setor
  • Uma auditoria externa de segurança estava prevista para começar em setembro de 2023; depois disso, o trabalho avançaria para o Milestone 4, focado em recursos corporativos

sudo-rs, reimplementado em Rust

  • A Prossimo publicou o primeiro lançamento estável do sudo-rs
  • O sudo-rs é um projeto que reimplementa em Rust o utilitário sudo, comumente usado no Linux para atravessar a fronteira de privilégios entre contas de usuário e contas de administrador
  • O projeto sudo-rs tem foco em aumentar a segurança em comparação com o sudo original
    • Usa Rust para garantir segurança de memória
    • O ponto de partida foi a estimativa de que cerca de um terço dos bugs de segurança do sudo original eram problemas de gerenciamento de memória
    • Reduz a superfície de ataque ao excluir recursos menos usados
    • Desenvolveu uma suíte de testes abrangente, que também encontrou bugs no sudo original

Adoção atual e próximos passos

  • O Wolfi Linux OS já inclui o sudo-rs
  • Dan Lorenc, CEO e cofundador da Chainguard, afirma que a segurança de memória foi prioridade máxima ao criar o Wolfi, e acredita que melhorias em ferramentas essenciais de segurança como o sudo podem ter grande impacto em todo o setor
  • O sudo-rs foi construído por uma equipe conjunta da Tweede Golf e da Ferrous Systems sob contrato com a Prossimo
  • O projeto foi iniciado em dezembro de 2022, e a auditoria externa de segurança do código do sudo-rs estava prevista para começar em setembro de 2023
  • Após a auditoria, a equipe passaria para o Milestone 4 do plano de trabalho, etapa focada em recursos corporativos
  • O utilitário sudo original, baseado em C, é mantido há muito tempo por Todd C. Miller, que também forneceu orientação para a implementação do sudo-rs
  • A NLnet Foundation financiou a auditoria do sudo-rs, e a Amazon Web Services apoiou este trabalho e a transição para software com segurança de memória

Leituras relacionadas

1 comentários

 
GN⁺ 2023-11-07
Opiniões do Hacker News

  • Como um dos desenvolvedores originais do sudo (https://en.wikipedia.org/wiki/Sudo), acompanhei nos últimos 43 anos ele ser quase totalmente reescrito e receber correções de bugs continuamente
    Pode-se dizer que é um dos comandos UNIX cujas falhas de segurança foram mais revisadas, e as falhas encontradas foram corrigidas
    Fico em dúvida se uma única equipe de desenvolvimento, ao reimplementar por completo uma ferramenta que foi examinada por milhares de desenvolvedores e especialistas em segurança, consegue não introduzir nem um ou dois bugs novos
    Será que a linguagem Rust tem algo que elimina magicamente toda a possibilidade de bugs entrarem?

    • Só podemos agradecer pelo trabalho de criar o sudo, e acho que é uma ferramenta realmente valiosa no uso diário de muita gente
      Do ponto de vista de quem está criando o sudo-rs, nunca tentamos invalidar o trabalho existente e sabemos muito bem, especialmente no início, que a nossa implementação não estará livre de bugs
      Pessoalmente, ao criar a versão em Rust, consegui mexer em áreas nas quais normalmente seria difícil tocar, pois não tenho tanta confiança em escrever código C relativamente seguro
      No mínimo, graças a esse trabalho já encontramos alguns bugs no sudo existente e, mesmo que ele tenha sido corrigido ao longo de 43 anos, enquanto o ambiente ao redor mudar, é difícil que um software assim fique completamente livre de bugs
      Desde que haja cooperação mútua e aprendizado com o trabalho e os erros uns dos outros, não há nada de ruim em ter algumas alternativas
    • Seja o que for que tenha acontecido nos últimos 43 anos, em 2021 houve uma vulnerabilidade de corrupção de memória amplamente explorável chamada Baron Samedit
    • Sistemas de tipos avançados, borrow checking e linguagens com segurança de memória certamente ajudam muito, mas obviamente não eliminam todos os bugs
      Ao fazer RiiR, o melhor que desenvolvedores podem fazer é seguir boas práticas e aprender com erros do passado
      Houve muito progresso em 43 anos, e só abandonar o tratamento de strings em C já elimina inúmeros bugs antes mesmo de se discutir segurança de memória
      Hoje, alguém tentando criar um substituto seguro para o sudo conseguiria fazer muito melhor do que antigamente mesmo usando apenas C, e o projeto OpenBSD mostra isso muito bem
      Se muitos dos cantos afiados que o código do OpenBSD evita forem removidos no nível da linguagem, a largada será vantajosa, mas ainda assim são necessários muito cuidado e experiência, e uma linguagem de programação não pode fornecer isso no lugar da pessoa
      No mínimo vale uma análise séria, mas acho que não deveria ser distribuído como padrão por enquanto
    • Não quero negar a experiência, e imagino que este projeto certamente vá redescobrir algumas dores, mas também é importante notar que, para entender corretamente a física clássica, não precisamos repetir exatamente o trabalho de uma vida inteira de Newton, Leibniz e Maxwell
      Hoje isso já faz parte do currículo do ensino médio; quem passa por ele consegue se virar razoavelmente bem e, com um pouco mais de esforço, consegue lidar muito bem com aquilo que eles levaram a vida inteira para realizar
      Isso é porque podemos ficar sobre os ombros de gigantes, temos hindsight, tecnologias e métodos de aprendizado melhores, e não precisamos repetir todos os erros deles
      Se o desenvolvedor original reescrevesse o sudo do zero hoje, com a experiência e o conhecimento atuais, é bem provável que conseguisse torná-lo mais limpo e simples em muito menos tempo
      Não é uma desvalorização do esforço e da experiência existentes, mas sim que não é impossível transformar essa experiência em algo melhor em menos tempo
    • Em termos de segurança de memória é verdade, e a linguagem é muito melhor para tornar as coisas seguras por padrão, mas não faz nada contra bugs de lógica
      Ainda assim, ao substituir o sudo ou outras ferramentas escritas em C, vulnerabilidades como ponteiros nulos ou mau uso de buffers facilmente respondem por 50% do total

  • Acho que os dois pontos destacados por este projeto são aspectos ainda mais frequentemente negligenciados do que o uso de Rust
    Reduzir a superfície de ataque removendo recursos menos usados e desenvolver um amplo conjunto de testes que até encontrou bugs no sudo existente
    Ao escrever código crítico para segurança, esses pontos são mais importantes até do que reescrever em Rust

  • Supondo que o objetivo deste projeto seja substituir o sudo, acho um pouco preocupante passar por cima de “excluir recursos menos usados” sem muita explicação
    É importante saber quais são esses recursos, quão menos usados eles são e de que forma falham em configurações que usam esses recursos
    Correção: parece que algumas limitações estão resumidas no README do GitHub, https://github.com/memorysafety/sudo-rs#differences-from-ori...

    • Um dos recursos ausentes é sudoedit ou sudo -e
      Uso isso com frequência ao editar arquivos dentro de /etc ou arquivos para os quais meu usuário não tem permissão; essa flag primeiro copia o arquivo para um local temporário com permissões que meu usuário pode editar e depois executa o editor de texto com as permissões do meu usuário, sem privilégios de sudo
      O editor é definido pela variável de ambiente $SUDO_EDITOR e, depois de fechado, o arquivo só é copiado de volta com as permissões originais se houver alterações
      O ponto positivo é que o editor roda como meu usuário, não como root, então carrega minhas configurações e plugins de usuário
    • Um recurso que não foi listado como ausente é a capacidade de executar make me a sandwich (https://github.com/sudo-project/sudo/blob/main/Makefile.in#L...)
    • Um recurso usado em ambientes maiores, mas que não está no roadmap do sudo-rs e não foi implementado, é o suporte a LDAP
      No sudo comum, é possível gerenciar as permissões de sudo de toda a rede a partir de uma configuração LDAP central, e também criar regras centralizadas limitadas por horário, host, usuário e comando
      Sem o risco de um simples erro de sintaxe derrubar toda a configuração; nesse caso, só aquela regra é ignorada
    • Como já passaram pelo processo de migração para o systemd, administradores de sistema provavelmente conseguem lidar com esse nível de coisa
      Certamente haverá boa documentação técnica, e, como este é um release promocional, não acho que seja o lugar para procurar uma lista de recursos ausentes
    • O fato de uma das ferramentas UNIX mais básicas ter recursos demais por si só é um sinal de alerta muito maior

  • Pela diferença entre Apache-2.0+MIT e GPL-2.0, até podemos ganhar um su/sudo-rs seguro quanto à memória, mas quem o distribuir em forma binária não terá obrigação de publicar o código-fonte usado no build nem eventuais modificações

    • Eu também queria escrever este comentário
      Tenho uma grande preocupação de que a tendência de empurrar ferramentas GPL para fora, substituindo-as por reescritas em Rust sob licença MIT/Apache, um dia leve a um Linux proprietário, mas o sudo original não é GPL
      É uma licença no estilo ISC/MIT [1]
      1. https://www.sudo.ws/about/license/
    • Sair da GPL nesses componentes essenciais é uma péssima ideia
      É pelo motivo mencionado logo acima, e estou deixando isto para enfatizar o problema
    • O Sudo não é GPL, mas sim uma licença muito permissiva da família ISC[0]
      O su parece ser de fato GPL
      [0]: https://www.sudo.ws/about/license/
    • Isso é realmente ruim?
      Você tem a liberdade de não usar uma distribuição dessas
      Do ponto de vista de segurança, um agente malicioso também poderia mostrar um código-fonte diferente daquele que distribui em binário
      Isso vale com GPL ou sem GPL
    • Para o bem ou para o mal, o uso da GPL está diminuindo, e o futuro do kernel Linux também não está garantido
      No campo dos sistemas operacionais livres e de código aberto do tipo UNIX para IoT, todos os candidatos, incluindo o ZephyrOS patrocinado pela Linux Foundation, usam uma mistura de licenças Apache, MIT e BSD
      Quando a geração GPL desaparecer, não vai demorar para surgir um sistema operacional do tipo UNIX com licenças mais atraentes para grandes empresas como outra alternativa de governança ao kernel Linux

  • Seria interessante ver uma derivação do Debian que combine isso com a implementação em Rust do GNU Coreutils
    Poderia trazer grandes ganhos em segurança de memória e desempenho
    [1] https://github.com/uutils/coreutils

    • Fico me perguntando quanto falta para um espaço de usuário UNIX baseado em Rust
      Pelo menos não será necessário implementar um compilador C

  • Estão polindo cocô?
    Uma reimplementação melhor é obviamente boa, mas você não ficou surpreso ao ler sobre os recursos estranhos do sudo?
    Até as partes que parecem comuns são muito estranhas e sutis, e portanto vulneráveis nessa medida
    Quem usa o sudo “a fundo” deveria considerar se há outro jeito

  • Seria bom ter uma flag ou ferramenta de validação/verificação que execute um teste da configuração atual do sudo e mostre as partes que o sudo-rs não oferece suporte
    Projetos assim precisam de ajudantes de portabilidade para tornar a migração tranquila

  • Se minha memória não falha, as vulnerabilidades recentes do sudo foram todas erros de lógica, não problemas de segurança de memória
    Reescrever é bom, mas não se deve fingir que não é possível introduzir novos bugs por entender mal como algo funciona ou por um erro comum

    • 2021: https://nvd.nist.gov/vuln/detail/CVE-2021-3156
      2019: https://nvd.nist.gov/vuln/detail/CVE-2019-18634
    • Quem está fingindo isso?
      Vejo muitas afirmações sobre segurança de memória, mas não me parece que este projeto diga que outros tipos de bugs serão definitivamente eliminados
    • Da mesma forma, novos bugs de memória também podem entrar no sudo existente
      Reduzir a superfície de ataque com verificação estática parece um negócio melhor no longo prazo

  • doas é uma ferramenta muito mais simples que faz a mesma coisa
    Não entendo muito bem por que não é mais usada

  • doas tem 43184 bytes e faz tudo de que eu preciso
    Aquele exploit do sudo foi um alerta
    Se você ainda não migrou, vale a pena experimentar o opendoas (pacote do Debian)