Perl CGI executer un script avec les droits root

par **HaM** » 07 Avr 2004 23:05

Salut tout le monde. Certains d'entre vous sont au courant que j'essaye de developper une application de Backup pour SME qui est dispo sur mon site, et la je suis confronté à un problème, il faut que j'execute un script bash avec les droits root depuis un CGI en perl, et je ne sais pas comment faire ça !
Une idée ??

par **sibsib** » 07 Avr 2004 23:55

Salut,

Vi, même plus qu'une idée, une solution ;-)

Ton script cgi, tu lui fais çà :
chown root:admin script.pl
chmod 4750 script.pl

Et, automagiquement, au prochain lancement, il sera exécuté par root.

Attention : la manip, telle que décrite, protège quelque peu le script : seul les membres du groupe admin vont pouvoir le lire (et donc l'exécuter en temps que root)
Si tu souhaites que tout le monde puisse le lancer ( :evil:

)
il faut faire
chmod 4755 script.pl

(Mais c'est pas forcément prudent...)

man chown et chmod pour en savoir plus, et google sticky bit pour en savoir encore beaucoup plus/

Petit détail, lié à Perl : un script qui est 'chowné' par le sticky bit (le petit 4 du chmod) est automatiquement 'tainté' , ce qui veut dire que l'appel à des commandes externes est nettement plus ch...t.
Pas la peine de passer un post ici parce que tes commandes externes ne passent plus, il faut écrire aux gens qui écrivent Perl.

(Cà sent pas un peu le vécu, çà ?)
A+,
Pascal

par **sibsib** » 08 Avr 2004 00:00

Ah, oups, lu trop vite...

Non, ton script bash ne peut pas être setuidé. (Blocage volontaire du shell).
Par contre, tu peux créer le même script en perl, qui lui supporte (avec les restrictions précédentes) le sticky bit.

Sinon, après, il reste la solution du cochon :-D

Tu fais une copie cachée de /bin/bash, et tu fait un chmod 4710 dessus, puis tu lance ton script par là...

Mais bon, faire çà c'est franchement incompatible avec toute forme de sécurité, même minimaliste...

Et à mettre dans un rpm, les gens vont t'accuser de créer une back door sur leur machine !

A+,
Pascal

par **HaM** » 08 Avr 2004 00:24

Je te remerci pour ta reponse rapide. Bon ça veut dire que j'ai beaucoup de boulot en vu car passer le script en perl n'est pas ce qu'il y a de plus facile, vu la taille du script ! (8Ko ~250 lignes).

par **Franck78** » 08 Avr 2004 00:30

J'ai ta solution si tu veux:

deux lignes de C,

tu reprends ca dans mon sguard (www en bas de message)

ou tu prend le package complet

"sbox"

http://stein.cshl.org/WWW/software/sbox/

Et les scripts suid, ca marche pas !

bye

par tj » 08 Avr 2004 00:32

Dans ce genre de cas je passe par un fichier sémaphore.
J'utilise un fichier que je renomme (en changeant l'extension par exemple).
Quand je veut lancer l'action le script Perl renomme (ou crée) un fichier du style
/ton dir/TonAction.requested

un script Shell (root) va tester ce fichier (crontab ou une boucle + sleep selon la vitesse de reaction que tu attends)
et si il trouve
/ton dir/TonAction.requested
il lance l'action et renomme le fichier en
/ton dir/TonAction.launched

(ca permet au Perl de venir voir l'état de prise en compte de l'action)

On peut même ajouter un troisième état quand l'action est finie (si elle est longue) le scrip root doit alors renommer en debut de script puis en fin de script.
/ton dir/TonAction.finished

Si plus de details sont nécessaires dans le dialogue root/Perl tu peux rediriger l'output du script shell dans le fichier, Perl ayant alors le droit de le lire

Thierry

http://t.jean.free.fr

par **Franck78** » 08 Avr 2004 00:55

C'est pas un peu dangereux cette méthode ? Tu n'es pas root, tu écris juste une ligne dans le fichier et tu obtiens ce que tu veux !
Quelle est la parade ?

Salut

par **Muzo** » 08 Avr 2004 09:04

Dites moi si je me gourre, mais l'interface Perl du server-manager elle tourne en tant qu'admin. Et en tant que telle, elle a les mêmes droits que root non?

Je suppose que l'appli de back up va se faire à partir de ces panels? (c'est pas précisé dans le post)

