Publication de la première version stable de sudo-rs, une implémentation de sudo sûre pour la mémoire

 (memorysafety.org)
1 points par GN⁺ 2023-11-07 | 1 commentaires | Partager sur WhatsApp
  • sudo-rs, une réimplémentation en Rust de sudo, utilisé pour franchir les frontières de privilèges, est publié dans sa première version stable
  • Le principal moteur de cette réécriture en Rust est l’estimation selon laquelle environ un tiers des bugs de sécurité du sudo d’origine relevaient de problèmes de gestion de la mémoire
  • sudo-rs réduit la surface d’attaque en excluant des fonctionnalités moins utilisées, et sa suite de tests sert aussi à découvrir des bugs dans le sudo d’origine
  • Wolfi Linux OS inclut déjà sudo-rs, et Chainguard estime que l’amélioration d’outils critiques pour la sécurité peut avoir un impact sur l’ensemble du secteur
  • Un audit de sécurité externe doit commencer en septembre 2023, après quoi les travaux passeront au Milestone 4, centré sur les fonctionnalités d’entreprise

sudo-rs, réimplémenté en Rust

  • Prossimo a publié la première version stable de sudo-rs
  • sudo-rs est un projet qui réimplémente en Rust l’utilitaire sudo, couramment utilisé sous Linux pour franchir la frontière de privilèges entre un compte utilisateur et un compte administrateur
  • Le projet sudo-rs se concentre sur l’amélioration de la sécurité par rapport au sudo d’origine
    • Il utilise Rust afin d’assurer la sûreté mémoire
    • Son point de départ est l’estimation selon laquelle environ un tiers des bugs de sécurité du sudo d’origine étaient liés à la gestion de la mémoire
    • Il réduit la surface d’attaque en excluant des fonctionnalités moins couramment utilisées
    • Il a développé une suite de tests étendue, qui a également permis de trouver des bugs dans le sudo d’origine

Adoption et prochaines étapes

  • Wolfi Linux OS inclut déjà sudo-rs
  • Dan Lorenc, CEO et cofondateur de Chainguard, estime que la sûreté mémoire était une priorité absolue lors de la création de Wolfi, et que l’amélioration d’outils centraux pour la sécurité comme sudo peut avoir un impact majeur sur tout le secteur
  • sudo-rs a été construit par une équipe conjointe de Tweede Golf et Ferrous Systems, sous contrat avec Prossimo
  • Le projet a démarré en décembre 2022, et un audit de sécurité externe du code de sudo-rs doit commencer en septembre 2023
  • Après l’audit, l’équipe passera au Milestone 4 du plan de travail, une étape centrée sur les fonctionnalités d’entreprise
  • L’utilitaire sudo d’origine basé sur C est maintenu depuis longtemps par Todd C. Miller, qui a aussi fourni des conseils pour l’implémentation de sudo-rs
  • La NLnet Foundation a financé l’audit de sudo-rs, et Amazon Web Services soutient ce travail ainsi que la transition vers des logiciels sûrs pour la mémoire

À lire aussi

