Les développeurs travaillent sur la réécriture de sudo et su en Rust – Informatique – Actualités

Edit : merci les amis, je sais que vous pouvez y faire des choses en tant qu’autres utilisateurs/admin/root ; la question est ce qu’il fait techniquement. En d’autres termes, comment su(do) fait-il cela ? À quoi ressemble une alternative sudo ?

Il existe plusieurs implémentations de su, mais elles fonctionnent généralement de la même manière. je vais prendre cette version je regarde util-linux pour référence, puisqu’il s’agit de la version que j’utilise ici sur Ubuntu ; donc c’est su mais pas sudo. sudo fait à peu près ce que su fait, mais a beaucoup plus d’options pour exécuter de manière transparente ou non transparente certaines commandes pour certains groupes et utilisateurs.

Tout d’abord, les arguments de la ligne de commande sont lus et il est déterminé ce qui doit être fait. Ensuite, le chargement sécurisé des fichiers de configuration nécessaires est prêt et le périphérique d’entrée spécifique est recherché afin qu’il puisse être lu directement à partir de celui-ci (afin que les attaques par injection soient moins probables et que vous ne puissiez pas simplement diriger votre mot de passe vers su).

Ensuite, les informations de l’utilisateur actuel et de l’utilisateur souhaité sont demandées et validées. Celui-ci sert à effectuer l’authentification (lire : le mot de passe ou votre empreinte digitale ou votre carte à puce est validée).

Le bon shell est alors recherché, si nécessaire, un appel à initgroups() est fait pour mettre à jour la liste des groupes à partir du système de fichiers. Les limites de ressources nécessaires (voir par exemple ici) sont mis à jour pour le nouvel utilisateur et une session est ouverte via PAM afin que le système soit prêt à changer d’identité.

Ensuite, le processus est bifurqué pour qu’il y ait un processus enfant et un sous-processus qui surveillent les choses et pour que les anciennes données nécessaires puissent être nettoyées. Le processus enfant est utilisé pour changer d’utilisateur.

Puis ils appellent setgid() dans régler le temps() Sur. Ces API ne sont disponibles que dans les binaires avec un attribut de système de fichiers spécial (SUID pour setuid, SGID pour setgroupid). Ils indiquent au noyau de modifier la liste des processus et d’ajuster les autorisations et les privilèges afin que le processus s’exécute désormais en tant qu’utilisateur et groupe différents. su et, dans une certaine mesure, sudo consistent simplement à appeler correctement ces deux API.

Maintenant que le processus s’exécute en tant qu’utilisateur prévu, l’environnement est modifié (afin que $HOME et autres soient corrects) et le programme remplace le répertoire courant par le répertoire personnel.

Si une commande est donnée, elle sera maintenant exécutée, sinon le programme appelle le shell par défaut via execv(). execv remplace le processus en mémoire (charge une nouvelle image, appelle son main(), efface toute la mémoire et autres du processus actuel) et ne crée donc pas de processus enfant. C’est là que su se termine à moins que execv n’échoue, puis affiche simplement un message d’erreur.

Vous pouvez créer votre propre su assez facilement. Vous devez appeler l’API pour valider l’utilisateur, puis appeler les API pour l’UID et le GID, et le tour est joué. En fait, la validation des utilisateurs est techniquement facultative ! Si votre binaire a les attributs nécessaires, vous pouvez appeler setuid et setguid tout de suite !
Il y a beaucoup de comptabilité et de C-API impliqués dans les outils normaux et l’ordre des choses est extrêmement important ; mélangez l’ordre et vous pourriez accidentellement donner à tout le monde des privilèges root !

Vous pouvez obtenir une explication plus détaillée de la façon dont vous pourriez implémenter cela dans Rust trouver ici. Remarquez, ce blog utilise un style assez… intéressant, si c’est trop pour vous, vous pouvez toujours lire le code C de su et sudo.

[Reactie gewijzigd door GertMenkel op 1 mei 2023 10:10]