Si oui, je ne vois pas ou est le lézard, car perl permet de lancer des scripts bash (j'ai oublié la commande).
Tu as même 2 commandes, un qui fait l'éxécution et récupère uniquement l'état (exit(0) ou exit(1)), et une autre qui te récupère tout l'outpout (genre récupéré le texte d'un man).

A partir du moment u ton interface et ton execuitable font parti du même groupe, ce devrait fonctionner.

par **HaM** » 08 Avr 2004 12:46

Et bien en fait, le script bash est lancé depuis un CGI dans le server-manager avec la commande system(). Ce qui est bizzard c'est que le script ne fonctionne pas correctement de cette façon.
Quand il est lancé par crond ou sous root ça fonctionne (les sauveguardes sont faitent), mais via le CGI le script est lancé avec cet commande :

Code: Tout sélectionner: system("/root/./save.sh", "$bc_execsave")== 0 or die "Failed \n";

Et il y a une erreeur sur la page, "Failed"

par **Franck78** » 08 Avr 2004 12:57

J'ai exactement ce problème dans la lise à jour de la blacklist de squidguard. Le prog cgi perl s'execute avec les privilèges de nobody:nobody si ton apache est un peu "secure".

La solution est dans mon truc si tu veux allez voir. "www" en bas de message. Regarde le fichier updateblaclist.pl... (sguard)

bye

par **HaM** » 08 Avr 2004 13:07

Très interessant mais pourrais tu m'éxpliquer cette solution car je ne vois pas bien comment cela fonctionne.

par **Muzo** » 08 Avr 2004 13:32

Exact Frank78, pour que le script soit lancer par le server-manager, le propriétaire doit être le group "www" (enrésumé tout ce qui est serveur web : http, ftp, php, ..)

A ton script save, fait un test en lui mettant le propriétaire "www", et non "root" Pour info, le "root" peut mancer les script "www".

tu fais :
chmod <mon_fichier> wwww

par **sibsib** » 08 Avr 2004 20:55

Non, ce n'est pas tout à fait çà :

En fait, comme on s'authentifie admin, la page tourne au niveau du compte admin, et avec les droits admin (et seulement admin) par défaut.
Mais tous les perls script du panel sont positionnés ainsi :
Propriétaire root
groupe admin
droit -rxsr-x---
En décriptant : le propriétaire est root, il peut lire, ecrire et exécuter.
Les menbres du groupe admin peuvent lire et exécuter, et surtout, le script tourne en 'équivalent root'.

Ceci veut dire que tant qu'on reste dans l'enveloppe du script, on 'vaut' root, mais le script n'est pas dupe :
en fait la commande ip renvoie (je sais plus exactement, mais de tête) un message genre
id=admin euid=root
Je suis admin et je me fais passer pour root.
Le shell récupère l'info, et fait tourner le script au compte initial, pas au compte 'usurpé'.

A+,
Pascal

par **Gesp** » 08 Avr 2004 21:29

Je n'ai pas pratiqué SME mais je commence à maitriser pas trop mal IPCop et on utilise plusieurs solutions pour faire ce genre de choses :
- soit les commandes sont encapsulées dans un programme C, le prog C relit un fichier de conf écrit par l'interface : pas souple pour faire des modifs et tester mais le C ne fera que ce pourquoi il a été compilé, donc sûr si vous prenez soin de filtrer ce que vous lisez.

- soit les commandes sont dans un script perl setuid : il faut déteindre les variables alors préparez vous à une floraison de
$var =~ /([A-Za-z0-9_-]*)/; $var = $1;
ou
$val =~ /([\w\W]*)/; $val = $1;

- soit le script perl setuid appelle un script bash

Il est aussi prudent que dans le script, toutes les commandes soient avec le chemin complet sans utiliser le PATH.

par **Franck78** » 08 Avr 2004 22:18

J'ai pas trop rencontré les problémes décrits avant. Le cgi crée un fichier plein de commande (tempX) pour bash,et si je l'appelle directement, pas assez de privilège.
Alors je passe par cet intermédiare vraiment basique de chez basique:
Of course, l'executable C est suid. Et ca roule sans problème.

Code: Tout sélectionner: extern char **environ; /***************** START OF CODE ****************/ int main (int argc, char* argv[]) { int gid,uid,i; gid = 0; uid = 0; if (setuid(uid) < 0) { printf("couldn't setuid() to 0 (%s)\n",strerror(errno)); } /* execute the target */ execve("/var/ipcop/proxy/tempX",argv,environ); return -1; }

J'ai repris ça de sbox, lui même basé sur suexec de Apache.

Bye

Perl CGI executer un script avec les droits root

Perl CGI executer un script avec les droits root

Qui est en ligne ?