1 commentaires

 
GN⁺ 2023-11-07
Avis de Hacker News

  • En tant que l’un des développeurs originels de sudo (https://en.wikipedia.org/wiki/Sudo), je l’ai vu être presque entièrement réécrit et continuellement corrigé au cours des 43 dernières années
    On pourrait dire que c’est la commande UNIX dont les failles de sécurité ont été les plus passées en revue, et les failles découvertes ont été corrigées
    Je me demande si une seule équipe de développement peut réimplémenter entièrement un outil que des milliers de développeurs et d’experts en sécurité ont examiné sans introduire ne serait-ce qu’un ou deux nouveaux bugs
    Je me demande si le langage Rust a quelque chose qui élimine magiquement toute possibilité d’introduire des bugs

    • On ne peut qu’être reconnaissant pour le travail qui a donné naissance à sudo, et je pense que c’est un outil vraiment précieux dans l’usage quotidien de beaucoup de gens
      Du point de vue de ceux qui développent sudo-rs, nous n’avons jamais cherché à invalider le travail existant et, surtout au début, nous savons bien que notre implémentation ne sera pas exempte de bugs
      Personnellement, en créant une version Rust, j’ai pu aborder un domaine auquel je n’aurais normalement pas osé toucher, faute d’avoir une grande confiance dans ma capacité à écrire du code C relativement sûr
      À tout le moins, ce travail nous a déjà permis de trouver quelques bugs dans le sudo existant, et même s’il a été corrigé pendant 43 ans, tant que l’environnement autour de lui change, il est difficile pour ce type de logiciel de devenir totalement exempt de bugs
      Tant que nous coopérons et apprenons du travail et des erreurs des uns et des autres, avoir quelques alternatives n’a rien de mauvais
    • Quoi qu’il se soit passé au cours des 43 dernières années, il y a eu en 2021 une vulnérabilité de corruption mémoire largement exploitable appelée Baron Samedit
    • Les systèmes de types avancés, le borrow checking et les langages à mémoire sûre aident clairement beaucoup, mais ils n’éliminent évidemment pas tous les bugs
      Quand on fait du RiiR, le mieux que les développeurs puissent faire est de suivre les bonnes pratiques et d’apprendre des erreurs passées
      En 43 ans, on a beaucoup progressé, et rien que l’abandon de la gestion des chaînes en C élimine un grand nombre de bugs avant même de parler de sûreté mémoire
      Aujourd’hui, quelqu’un qui veut créer un remplaçant sécurisé de sudo peut faire bien mieux qu’autrefois même en utilisant seulement C, et le projet OpenBSD l’illustre assez bien
      Si l’on élimine au niveau du langage une grande partie des arêtes vives que le code OpenBSD évite, on part avec un avantage, mais il faut toujours beaucoup de prudence et d’expérience, et un langage de programmation ne peut pas les fournir à votre place
      Cela mérite au moins un examen sérieux, mais je ne pense pas que cela devrait être distribué par défaut pour le moment
    • Je ne cherche pas à nier l’expérience, et je m’attends clairement à ce que ce projet redécouvre certaines douleurs, mais il est aussi important de noter que nous n’avons pas besoin de répéter tel quel le travail de toute une vie de Newton, Leibniz ou Maxwell pour bien comprendre la physique classique
      Elle fait désormais partie du programme du lycée, et si on le maîtrise, on peut déjà s’en sortir plutôt bien ; avec un peu plus d’efforts, on peut très bien manier ce qu’ils ont mis une vie à accomplir
      C’est parce que l’on peut se tenir sur les épaules des géants, que l’on bénéficie du recul ainsi que de meilleures technologies et méthodes d’apprentissage, et que l’on n’a pas besoin de répéter toutes leurs erreurs
      Si le développeur originel réécrivait aujourd’hui sudo à partir de zéro avec son expérience et ses connaissances actuelles, il est très probable qu’il pourrait en faire quelque chose de plus propre et de plus simple en beaucoup moins de temps
      Il ne s’agit pas de dénigrer les efforts et l’expérience existants, mais de dire qu’il n’est pas impossible de transformer cette expérience en quelque chose de meilleur en moins de temps
    • C’est vrai pour la sûreté mémoire, et les langages qui rendent les choses sûres par défaut sont bien meilleurs, mais ils ne font rien contre les bugs de logique
      Cela dit, lorsqu’on remplace sudo en C ou d’autres outils, les vulnérabilités comme les pointeurs nuls ou les abus de buffers représentent facilement 50 % du total

  • Je pense que les deux points mis en avant par ce projet sont des aspects encore plus souvent négligés que l’usage de Rust
    Il s’agit de réduire la surface d’attaque en retirant des fonctionnalités peu utilisées, et de développer une vaste suite de tests qui a même permis de trouver des bugs dans le sudo existant
    Quand on écrit du code critique pour la sécurité, ces aspects sont encore plus importants qu’une réécriture en Rust

  • Si l’on suppose que l’objectif de ce projet est de remplacer sudo, balayer d’un revers de main le fait d’« exclure les fonctionnalités moins utilisées » est un peu inquiétant
    Il est important de savoir quelles sont ces fonctionnalités, à quel point elles sont moins utilisées, et comment les configurations qui les utilisent échouent
    Modification : il semble que certaines limitations soient récapitulées dans le README GitHub, https://github.com/memorysafety/sudo-rs#differences-from-ori...

    • L’une des fonctionnalités manquantes est sudoedit, ou sudo -e
      Je l’utilise souvent pour modifier des fichiers sous /etc ou des fichiers sur lesquels mon utilisateur n’a pas de droits ; ce flag commence par copier le fichier vers un emplacement temporaire que mon utilisateur peut modifier, puis lance l’éditeur de texte avec les droits de mon utilisateur, sans privilèges sudo
      L’éditeur est défini par la variable d’environnement $SUDO_EDITOR, et après sa fermeture, le fichier n’est recopié avec les droits d’origine que s’il y a eu des changements
      L’intérêt, c’est que l’éditeur tourne avec mon utilisateur, pas avec root, et charge donc ma configuration et mes plugins utilisateur
    • Une fonctionnalité qui n’est pas indiquée comme manquante est celle qui exécute make me a sandwich (https://github.com/sudo-project/sudo/blob/main/Makefile.in#L...)
    • Une fonctionnalité utilisée dans des environnements plus importants, absente de la roadmap de sudo-rs et non implémentée, est la prise en charge de LDAP
      Avec sudo classique, on peut gérer les droits sudo de tout un réseau depuis une configuration LDAP centralisée, et définir aussi centralement des règles limitées par heure, hôte, utilisateur et commande
      Sans qu’une simple erreur de syntaxe risque de faire tomber toute la configuration : dans ce cas, seule la règle concernée est ignorée
    • Les administrateurs système ont déjà traversé la migration vers systemd, donc ils devraient pouvoir gérer ce genre de chose
      Il y aura sûrement une excellente documentation technique, et comme il s’agit d’une annonce promotionnelle, je ne pense pas que ce soit l’endroit où chercher la liste des fonctionnalités manquantes
    • Le fait que l’un des outils UNIX les plus fondamentaux embarque autant de fonctionnalités est en soi un signal d’alarme bien plus important

  • Quand on regarde la différence entre Apache-2.0+MIT et GPL-2.0, on peut bien obtenir des su/sudo-rs sûrs pour la mémoire, mais ceux qui les distribuent sous forme binaire ne sont pas tenus de publier le code source utilisé pour la compilation, ni les éventuelles modifications

    • Je voulais écrire ce commentaire moi aussi
      Je crains beaucoup que la tendance à remplacer des outils GPL par des réécritures Rust sous licence MIT/Apache ne mène un jour à un Linux propriétaire, mais sudo n’est pas GPL à l’origine
      C’est une licence de style ISC/MIT [1]
      1. https://www.sudo.ws/about/license/
    • S’éloigner de la GPL pour ce genre de composants critiques est une très mauvaise idée
      Pour la raison mentionnée juste au-dessus ; je laisse ceci afin de souligner le problème
    • Sudo n’est pas sous GPL, mais sous une licence de la famille ISC[0], très permissive
      su semble effectivement être sous GPL
      [0]: https://www.sudo.ws/about/license/
    • Est-ce vraiment si mauvais ?
      On a la liberté de ne pas utiliser une telle distribution
      Côté sécurité, un acteur malveillant pourrait aussi distribuer un binaire tout en montrant un code source différent
      GPL ou non, c’est pareil
    • En bien ou en mal, l’usage de la GPL recule, et même l’avenir du noyau Linux n’est pas garanti
      Dans le domaine des systèmes d’exploitation libres et open source de type UNIX pour l’IoT, tous les candidats, y compris ZephyrOS soutenu par la Linux Foundation, utilisent un mélange de licences Apache, MIT et BSD
      Une fois la génération GPL disparue, un système d’exploitation de type UNIX doté d’une licence plus attrayante pour les grandes entreprises apparaîtra bientôt comme une autre solution durable de gouvernance que le noyau Linux

  • Il serait intéressant de voir une dérivée de Debian combinant cela avec les GNU Coreutils implémentés en Rust
    Cela pourrait apporter de gros gains en sécurité mémoire et en performances
    [1] https://github.com/uutils/coreutils

    • Je me demande combien de temps il reste avant d’avoir un espace utilisateur UNIX basé sur Rust
      Au moins, il ne sera pas nécessaire d’implémenter un compilateur C

  • Est-ce qu’on ne serait pas en train de faire briller une crotte ?
    Une meilleure réimplémentation est évidemment une bonne chose, mais vous n’avez pas été surpris en lisant les fonctionnalités bizarres de sudo ?
    Même les parties qui semblent ordinaires sont très étranges et subtiles, et donc tout aussi vulnérables
    Les gens qui utilisent sudo « en profondeur » feraient bien de se demander s’il existe une autre façon de faire

  • Ce serait bien d’avoir un flag ou un outil de validation/vérification qui exécute à blanc la configuration sudo actuelle et affiche les parties que sudo-rs ne prend pas en charge
    Pour ce genre de projet, un assistant de portabilité faciliterait la transition

  • Si ma mémoire est bonne, les vulnérabilités récentes de sudo étaient toutes des erreurs de logique, pas des problèmes de sécurité mémoire
    Réécrire est une bonne chose, mais il ne faut pas faire comme si de nouveaux bugs ne pouvaient pas être introduits parce que quelqu’un a mal compris le fonctionnement de quelque chose, ou simplement commis une erreur ordinaire

    • 2021 : https://nvd.nist.gov/vuln/detail/CVE-2021-3156
      2019 : https://nvd.nist.gov/vuln/detail/CVE-2019-18634
    • Qui fait comme si c’était le cas ?
      Je vois beaucoup d’affirmations sur la sécurité mémoire, mais ce projet ne semble pas dire que les autres types de bugs seront à coup sûr éliminés
    • De la même manière, de nouveaux bugs mémoire peuvent être introduits dans le sudo existant
      Réduire la surface d’attaque par des vérifications statiques semble être un meilleur compromis à long terme

  • doas est un outil beaucoup plus simple qui fait la même chose
    Je ne comprends pas bien pourquoi il n’est pas plus utilisé

  • doas fait 43 184 octets, et fait tout ce dont j’ai besoin
    Cet exploit sudo a été un signal d’alarme
    Si vous n’avez pas encore migré, opendoas (paquet Debian) vaut le coup d’essayer