• # Rust

    Posté par  (site web personnel) . Évalué à 4 (+1/-0).

    C'est du pain béni pour Sudo-rs : https://github.com/trifectatechfoundation/sudo-rs

    • [^] # Re: Rust

      Posté par  . Évalué à 10 (+9/-1). Dernière modification le 30 septembre 2025 à 12:37.

      Oui enfin cela fait 3 mois que la faille est corrigée dans toutes les distributions (30 juin pour le paquet Debian). Et si l'on veux vraiment limiter la surface d'attaque on installe pas sudo.

      Ce qui était intéressant c'est l'exploitation originale de cette faille.

      • [^] # Re: Rust

        Posté par  (site web personnel) . Évalué à 10 (+11/-0).

        Et le fait qu'il y ait un bug dans sudo ne garantit pas qu'il n'y ait pas de bug dans sudo-rs.

        • [^] # Re: Rust

          Posté par  (site web personnel) . Évalué à 10 (+9/-0). 

          void * return_random_give_me_more_powers() {
  switch (xkcd_221.getRandomNumber()) {
    case 1:
      return &doas;
    case 2:
      return &sudo-rs;
    case 3:
      return &su;
    case 4:
      return &sudo;
    default:
      exit(42);
}

          • [^] # Re: Rust

            Posté par  . Évalué à 4 (+2/-0).

            switch (xkcd_221.getRandomNumber()) {

            héhéhé, je crois que ton switch case est biaisé :D "fair dice roll"

            ce qui est fou, c'est que je n'ai même pas eu besoin de vérifier que c'était bien celui-là :D

      • [^] # Re: Rust

        Posté par  . Évalué à 2 (+1/-1).

        Et si l'on veux vraiment limiter la surface d'attaque on installe pas sudo.

        wut? sudo est un outil qui sert à réduire la surface d'attaque. Je veux bien un peu plus d'explications là.

        • [^] # Re: Rust

          Posté par  . Évalué à 2 (+1/-1).

          sudo est un outil qui sert à réduire la surface d'attaque

          Renversement de la charge de preuve 😉
          En quoi sudo réduit-il la surface d'attaque par rapport à su ?

          Ajouter une application susceptible de contenir des failles(*) augmente la surface d'attaque surtout si on n'a pas besoin de ses spécificités (ce qui est généralement le cas).

          (*) apt changelog sudo | grep CVE

          • [^] # Re: Rust

            Posté par  . Évalué à 6 (+4/-0).

            En quoi sudo réduit-il la surface d'attaque par rapport à su ?

            Ce n'est pas comparable : sudo permet d'exécuter des commandes précises avec des permissions utilisateur différentes. Cette granularité permet de donner quelques privilèges sans donner accès à toutes les commandes. Si on veux comparer, il faut comparer avec polkit par exemple.

            Si la config sudo permet d'avoir un shell, et que l'usage de sudo se limite à faire sudo -i, alors oui, c'est équivalent à su, mais le problème ne provient pas de sudo dans ce cas :).

            • [^] # Re: Rust

              Posté par  . Évalué à 1 (+0/-1).

              Merci de lire attentivement ce que j'écris :

              surtout si on n'a pas besoin de ses spécificités

              La configuration des commandes autorisées, avec ou sans mot de passe, via sudoers est une spécificité de sudo.

              Pour le reste cela permet de se substituer à n'importe quel autre utilisateur, tout comme su (qui lui exige de connaître le mot de passe de cet utilisateur).

              • [^] # Re: Rust

                Posté par  (site web personnel, Mastodon) . Évalué à 4 (+2/-0).

                Tu as répondu toi-même : dans un cas tu sèmes le mot de passe à tout va et dans l’autre cas le mot de passe du compte cible reste confidentiel.

                “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                • [^] # Re: Rust

                  Posté par  . Évalué à 1 (+0/-1). Dernière modification le 01 octobre 2025 à 11:24.

                  On ne le sème pas, seules les personnes habilitées à administrer le système ont les clefs (ou les mots de passe si tu veux). De ce point de vue cela ne change rien.

              • [^] # Re: Rust

                Posté par  . Évalué à 7 (+5/-0).

                surtout si on n'a pas besoin de ses spécificités

                ah bah oui, forcément, du coup, c'est valable pour tout, non?

                Je n'ai pas besoin de 'xxx', donc l'installer c'est une surface d'attaque supplémentaire.
                Je n'ai pas besoin de firewall, car l'installer c'est une surface d'attaque supplémentaire.
                Je n'ai pas besoin de sudo (car mes users ont tous le mot de passe root), donc c'est une surface d'attaque supplémentaire.

                Sinon, ouais pour moi, sudo limite bien. On peut donner des droits réduits à 1 user sans lui filer les clés du chateau. bon après, y'a des vulns, certes. Le kernel linux a des vulns aussi.

              • [^] # Re: Rust

                Posté par  . Évalué à 5 (+3/-0).

                Hello,

                on est d'accord, si tu es OK avec le fait d'obtenir ou donner les pleins pouvoirs, tu peux te contenter de su.

                J'ai peut-être une déformation ou un biais à force de chercher à sécuriser les systèmes dont je suis responsable… Mais je vais donner d'autres arguments :

                • le partage de mot de passe rend la traçabilité très complexe. Une session locale ouverte par root ou admin ne permet pas de savoir qui l'a fait. En se logeant avec voltairine ou cg puis fait sudo systemctl stop syslog-ng, on sait qui a lancé la commande.
                • Si le mot de passe est partagé et qu'on souhaite révoquer l'accès à cg mais pas aux 5 autres utilisateurs, et bien il faut communiquer le mot de passe aux 5 autres, et ce de manière rapide et sécurisée.
                • sudo permet d'enregistrer toutes les commandes lancées et leur affichage (y compris pour un shell root), ce que su ne fait pas1.
                • `su' rend obligatoire de mettre un mot de passe au compte root si on veut obtenir un shell.
                • si l'accès est basé sur un mot de passe, alors un utilisateur peut bloquer les autres en le changeant.

                surtout si on n'a pas besoin de ses spécificités (ce qui est généralement le cas)

                Je me permet de faire comme toi : renversement de la charge de preuve 😉. Quel est ce "cas général" dans lequel un utilisateur peut passer root avec su, voire même connaître le mot de passe des autres comptes ?

                Dans les environnements autres que mon ordi perso, sudo offre une granularité sans laquelle il est dangereux d'offrir plus que les permissions standard.

                sudo a certainement des défauts (que doas n'a pas, que sudo-rs mitige, on peut aussi regardee polkit mais c'est encore un autre monde), en particulier, souvent que la config par défaut est laxiste. Mais en aucun cas ça ne plaide pour un mot de passe partagé ou un mécanisme "tout ou rien" comme su ou sudo bash. Quand tu veux centraliser des permissions complexes dans un LDAP ou en posant des fichiers de conf avec Puppet ou Ansible, avec sudo, tu peux. Avec su, aucune finesse possible.

                Bref, je voulais mettre en lumière les avantages qu'offre sudo, parce que ça peut donner des idées et peut-être pouvoir se dire qu'en fait, ses spécificités, on en a besoin 😇.

                1. on peut compenser avec auditd mais on aura les commandes, pas l'affichage. On a aussi pam_wheel qui permet de limiter les groupes qui ont accès à su, ce qui est un bon début. ↩

                • [^] # Re: Rust

                  Posté par  . Évalué à 2 (+0/-0).

                  Je ne peux qu'être d'accord avec a peu près tout cela puisque ce n'était pas le sujet (et que je l'aivais bien précisé)…

                  Sauf ceci :

                  `su' rend obligatoire de mettre un mot de passe au compte root si on veut obtenir un shell.
                  qui est faux. On peut avoir un compte root verrouillé et obtenir un shell avec SSH par exemple.

                  • [^] # Re: Rust

                    Posté par  . Évalué à 2 (+0/-0).

                    su rend obligatoire de mettre un mot de passe au compte root si on veut obtenir un shell.

                    qui est faux. On peut avoir un compte root verrouillé et obtenir un shell avec SSH par exemple.

                    En effet, c'est mal formulé, c'était plus clair d'écrire : su rend obligatoire de mettre un mot de passe au compte root si on veut obtenir un shell avec su :).

  • # MAJ

    Posté par  . Évalué à 8 (+8/-0). Dernière modification le 30 septembre 2025 à 12:39.

    Je cite :

    Le problème est résolu depuis presque trois mois. Comme indiqué, le message s’adresse
    davantage aux grosses structures qui auraient été plus lentes à réagir.

    Donc, ça ne concerne que les gens qui ne font pas leurs mises à jour.

    Les MAJ, c'est Bien™ ! Mangez-en !

  • # doas

    Posté par  (site web personnel) . Évalué à 5 (+4/-1).

    ça fait un paquet d'années que je suis passé à doas

    AI is a mental disorder

    • [^] # Re: doas

      Posté par  (site web personnel, Mastodon) . Évalué à 3 (+1/-0).

      je suis passé à doas

      Tu pourrais nous expliquer pourquoi ?

      • [^] # Re: doas

        Posté par  (site web personnel) . Évalué à 4 (+2/-0).

        Configuration simple et proche d'un texte lisible par un humain.

        # autorise en mot de passe avec un peu de délai entre chaque prochain commande le groupe admin
permit persist :admin

# autorise sans mot de passe les gens du groupe superadmin
permit nopass :superadmin

# autorise l'user markand à exécuter /sbin/nuke sans mot de passe
permit nopass markand cmd /sbin/nuke

        Le tout pour seulement <1000 lignes de code contre plus de 150000 pour sudo.

        AI is a mental disorder

      • [^] # Re: doas

        Posté par  (site web personnel, Mastodon) . Évalué à 5 (+3/-0).

        Cette commande/approche couvre moins de cas que sudo… Si tu n’as pas besoin de plus que ce que permet doas (ce qui est le cas de la majorité des usages), celui-ci est plus simple à mettre en œuvre.

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.