Nous avons vu l´avant-veille d´aujourd´hui (mais vous ne lisiez déjà pas) comment faire un répertoire partagé qui empêchait à n´importe qui de supprimer n´importe quoi. Aujourd´hui nous allons faire quelque chose de beaucoup plus constructif : nous allons permettre à n´importe qui de supprimer une partie du n´importe quoi (et les plus courageux d´entre vous pourrons même chercher à faire un contrôle sur le n´importe qui) sans pour autant lui permettre de supprimer le reste. Sisi, ça a une utilité : par exemple, vous voulez bien que votre soeur supprime des fichiers déposés par vous-même dans le dossier Partagé juste à l´occasion d´un coup d´oeil, mais il est hors de question qu´elle supprime le-truc-dont-tout-le-monde-a-besoin. De plus, ça va permettre aux personnes qui n´ont pas de droits d´administration de supprimer des fichiers protégés sans pour autant devoir passer par un compte admin, ou pire, par le Terminal.
Nous allons analyser le problème de façon plus unixienne : nous sommes en présence de fichiers appartenant à quelqu´un d´autre que nous, sur lesquels nous n´avons pas droit de suppression, et nous avons donc besoin de droits roots pour les supprimer, sans pour autant pouvoir appeler ces droits sur le moment. Nous avons vu la dernière fois le bit gluant, voyons aujourd´hui le bit S-UID. C´est nettement moins joli comme nom mais après tout, c´est comme l´autre, on va l´utiliser une fois puis basta.
Notre projet final est de faire un dropplet contenant un script shell (que vous pourrez après remplacer) qui détruira ce que vous ferez glisser dessus.
Partie 1 : Un bref passage par le concept de droits d´éxecutions
Vous commencez à le savoir mieux que personne, Unix est un organisme complexe, le genre dans lequel il y´a des règles sur les règles 
Nous avons vu que les fichiers avaient des droits, qui correspondaient aux autorisations des utilisateurs sur ces fichiers. Mais nous n´avons pas vu grand chose sur les utilisateurs eux-mêmes... Voici un très très bref aperçu de ce qui se passe quand un utilisateur lance une commande ou un programme.
Le système commence par regarder le droit de l´utilisateur de lancer la commande. Il faut que cet utilisateur ai droit d´executer le fichier qui désigne la commande, ce qui se voit par un "x" lorsqu´on utilise la commande ls avec l´option -l :
minipingouin:~ poulet$ ls -l /bin/ls
-r-xr-xr-x 1 root wheel 32460 Mar 21 2005 /bin/ls
Après cela, le système va lancer un nouveau processus (c´est à dire une nouvelle tâche) avec, dans ces conditions là (nous verrons après comment changer ces conditions) ce qu´on appelle un EUID rattaché au processus. C´est l´Effective User IDentifier (ne pas confondre le E avec Execution) qui décide des droits du processus. Par exemple un programme qui voudrait accèder au fichier /var/log/secure.log DOIT être lancé avec un EUID correspondant au root. Voici ce qui se passe pour un utilisateur lambda
minipingouin:~ lambda$ head /var/log/secure.log
head: /var/log/secure.log: Permission denied
Simplement parce que
minipingouin:~ lambda$ ls -l /var/log/secure.log
-rw------- 1 root admin 338113 Oct 24 12:03 /var/log/secure.log
le fichier n´est pas accessible à n´importe qui.
Nous allons faire un programme en C (si vous ne le comprenez pas, c´est pas grave) qui vérifie ce qu´on appelle l´EUID et qui essaye de faire la commande au dessus. Le voici :
- include <stdio.h>
- include <unistd.h>
main()
{
printf("Execution par %s\n", geteuid()==0 ? "le root" : "quelqu´un d´autre que le root");
system("head /var/log/secure.log");
}
Il fait appelle à la fonction geteuid() qui renvoie l´EUID du processus. Rappelez vous que le root a un UID de 0. Le test
geteuid()==0 ? "le root" : "quelqu´un d´autre que le root"
est donc une expression un peu compliquée (très célèbre en C) qui sert à afficher avec printf (ici) si le processus est lancé en root ou non.
Compilez le programme et testez le :
minipingouin:~ poulet$ cc -o foo.prog foo.c
minipingouin:~ poulet$ ./foo.prog
Execution par quelqu´un d´autre que le root
head: /var/log/secure.log: Permission denied
minipingouin:~ poulet$
C´était prévisible. Nous allons maintenant le lancer en root :
minipingouin:~ poulet$ sudo ./foo.prog
Password:
Execution par le root
... suivi du résultat de la commande head
C´est donc que l´EUID dépend de l´utilisateur. Si nous voulions utiliser un EUID de zéro depuis un utilisateur quelconque, il nous faudrait une astuce pour cela. Et nous verrons tout à l´heure les S-UID
Partie 2 : Faire d´un script shell (ou autre) proprement génial un dropplet.
Les plus dégourdis d´entre vous auront sans doute remarqué que le Finder considère mal leurs programmes pour la ligne de commande : il n´est pas possible par exemple de faire glisser un fichier sur un de ceux-là pour que le programme se lance avec le fichier comme argument. La solution facile à trouver serait de faire une nouvelle application dropplet en AppleScript ou Objective-C pour qu´elle lance notre premier programme, ce qui serait un peu long.
Heureusement, quelqu´un a pensé aux bricoleurs que nous sommes, et a écrit un programme fantastique qui transforme n´importe lequel de vos scripts en dropplet : DropScript http://www.wsanchez.net/software/
Il place votre script dans un paquet dont vous devriez connaître certains fichiers (/ représente la racine du paquet)
/Contents/MacOS/Dropnomduscript
/Contents/Ressources/script
Le premier fichier est à modifier lorsque vous changez le nom du paquet (les deux noms doivent coïncider). C´est l´executable qui vient en premier, et qui APRES appelle votre script. Le second est justemment ce script. Il existe bien sûr d´autres fichiers qui peuvent être intéressants.
Maintenant que nous savons comment faire un dropplet à partir d´un script, il ne nous manque que... le script. Pour commencer, un simple "jesupprimetoutcequimetouche" suffira :
- !/bin/sh
rm -rf $*
La première ligne est nécessaire pour qu´on puisse lancer le script depuis DropScript. La deuxième est un bon vieux rm -rf qui remplacera le $* par tous les arguments que lui aura passé Dropscript au lancement (c´est à dire tous les fichiers que vous aurez fait glisser).
Faites glisser ce script sur DropScript... paf. Vous pouvez tester ce que vous voulez dessus, mais sachez QUE CA SERA PERDU A JAMAIS (sans vouloir vous faire paniquer). Si vous voulez modifier le script (par ce que vous voulez, même d´un autre langage), vous pouvez l´ouvrir directement dans le paquet, mais parfois le Finder refuse d´ouvrir les applications qui ont au moins un de leurs fichiers ouverts. N´oubliez donc pas de tout refermer. N´oubliez pas non plus la première ligne qui indique le chemin de l´interpréteur.
Notre dropplet de suppression fonctionne donc. Mais naturellement, il subit les contraintes de la partie I, et ne peut-être lancé pour supprimer un fichier normalement interdit en écriture que depuis un compte root. Sauf que...
Partie 3 : Changer le EUID d´un programme à son lancement sans entrer de mot de passe ni en laisser un en clair dans le programme, ce qui ne serait d´ailleurs pas très sécurisé
Nous allons donc voir le bit ´s´ qui permet de lancer un programme sous le nom de son propriétaire. Reprenons l´exemple de la partie 3.
minipingouin:~ poulet$ ./foo.prog
Execution par quelqu´un d´autre que le root
head: /var/log/secure.log: Permission denied
minipingouin:~ poulet$ sudo ./foo.prog
Password:
Execution par le root
... suivi du résultat de la commande head
Nous pouvons essayer de changer le propriétaire du fichier
minipingouin:~ poulet$ sudo chown root:wheel foo.prog
minipingouin:~ poulet$ ls -l foo.prog
-rwxr-xr-x 1 root wheel 17268 Oct 24 12:51 foo.prog
minipingouin:~ poulet$ ./foo.prog
Execution par quelqu´un d´autre que le root
head: /var/log/secure.log: Permission denied
minipingouin:~ poulet$
Mais ça ne fonctionne pas vraiment mieux (ce qui est rassurant, pensez au nombre de programmes qui appartiennent au compte root dans votre système et qui seraient donc lancés en root si les choses fonctionnaient comme ça). Et voilà l´astuce :
minipingouin:~ poulet$ sudo chmod +s foo.prog
minipingouin:~ poulet$ ls -l foo.prog
-rwsr-sr-x 1 root wheel 17268 Oct 24 12:51 foo.prog
Remarquez que le bit x a laissé place à un s. Lançons maintenant notre mystérieux programme...
minipingouin:~ poulet$ ./foo.prog
Execution par le root
...et nous avons bien le résultat de la commande head.
Tout fonctionne parfaitement. Etape suivante...
Partie 4 : Appliquer notre savoir au dropplet
Commencez par placer votre dropplet dans le répertoire Partagé. Actuellement il est capable de supprimer tout ce qui vous appartient, ce qui n´est pas encore assez vaste comme champ d´application. C´est pourquoi nous allons le SUIDiser.
Commencez par aller dans le répertoire MacOS du paquet comme je le fais ici :
minipingouin:/Users/Shared poulet$ cd /Users/Shared/Dropdestruit.app/Contents/MacOS/
minipingouin:/Users/Shared/Dropdestruit.app/Conten
ts/MacOS poulet$ ls -l
total 48
-rwxr-xr-x 1 poulet poulet 22568 Aug 11 2002 Dropdestruit
Puis changeons le propriétaire, le groupe et plaçons notre S-UID
minipingouin:/Users/Shared/Dropdestruit.app/Conten
ts/MacOS poulet$ sudo chown root:wheel Dropdestruit
Password:
minipingouin:/Users/Shared/Dropdestruit.app/Conten
ts/MacOS poulet$ sudo chmod +s Dropdestruit
Vous pouvez tester, c´est redoutable.
Partie 5 : Limiter l´action !
Notre script présente un gros gros gros défaut (même plusieurs mais on va y´aller par ordre) : nous n´avons pas changé ses droits... ce qui fait qu´un utilisateur averti peut en profiter pour le modifier pour qu´il soit lancé en root... et je vous laisse deviner la suite. Réglez donc ceci par vous mêmes.
Maintenant, il en présente d´autres. Par exemple, il nous permet de supprimer n´importe quoi en le glissant-déposant dessus... ce qui n´est pas chouette, ça permet à n´importe qui de supprimer n´importe quoi dans TOUT le système. Voilà le même script en plus sécurisé
- !/bin/sh
tmp=`echo "$1" | grep -v "\.\." | grep "^/Users/Shared" `
if [ -n "$tmp" ]
then
rm -rf "$tmp"
fi
Il s´assure de trouver /Users/Shared dans le chemin du fichier, et surtout de ne pas trouver d´astuce comme un /Users/Shared/../qqchose qui permettrit d´attaquer un qqchose placé ailleurs que dans le répertoire Partagé (car les .. remontent dans le répertoire parent, je précise au cas où )
Je vous conseille fortement de ne PAS faire vos scripts en shell, car c´est vraiment un langage pénible. Préférez Python ou PHP, comme ici (écrit par Panther) :
- ! /usr/bin/php
<?php
// On est bien dans /Users/Shared?
if ( ereg("^/Users/Shared",$argv[1]) == 0 || ereg("\.\.",$argv[1])) exit("Heho ca va pas la tete t´es pas du tout la ou il faut.\n");
// Fonction de suppression d´un dossier plein
function rm_recursif($dossiern)
{
$dossier = dir($dossiern);
while ($item = $dossier->read())
{
if (is_dir($dossiern."/".$item) && $item != "." && $item != "..") rm_recursif($dossiern."/".$item);
else if ($item != "." && $item != "..") {
unlink($dossiern."/".$item);
echo $dossiern."/".$item."... Supprimé\n";
}
}
rmdir($dossiern);
echo "$dossiern... Supprimé\n";
}
// Cas d´un dossier
if(file_exists($argv[1]) && is_dir($argv[1]))
rm_recursif($argv[1]);
// Cas d´un fichier
else if (file_exists($argv[1]))
{
unlink($argv[1]);
echo $argv[1]."... Supprimé\n";
}
// Cas fichier non trouvé
else
echo "Fichier non trouve\n";
?>
Partie 6 : Où on s´aperçoit que les SUID sont utiles, et que vous avez tord de ne pas m´écouter
Vous avez dans votre système quelques programmes qui sont déjà SUID comme ps
minipingouin:~/Documents poulet$ ls -l /bin/ps
-rwsr-xr-x 1 root wheel 31932 Mar 21 2005 /bin/ps
car sinon, comment pourrait-il lister les processus de chacuns ?
Nous allons faire un autre exemple. Ecrivez
- !/bin/sh
shutdown -h now
dans un fichier nommé "eteindre". Puis :
minipingouin:~ poulet$ sudo chown root:wheel eteindre
minipingouin:~ poulet$ sudo mv eteindre /bin/eteindre
minipingouin:~ poulet$ sudo chmod +s /bin/eteindre
Normalement, si vous faites ´eteindre´, votre Mac s´éteint directement. Ne le faites pas : ça n´est pas une façon très propre de l´éteindre, et en plus ça ne marchera pas (sauf peut être sous des systèmes plus âgés). Pourquoi ?
Parce que MacOS X est bien fait : il sait que ça n´est pas une bonne idée de SUIDiser les scripts, qui ne sont que du texte et qui risquent d´être modifiés par des pirates (me demandez pas comment j´ai pas retenu l´exemple du site sur lequel j´ai vu ça). Dans le cas du Dropscript, cela a fonctionné uniquement parce que c´était un programme compilé qui lançait le script.
Il y´a pour nous deux possibilités :
Ou bien nous sommes complètement fous et nous modifions une option du kernel avec la commande
minipingouin:~ poulet$ sudo sysctl -w kern.sugid_scripts=1
kern.sugid_scripts: 0 -> 1
Ou bien nous faisons comme dans le cas du Dropscript, nous demandons à un programme compilé de lancer notre script. Un simple system("eteindre"); dans un programme lancé en C en SUID root et ça fonctionnera.
La somme des connaissances que vous venez d´emmaganiser à la suite de votre lecture est considérable.
) 