Perl et SUID

Le mercredi 26 août 2015 par Benjamin Boudoir

Je déteste sudo. Je comprends sont intérêt, mais globalement, je trouve que c'est généralement une solution sale à des problèmes qui ont une solution élégante déjà en place depuis ~40 ans.

En effet, il y a deux cas d'utilisation de sudo :

  1. avoir un user qui dispose de tous les droits sans connaitre le mot de passe root (l'approche d'Ubuntu et d'OS X) qui l'approche la plus stupide qui soit. Personne ne devrait avoir une config de sudo qui dit :
%sudo ALL=(ALL) ALL

ou pire :

%sudo ALL=(ALL) NOPASSWD:ALL
  1. Donner des droits spécifiques a une personne ou un groupe d'utilisateur. Par exemple, donner les droits de redémarrer un serveur web sur une machine de developpement ou de test au membres des groupes qa et dev. Dans ce cas ci, de nombreux cas d'utilisation viennent d'une mauvaise connaissance de certaines capacités du noyau : les acl et les bit s[g|u]id.

Ici, on va s'intéresser à l'utilisation des bits s[g|u]id avec des scripts perl parce que j'ai eu le cas d'un check nagios pour remonter des informations lisibles uniquement par un utilisateur (qui n'est pas root).

Mon vieux réflexe a été de changer le propriétaire du script pour le faire correspondre, ajouter un bit suid dessus et installer le module perl suid (car il est a noter que les bits s[u|g]id sont ignorés par Linux quand ils sont sur des scripts pour éviter les sushis). Sauf qu'icelui est déprécié depuis 2008 (oui, je fais ça rarement).

J'ai donc adopté une autre approche : compiler mon script. Il existe des compilateurs perl, pour transformer son joli script en un binaire C assez sale, mais au moins, ça marche.

Pour ma part, j'ai donc utilisé perlcc :
root@localhost# perlcc -o check_service check_service.pl
root@localhost# chown user: check_service
root@localhost# chmod u+s check_service

Et ça marche plutôt bien.