| Qui est en ligne ? |
| Il y a : 12 utilisateurs en ligne, consultez le détail |
Forum » Serveur, Réseaux et Programmation » script bash root lancé par php et serveur web |
Forum modéré par : jblecanard |
| Même auteur |
|
Score ( voter ) : |
|
 |
| Page : [1] 2 |
| Auteur | Message |
|---|---|
 |
|
Scarabée Forum : Inscrit Association : Arrivé(e) le : 19-02-2008 Nombre de messages : 561 |
Bonjour tout le monde je fais un appel aux artistes du codage bash je fais un script php et bash pour administrer un système d'usager web donc à un moment j'ai un script php qui lance un script bash la commande php qui marche dans mon script php est system("sh ./userscript.sh $login $passe", $result);le script bash doit fonctionner en root pour lancer plusieurs commandes dont principalement useradd dont dépendent ensuite des commandes mkdir et chmod et chgrp et chown donc j'ai mis le bit suid dessus en faisant chmod +s dessus la réponse de ls -ahl sur ce script est : _rwsr-sr-x 1 root root ... le début du script incriminé dans ce qui ne marche pas est : #! /bin/sh export userid=$1 export password=$2 /usr/sbin/useradd $userid -s /bin/false -d /home/paul/http/$userid -m -p $password mkdir /home/paul/http/$userid/http ...etc... le reste du script fonctionne y compris les commandes mysql de création d'utilisateur et de base... la réponse donnée à la commande incriminée est useradd: cannot lock /etc/passwd; try agin later ça me parait logique du fait que useradd doit être lancé par root pour fonctionner. donc là je sais pas comment faire et je veux pas mettre du sudo là dedans pour des raisons de sécurité évidentes... comment font-ils dans les systèmes de gestion d'hébergement web ?... voilà donc si vous avez une idée ? j'ai lu l'article suivant qui m'a inspiré... http://blog.khemael.net/2010/08/26/de-la-maniere-de-faire-de-lexec-et-system-root-en-php/ |
|
|
|
|
|
Scarabée Forum : Inscrit Association : Arrivé(e) le : 19-02-2008 Nombre de messages : 561 |
j'ai ensuite modifié le système en installant les scripts php dans /var/www/adm/ et le script bash dans /usr/lib/cgi-bin/ j'ai de même mis le setuid sur le script bash dans ce nouvel emplacement etc... mais j'obtiens la même réponse de useradd qui ne peut vérouiller /etc/passwd donc en fait ça ne marche pas, ce qui d'une certaine façon est rassurant. |
|
|
|
|
|
|
Scarabée Forum : Inscrit Association : Arrivé(e) le : 19-02-2008 Nombre de messages : 561 |
le script bash qui marche sans être lancé dangereusement par www-data, donc en console et qui ajoute un utilisateur de l'espace d'hébergement, à partir uniquement de son login et de son mot de passe et que donc je tente de faire passer par php script bash d'automatisation de l'inscription d'un utilisateur à lancer en console root en passant les paramètres login et motdepasse de l'utilisateur comme suit $; ./script.sh login motdepasse #! /bin/sh export userid=$1 export password=$2 /usr/sbin/useradd $userid -s /bin/false -d /chemindossierusager/$userid -m -p $password mkdir /chemindossierusager/$userid/http chgrp -R $userid /chemindossierusager/$userid/http chown -R $userid /chemindossierusager/$userid/http chmod -R 755 /chemindossierusager/$userid/http mysql -u root -p"NamdepjucJi" -e "CREATE USER '$userid'@'localhost' IDENTIFIED BY '$password'; GRANT USAGE ON *.* TO '$userid'@'localhost' IDENTIFIED BY '$userid' WITH MAX_QUERIES_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_USER_CONNECTIONS 0; CREATE DATABASE IF NOT EXISTS $userid; GRANT ALL PRIVILEGES ON $userid.* TO '$userid'@'localhost';" echo "$userid IN A 192.168.1.3" >> /cheminconfbind/domaine.ext echo "<VirtualHost *:80> ServerAdmin webmaster@localhost ServerName $userid.domaine.ext:80 DocumentRoot /chemindossierusager/$userid/http/ <Directory /chemindossierusager/$userid/http/> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all </Directory> ErrorLog /var/log/apache2/error.$userid.log LogLevel warn CustomLog /var/log/apache2/access.$userid.log combined </VirtualHost>" >> /etc/apache2/sites-available/$userid.domaine.ext ln -s /etc/apache2/sites-available/$userid.domaine.ext /etc/apache2/sites-enabled/$userid.domaine.ext --Message édité par paulriluma le 10-12-2011 à 10:22:34-- |
|
|
|
|
|
|
Scarabée Forum : Inscrit Association : Arrivé(e) le : 19-02-2008 Nombre de messages : 561 |
donc c'est assez dangereux de le faire passer par www-data puisque il faut écrire dans divers fichiers /etc/bind /etc/passwd /etc/apache2/sites-available/ /etc/apache2/sites-enabled etc... donc bref je fais juste une expérience hein, je rassure tout le monde, je ne mets nulle part ça en libre accès quelque part... |
|
|
|
|
|
|
Hobbit  Forum : Inscrit Association : Arrivé(e) le : 31-01-2004 Nombre de messages : 1883 |
Salut, quitte à faire dans l'insécurisé, tu peux toujours lancer apache en tant que root plutôt que www-data. lol Sinon, tu peux toujours demander à root@cron de lancer régulièrement un script qui irait vérifier qu'un certain fichier/dossier serait vide, et ferait le nécessaire en cas contraire ------------------------------------- Qui ne tente rien n'a rien |
|
|
|
|
|
|
Scarabée Forum : Inscrit Association : Arrivé(e) le : 19-02-2008 Nombre de messages : 561 |
bonjour Pocrave oui je sais en fait j'ai fait quelques autres essais... infructueux... donc je me demande comment les interfaces comme alternc, openpanel panel-gzw font pour administrer un espace d'hébergement où il propose via une interface web d'administrer l'ajout d'utilisateur, le dns, apache et les virtualhost... etc... en parcourant les arborescences de dossiers de leur soft, ben y'a pas mal de scripts c ou perl... mais comme je ne suis pas développeur formé à tout ça, je patauge un peu pour comprendre comment ça marche... et donc j'arrive pas à voir comment ils font pour lancer en root des scripts sur le système tout en restant sécurisés. non parce que là effectivement, les solutions qu'on trouve sur le web communément c'est de faire le délire avec sudo et ça j'y crois pas un seul instant. par ailleurs, on m'a dit que de toute façon ce genre d'interface graphique à la gestion de système était dangereuse même dans des cas comme webmin par exemple qui parait-il a très mauvaise réputation... je sais pas hein mais bon. je fais tout ça surtout pour tenter de comprendre comment ça marche en fait. |
|
|
|
|
|
|
Naboo Forum : Modérateur Association : Arrivé(e) le : 09-04-2006 Nombre de messages : 2547 |
Bonsoir Paul, Désolé je n'ai pas eu le temps de te répondre avant. En fait, comme tu l'avais remarqué, le setuid n'a pas d'effet sur les scripts en shell. Cela s'explique par le fait qu'un script n'est pas à proprement parlé un exécutable : ce n'est pas ton script qui est exécuté mais le binaire de l'interpréteur qui se charge ensuite de réaliser les actions décrites dans le script. Le plus simple est de garder en tête que « exécuter » un script débutant par #!/bin/bash revient à écrire /bin/bash monscript.sh dans ton terminal. C'est /bin/bash qui est effectivement exécuté, pas monscript.sh (ni letiens.sh d'ailleurs). En revanche, activer le setuid sur (par exemple) /bin/bash permettrait à tes scripts d'obtenir les droits root. Mais ne fait surtout pas ça car cela serait valable pour tous les scripts exécutés avec cet interpréteur. Autrement dit, tout les scripts Bash de ta machine seraient ainsi lancé en root (et ton système ne serait même plus sûr de fonctionner correctement). On pourrait penser à copier le binaire /bin/bash a un autre endroit, activer le setuid sur la copie et utiliser celle-ci pour interpréter les seuls scripts que tu voudrais lancer en root. Cependant, il ne faut pas faire ça non plus : un interpréteur comme Bash, ne vérifie pas ce qu'il exécute ; il interprète bêtement, c'est tout. Pour lancer un script en root, il suffirait à un attaquant d'utiliser la copie setuid pour élever ses privilèges. Cette menace est réelle* et les programmes setuid doivent être sûrs. Un interpréteur qui exécute ce qu'on lui demande sans vérification n'est certainement pas sûr du tout. (* Beaucoup de programmes malveillants commencent par là : ils scannent le système à la recherche de binaires setuid à corrompre. Et on ne rappelle que trop rarement que le premier virus de l'histoire a bel et bien été écris pour attaquer UNIX.) Sudo, permet justement d'effectuer par mal de vérifications (et même un peu de nettoyage) avant de lancer un programme (au sens large) avec des privilèges élevés. Par défaut, il se contente de demander un mot de passe et de lancer la commande tapée en root si le mot de passe est correcte et génère une insulte sinon. Mais il peut aller plus loin. Il peut lancer une commande arbitraire sans mot de passe (ce que tu cherches précisément à faire). Fais tout de même attention : tu devras aller plus loin que ça ; les commandes en question ne doivent être lancées sans mot de passe que par l'utilisateur www-data et une commande peut être un binaire de ton système ou un script... c'est à toi de voir la granularité à choisir. Pourquoi justement, penses-tu qu'une solution à base de sudo ne pourrait pas marcher ou pas être sure ? Lorsqu'on cherche à obtenir une certaine sécurité, on commence généralement pas limiter les points d'entrée et la complexité des techniques (afin de toujours pouvoir les comprendre et donc anticiper les problèmes). Le rôle de sudo est précisément de gérer (i.e. d'accepter ou non) les élévations de privilèges. Sudo n'est néanmoins pas la seule solution : tu peux aussi écrire tes propres binaires (plutôt que des scripts) et les placer setuid comme bon te semble. Pocrave te propose aussi comme alternative de cloisonner complètement tes utilisateurs : un premier script s'exécute toujours en www-data et un autre toujours en root. C'est une autre manière de voir les choses et tu peux tout à fait envisager de combiner ces techniques. Mais dans tous les cas, le point clef reste le même : tu vas exécuter quelque chose avec des droits élevés. Si ton serveur web peut le faire, alors cela signifie qu'un utilisateur standard en a aussi la possibilité. C'est pourquoi tu dois faire très attention au code que tu exécute (et c'est à celui qui a les privilèges les plus élevés de vérifier que la demande est acceptable avant de la satisfaire) et être vigilant quand à l'origine de celui-ci (autrement dit, être sûr que tu as affaire à une demande légitime). Pour résumer, pour répondre à ton besoin, tu dois : - avoir un mécanisme d'exécution de demandes avec les privilèges root (que ce soit avec sudo ou en faisant communiquer deux scripts/processus distincts) ; - savoir contrôler ce que tu exécutes et refuser tout ce qui n'est pas attendu ; - être capable de tracer l'origine des actions d'administration demandées. --Message édité par Azollyx le 12-12-2011 à 20:31:04-- ------------------------------------- Tu as envie de t'impliquer ? Avec ton aide et tes compétences (je te vois, sourire... tu te sous-estimes !) nous pourrons bâtir la communauté Trustonme. Tu ne sais pas par où commencer ? Viens faire un tour dans la catégorie Association Trustonme. |
|
|
|
|
|
|
Scarabée Forum : Inscrit Association : Arrivé(e) le : 19-02-2008 Nombre de messages : 561 |
ah ! merci Azolyx de ces explications précises. là je comprends un peu mieux mais va falloir que je creuse à partir de là bien-sûr. bon j'ai aussi pensé à me mettre au c pour écrire un binaire. j'ai aussi pensé à perl, qui semble plus facile. mais suis pas sûr que ce soit mieux que php et bash dans ce cas. moi aussi au début j'ai pensé que si je limitais l'utilisation de sudo pour www-data uniquement sur ce script, ça serait déjà un peu sécurisé. sauf que voilà, dans le script y'a useradd qui donne donc la possibilité de mettre des usagers sur le système. donc je trouve ça dangereux. j'ai aussi lu les avertissements indiqués par l'auteur de l'article que je cite précédemment et qui lui propose de faire un "wrapper" en c ou en perl. mais j'avais pas compris aussi la nuance de taille à propos du bit setuid et du fonctionnement de bash. bon en tout cas ça me fait avancer merci beaucoup. en gros il vaudrait mieux que je me fabrique une petite application en perl et qui ne passe pas par www-data donc apache. je vais suivre cette piste pour me documenter sur perl. j'ai cru comprendre qu'au départ ce langage avait été conçu pour ce genre de besoin. je fais peut-être fausse route. |
|
|
|
|
|
|
Scarabée Forum : Inscrit Association : Arrivé(e) le : 19-02-2008 Nombre de messages : 561 |
euh... en repensant à comment j'ai compris qu'un script perl commence par #!/usr/bin/perl je suppose que ça va fonctionner comme bash ! donc c'est pas la peine que je cherche à résoudre mon projet avec perl je suppose ! donc y'a plus qu'à se mettre au c et apprendre à rédiger un truc qui ne soit utilisable que par root donc commence par une fenêtre de login/password comme quand on lance n'importe qu'elle application d'administration sous gnome... --Message édité par paulriluma le 13-12-2011 à 20:20:47-- |
|
|
|
|
|
|
Naboo Forum : Modérateur Association : Arrivé(e) le : 09-04-2006 Nombre de messages : 2547 |
Ne donner les droits d'exécution qu'à l'utilisateur/group souhaité n'est pas adapté selon toi ?
Dans tous les cas, tu cherches précisément à permettre à un utilisateur d'administrer ton système. J'ai l'impression que l'objectif que tu poursuis te dérange en lui-même : d'un côté tu veux permettre à www-data d'utiliser la commande useradd et de l'autre, tu ne veux pas qu'il puisse créer des utilisateurs. Tu ne t'en rends peut être pas encore compte, mais que tu fasses ça avec sudo, en C ou en Perl, tu auras le même problème. Il est inhérent à ton besoin. C'est pour cela que je t'ai parlé des problèmatiques complémentaires à l'élévation des privilèges elle-même.
Pour dire les choses autrement, tu veux mettre en place quelque chose qui n'est par essence pas sûr. Tu dois donc concevoir et garantir « toi-même » la sécurité de ton système. --Message édité par Azollyx le 13-12-2011 à 22:16:38-- ------------------------------------- Tu as envie de t'impliquer ? Avec ton aide et tes compétences (je te vois, sourire... tu te sous-estimes !) nous pourrons bâtir la communauté Trustonme. Tu ne sais pas par où commencer ? Viens faire un tour dans la catégorie Association Trustonme. |
|
|
|
|
|
|
Scarabée Forum : Inscrit Association : Arrivé(e) le : 19-02-2008 Nombre de messages : 561 |
wouai... je vois mieux effectivement oui je voulais pas que ce soit www-data qui puisse lancer effectivement useradd par exemple mais je ne voulais pas que ce soit récupérable par un intrus par l'intermédiaire de www-data et le net, donc faire une entrée obligatoire par l'intermédiaire d'un test sur root donc jusqu'ici je me suis toujours fait des script bash que je lance en root. ( là par exemple le script indiqué est d'ailleurs incomplet puisque je n'y ai pas mis les vérifications que je fais sur l'existence préalable du login de l'utilisateur, la longueur mini et maxi du login, son contenu en caractères autorisés, et la longueur minimale du mot de passe) là je voulais me faire une interface graphique conviviale, mais en le faisant je me suis dit que c'était récupérable par n'importe quel intrus. en bref, je voulais me faire une interface graphique privée : c'est uniquement l'administrateur de la machine qui peux y avoir accès. si je fais passer ça par httpd, ben c'est pas sûr voilà ce que je me suis dit. |
|
|
|
|
|
|
Naboo Forum : Modérateur Association : Arrivé(e) le : 09-04-2006 Nombre de messages : 2547 |
Mais que dirais-tu de protéger ton interface graphique par une authentification ? ------------------------------------- Tu as envie de t'impliquer ? Avec ton aide et tes compétences (je te vois, sourire... tu te sous-estimes !) nous pourrons bâtir la communauté Trustonme. Tu ne sais pas par où commencer ? Viens faire un tour dans la catégorie Association Trustonme. |
|
|
|
|
|
|
Scarabée Forum : Inscrit Association : Arrivé(e) le : 19-02-2008 Nombre de messages : 561 |
oui c'est ce que je veux faire c'est pour ça que j'indiquais l'exemple des interfaces graphiques d'administration système qu'on a dans gnome par exemple. donc j'ai bien pensé au départ faire un truc classique de session php, mais ensuite j'ai lu des articles disant que de faire ce genre de truc par l'intermédiaire de httpd c'était dangereux etc... donc j'ai cherché ailleurs bon de toute façon, une commande comme useradd refuse de fonctionner si l'usager n'est pas root dans les scripts que j'ai tenté. donc ce qu'il faudrait que je fasse c'est effectivement un contrôle de l'identité de l'usager pour que ce soit uniquement root qui puisse lancer le programme. dans tous les cas, y'a un moment où j'ai une instruction su qui demande donc un mot de passe je me suis demandé donc comment renvoyer cette demande d'un script bash vers une interface graphique qui va recevoir la réponse attendue et la repasser au script bash en attente... euh... j'ai aussi cherché comment enregistrer le mot de passe root en prévision de la demande de su etc... vois pas très bien comment faire... je patauge... |
|
|
|
|
|
|
Naboo Forum : Modérateur Association : Arrivé(e) le : 09-04-2006 Nombre de messages : 2547 |
Vas-y progressivement : commence par mettre en place un premier système, même s'il n'est pas sûr. Tu l'amélioreras ensuite. Tu fais ça « pour voir ». De ce fait, ce qui t'importe ici, c'est essentiellement ce que t'aura apporté ton expérience. ------------------------------------- Tu as envie de t'impliquer ? Avec ton aide et tes compétences (je te vois, sourire... tu te sous-estimes !) nous pourrons bâtir la communauté Trustonme. Tu ne sais pas par où commencer ? Viens faire un tour dans la catégorie Association Trustonme. |
|
|
|
|
|
|
Scarabée Forum : Inscrit Association : Arrivé(e) le : 19-02-2008 Nombre de messages : 561 |
tout à fait bon ben tiens un élément qui me pose problème dans mon premier système ej teste la conformité des login avec une expression régulière dans un script php et ça marchait je veux refaire tout ça en bash je veux tester l'existance de tout ce qui n'est pas A-Za-z en bash donc j'ai fait une expression [!A-Za-z] j'ai utilisé ça comme ça : if expr "$login" : "[!A-Za-z]" ben quand je met un lgogin du genre làçé il me le rejette : super mais quand je mets un login du genre $*ù!@ avec plein de caractères bizares, il me les laisse passer comme si c'était des lettres ordinaires donc j'ai pas trouvé la bonne expression ou mal utilisé expr une idée ? |
|
|
|
|
|
|
Scarabée Forum : Inscrit Association : Arrivé(e) le : 19-02-2008 Nombre de messages : 561 |
bon pour ce dernier problème d'expression régulière et d'utilisation de expr... ben j'ai pas compris pourquoi et comment utilisé ça mais j'ai trouvé une solution avec sed car=`echo "$login" | sed -e 's/[-abcdefghijklmnopqrstuvwxyz0123456789]*//g'` echo "les caractères nonautorisés sont : $car" if [ "$car" != "" ] then echo "login inacceptable" else echo "login accepté" fi c'est sûrement pas élégant, mais là au moins il ne laisse passer que les login composés comme je le veux... |
|
|
 |
| Page : [1] 2 |
Forum » Serveur, Réseaux et Programmation » script bash root lancé par php et serveur web |
Forum modéré par : jblecanard |
| Même auteur |
|
Score ( voter ) : |
|
- Petit scarabée : 0 pastille, moins de 100 messages
- Scarabée : 0 pastille, plus de 100 messages
- Hobbit : 1 pastille, plus de 1000 messages
- Naboo : 2 pastilles, plus de 2000 messages
- Elfe : 3 pastilles, plus de 3000 messages
- Jedi : 4 pastilles, plus de 4000 messages
- Maître Jedi : 5 pastilles, plus de 5000 messages