EB> Le mercredi 22 octobre, Philippe Beau a écrit :
>> un daemon fonctionnant sur la machine va ecouter les informations qui
>> proviennent de /tmp/secure/toto.sock et faire une action en
>> conséquence. je suis plus clair ?
EB> Et Frédéric Mantegazza a répondu :
>> Dans ton exemple, tu n'utilises pas les sockets, mais soit un fichier,
>> soit un pipe nomme. C'est different. Est-ce bien ce que tu veux ?
EB> Pourquoi tu dis ça ? /tmp/secure/toto.sock peut très bien être un socket
EB> Unix. Les sockets Unix, tout comme les pipes nommés, ont une entrée dans
EB> le système de fichiers. En fait les sockets Unix ressemblent beaucoup
EB> aux pipes nommés sauf que :
EB> - ils sont bidirectionnels ;
EB> - plusieurs clients peuvent se connecter indépendamment au même
EB> socket ;
EB> - ça utilise l'API socket.
ca me plait !!!!
EB> Philippe :
>> je veux faire transiter des infos d'un programme a l'autre, sur une
>> machine en LOCAL. Donc le souci du socket, c'est que ca ouvre un port,
>> meme si c'est sur l'interface lo, je pense que c'est dangereux, qu'en
>> penses-tu ?
EB> Les sockets Unix n'ouvrent pas de ports. L'exemple que t'a donné
EB> Frédéric utilise un socket Internet qui, contrairement à un socket Unix,
EB> ouvre un port sur la machine. Ceci dit, si le port est ouvert uniquement
EB> sur lo, c'est aussi sûr qu'un socket Unix. C'est juste moins efficace
EB> car tu passes inutilement à travers la pile TCP/IP du système.
EB> Frédéric :
>> Ceci-dit, je ne suis pas sur que tout ca soit le solution la plus simple. A
>> mon avis, executer un petit script qui a les droits suid, et qui lui-meme
>> va lancer les commandes voulues peut-etre suffisant. Mais *attention*:
>> reflechis bien a ce que tu fais, car c'est la porte ouverte a des failles
>> de securite !!!
EB> Je suis d'accord.
EB> Et Philippe :
>> c'est pour ca que je me creuse la tete entre les sockets et toutes les
>> autres versions possibles !
EB> Ça ne change pas grand chose au niveau sécurité. Le script PHP en suid
EB> root est dangereux car il traite des données venues de l'extérieur. Du
EB> coup s'il est mal codé il peut se laisser abuser par ces données et
EB> faire des choses qu'il ne devrait pas faire. Le serveur suid root que tu
EB> envisages est dangereux car il traite des données venues de l'extérieur.
EB> Du coup s'il est mal codé il peut se laisser abuser par ces données et
EB> faire des choses qu'il ne devrait pas faire.
EB> Ton serveur peut peut-être améliorer la sécurité en isolant les tâches à
EB> faire sous root des autres => moins de choses suid root, moins de risque
EB> de bogues. Mais tu peux peut-être faire cette séparation des tâches en
EB> PHP : un script qui appelle un autre suid root, lequel fait juste ce
EB> qu'il faut faire sous root.
EB> Moralité : il faut surtout bien penser à valider toutes les données que
EB> tu reçois avant de faire quoi que ce soit avec. L'option -T (taint) de
EB> Perl est pratique pour t'aider à vérifier que tu n'as rien oublié.
EB> Pour ce qui est des sockets Unix : j'ai codé un système client-serveur
EB> qui les utilise. C'était surtout pour avoir deux « threads » de mon
EB> application avec espaces d'adressage séparés (ce sont donc des
EB> processus...). Le serveur est suid root et temps réél : il doit mettre à
EB> jour le champ magnétique de ma manip toutes le millisecondes. Le client
EB> n'a pas ce genre de contraintes de temps. Si ça t'intéresse je peux
EB> t'envoyer ça, mais ce n'est pas très différent des sockets Internet pour
EB> lesqueles Frédéric t'a envoyé un exemple.
EB> Edgar.
il est hors de question que le serveur web soit suid root !!!!!
je veux un canal de communication entre les 2 processus (serveur web
et script) qui passe par un fichier comme le décrit Edgar, et qui me
permette de faire les opérations en temps réel. En temps décalé, je
peux le faire avec une base mysql par exemple (le serveur web ecrit
dans la base, le script va chercher dans la base) mais j'aimerais
supprimer ce problème de sécurité qu'est mysql.
--
Cordialement,
Philippe Courriel : philippe@???
