Je tente de m'intéresser de plus près au mode taint. J'ai pour l'instant
lu <http://gunther.web66.com/FAQS/taintmode.html#what> et si
unitairement chaque chose semble claire, la révision globale d'un long
script me semble complexe (parce qu'il s'agit de déterminer les cas
menant à une conjonction de caractéristiques qui, ensemble, rendent tel
ou tel point 'unsafe' ; parce que c'est une vérif au runtime si j'ai
bien compris et que ce n'est pas forcément facile d'éxécuter un script
par tous les chemins possibles et imaginables).
Bref, existe-il un outil, une sorte de "Taint Validator" qui aiderait à
traquer les éléments sensibles d'un script ?
En dehors de ça, ajouter le "-T", ça, c'est facile.
Je tente de m'intéresser de plus près au mode taint. J'ai pour l'instant lu <http://gunther.web66.com/FAQS/taintmode.html#what> et si unitairement chaque chose semble claire, la révision globale d'un long script me semble complexe (parce qu'il s'agit de déterminer les cas menant à une conjonction de caractéristiques qui, ensemble, rendent tel ou tel point 'unsafe' ; parce que c'est une vérif au runtime si j'ai bien compris et que ce n'est pas forcément facile d'éxécuter un script par tous les chemins possibles et imaginables).
Si le script est bien structuré, les choses sont plus faciles à faire :
- Les points d'entrée de données externes sont facilement localisables et c'est là (au plus tôt) que ces données doivent être vérifiées.
- Pour les commandes externes, il faut nettoyer le PATH et, dans la mesure du possible, utiliser les syntaxes évitant le passage par le shell.
Bref, existe-il un outil, une sorte de "Taint Validator" qui aiderait à traquer les éléments sensibles d'un script ?
En dehors de ça, ajouter le "-T", ça, c'est facile.
Le "Taint Validator", c'est l'option "-T". Il me semble utopique d'envisager un "Taint Validator" statique. Il faut donc créer des tests de couverture.
Vous pouvez lire 'perlsec'. En français, récemment mis à jour :
<http://perl.enstimac.fr/DocFr/perlsec.html>
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Je tente de m'intéresser de plus près au mode taint. J'ai pour l'instant
lu <http://gunther.web66.com/FAQS/taintmode.html#what> et si
unitairement chaque chose semble claire, la révision globale d'un long
script me semble complexe (parce qu'il s'agit de déterminer les cas
menant à une conjonction de caractéristiques qui, ensemble, rendent tel
ou tel point 'unsafe' ; parce que c'est une vérif au runtime si j'ai
bien compris et que ce n'est pas forcément facile d'éxécuter un script
par tous les chemins possibles et imaginables).
Si le script est bien structuré, les choses sont plus faciles à
faire :
- Les points d'entrée de données externes sont facilement
localisables et c'est là (au plus tôt) que ces données doivent
être vérifiées.
- Pour les commandes externes, il faut nettoyer le PATH et, dans
la mesure du possible, utiliser les syntaxes évitant le passage
par le shell.
Bref, existe-il un outil, une sorte de "Taint Validator" qui aiderait à
traquer les éléments sensibles d'un script ?
En dehors de ça, ajouter le "-T", ça, c'est facile.
Le "Taint Validator", c'est l'option "-T". Il me semble utopique
d'envisager un "Taint Validator" statique. Il faut donc créer des
tests de couverture.
Vous pouvez lire 'perlsec'. En français, récemment mis à jour :
<http://perl.enstimac.fr/DocFr/perlsec.html>
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
Je tente de m'intéresser de plus près au mode taint. J'ai pour l'instant lu <http://gunther.web66.com/FAQS/taintmode.html#what> et si unitairement chaque chose semble claire, la révision globale d'un long script me semble complexe (parce qu'il s'agit de déterminer les cas menant à une conjonction de caractéristiques qui, ensemble, rendent tel ou tel point 'unsafe' ; parce que c'est une vérif au runtime si j'ai bien compris et que ce n'est pas forcément facile d'éxécuter un script par tous les chemins possibles et imaginables).
Si le script est bien structuré, les choses sont plus faciles à faire :
- Les points d'entrée de données externes sont facilement localisables et c'est là (au plus tôt) que ces données doivent être vérifiées.
- Pour les commandes externes, il faut nettoyer le PATH et, dans la mesure du possible, utiliser les syntaxes évitant le passage par le shell.
Bref, existe-il un outil, une sorte de "Taint Validator" qui aiderait à traquer les éléments sensibles d'un script ?
En dehors de ça, ajouter le "-T", ça, c'est facile.
Le "Taint Validator", c'est l'option "-T". Il me semble utopique d'envisager un "Taint Validator" statique. Il faut donc créer des tests de couverture.
Vous pouvez lire 'perlsec'. En français, récemment mis à jour :
<http://perl.enstimac.fr/DocFr/perlsec.html>
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Asterbing
In article , says...
Si le script est bien structuré, les choses sont plus faciles à faire :
- Les points d'entrée de données externes sont facilement localisables et c'est là (au plus tôt) que ces données doivent être vérifiées.
OK, c'est le cas, il y a cinq points d'entrée possible venant de formulaires ou fichiers générés par autres softs. Je vais donc commencer à focaliser là-dessus.
- Pour les commandes externes, il faut nettoyer le PATH et, dans la mesure du possible, utiliser les syntaxes évitant le passage par le shell.
Juste un appel sendmail dans tout le script.
Le "Taint Validator", c'est l'option "-T". Il me semble utopique d'envisager un "Taint Validator" statique. Il faut donc créer des tests de couverture.
Bon, j'ai donc, à vue de nez, une vingtaine de passages à faire.
Vous pouvez lire 'perlsec'. En français, récemment mis à jour : <http://perl.enstimac.fr/DocFr/perlsec.html>
OK, bookmarké, merci Paul.
Bon, sinon deux questions en sus :
1) Est-il bien de laisser le mode taint sur le script final ou vaut-il mieux le retirer une fois bien testé en tous sens (par exemple parce que ça ralentirait le script et chargerait la machine) ?
2) Est-ce qu'un unlink sur un fichier temporaire est considéré comme unsafe ?
In article <r7zmj2531f.fsf@vaugirard.enstimac.fr>,
Paul.Gaborit@invalid.invalid says...
Si le script est bien structuré, les choses sont plus faciles à
faire :
- Les points d'entrée de données externes sont facilement
localisables et c'est là (au plus tôt) que ces données doivent
être vérifiées.
OK, c'est le cas, il y a cinq points d'entrée possible venant de
formulaires ou fichiers générés par autres softs. Je vais donc commencer
à focaliser là-dessus.
- Pour les commandes externes, il faut nettoyer le PATH et, dans
la mesure du possible, utiliser les syntaxes évitant le passage
par le shell.
Juste un appel sendmail dans tout le script.
Le "Taint Validator", c'est l'option "-T". Il me semble utopique
d'envisager un "Taint Validator" statique. Il faut donc créer des
tests de couverture.
Bon, j'ai donc, à vue de nez, une vingtaine de passages à faire.
Vous pouvez lire 'perlsec'. En français, récemment mis à jour :
<http://perl.enstimac.fr/DocFr/perlsec.html>
OK, bookmarké, merci Paul.
Bon, sinon deux questions en sus :
1) Est-il bien de laisser le mode taint sur le script final ou vaut-il
mieux le retirer une fois bien testé en tous sens (par exemple parce que
ça ralentirait le script et chargerait la machine) ?
2) Est-ce qu'un unlink sur un fichier temporaire est considéré comme
unsafe ?
Si le script est bien structuré, les choses sont plus faciles à faire :
- Les points d'entrée de données externes sont facilement localisables et c'est là (au plus tôt) que ces données doivent être vérifiées.
OK, c'est le cas, il y a cinq points d'entrée possible venant de formulaires ou fichiers générés par autres softs. Je vais donc commencer à focaliser là-dessus.
- Pour les commandes externes, il faut nettoyer le PATH et, dans la mesure du possible, utiliser les syntaxes évitant le passage par le shell.
Juste un appel sendmail dans tout le script.
Le "Taint Validator", c'est l'option "-T". Il me semble utopique d'envisager un "Taint Validator" statique. Il faut donc créer des tests de couverture.
Bon, j'ai donc, à vue de nez, une vingtaine de passages à faire.
Vous pouvez lire 'perlsec'. En français, récemment mis à jour : <http://perl.enstimac.fr/DocFr/perlsec.html>
OK, bookmarké, merci Paul.
Bon, sinon deux questions en sus :
1) Est-il bien de laisser le mode taint sur le script final ou vaut-il mieux le retirer une fois bien testé en tous sens (par exemple parce que ça ralentirait le script et chargerait la machine) ?
2) Est-ce qu'un unlink sur un fichier temporaire est considéré comme unsafe ?
Vous appelez 'sendmail' directement ! En général, on évite... On préfère des solutions plus modulaires....
Bon, sinon deux questions en sus :
1) Est-il bien de laisser le mode taint sur le script final ou vaut-il mieux le retirer une fois bien testé en tous sens (par exemple parce que ça ralentirait le script et chargerait la machine) ?
Le "ralentissement" est minime sauf si vous traitez de très grosses quantités d'information. L'intérêt de le laisser se verra le jour où il bloquera quelque chose... Le signe que vos tests de couvertures n'étaient pas complets ;-)
Ceci étant, le 'taint mode' ne garantit rien. C'est comme la preuve par 9 : quand ça plante, c'est qu'il y a une erreur. Quand ça ne plante pas, c'est peut-être que l'erreur n'est pas détectable par le 'taint mode'. ;-)
2) Est-ce qu'un unlink sur un fichier temporaire est considéré comme unsafe ?
'unlink' est cité dans les exemples de 'perlsec'. Si les chemins sont 'safe', le 'unlink' l'est. Si c'est un fichier temporaire, c'est que votre script l'a créé et donc que le chemin a déjà été considéré comme 'safe'...
Encore une fois, cela ne prouve pas que la création de votre fichier temporaire est réellement 'safe'.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Vous appelez 'sendmail' directement ! En général, on évite... On
préfère des solutions plus modulaires....
Bon, sinon deux questions en sus :
1) Est-il bien de laisser le mode taint sur le script final ou vaut-il
mieux le retirer une fois bien testé en tous sens (par exemple parce que
ça ralentirait le script et chargerait la machine) ?
Le "ralentissement" est minime sauf si vous traitez de très grosses
quantités d'information. L'intérêt de le laisser se verra le jour où
il bloquera quelque chose... Le signe que vos tests de couvertures
n'étaient pas complets ;-)
Ceci étant, le 'taint mode' ne garantit rien. C'est comme la preuve
par 9 : quand ça plante, c'est qu'il y a une erreur. Quand ça ne
plante pas, c'est peut-être que l'erreur n'est pas détectable par le
'taint mode'. ;-)
2) Est-ce qu'un unlink sur un fichier temporaire est considéré comme
unsafe ?
'unlink' est cité dans les exemples de 'perlsec'. Si les chemins sont
'safe', le 'unlink' l'est. Si c'est un fichier temporaire, c'est que
votre script l'a créé et donc que le chemin a déjà été considéré comme
'safe'...
Encore une fois, cela ne prouve pas que la création de votre fichier
temporaire est réellement 'safe'.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
Vous appelez 'sendmail' directement ! En général, on évite... On préfère des solutions plus modulaires....
Bon, sinon deux questions en sus :
1) Est-il bien de laisser le mode taint sur le script final ou vaut-il mieux le retirer une fois bien testé en tous sens (par exemple parce que ça ralentirait le script et chargerait la machine) ?
Le "ralentissement" est minime sauf si vous traitez de très grosses quantités d'information. L'intérêt de le laisser se verra le jour où il bloquera quelque chose... Le signe que vos tests de couvertures n'étaient pas complets ;-)
Ceci étant, le 'taint mode' ne garantit rien. C'est comme la preuve par 9 : quand ça plante, c'est qu'il y a une erreur. Quand ça ne plante pas, c'est peut-être que l'erreur n'est pas détectable par le 'taint mode'. ;-)
2) Est-ce qu'un unlink sur un fichier temporaire est considéré comme unsafe ?
'unlink' est cité dans les exemples de 'perlsec'. Si les chemins sont 'safe', le 'unlink' l'est. Si c'est un fichier temporaire, c'est que votre script l'a créé et donc que le chemin a déjà été considéré comme 'safe'...
Encore une fois, cela ne prouve pas que la création de votre fichier temporaire est réellement 'safe'.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Asterbing
In article , says...
Le "ralentissement" est minime sauf si vous traitez de très grosses quantités d'information. L'intérêt de le laisser se verra le jour où il bloquera quelque chose... Le signe que vos tests de couvertures n'étaient pas complets ;-)
Hum, oui, mais justement j'y reviens : en matière de couverture, n'existe-t-il pas de soft d'analyse tels que ceux que l'on trouve pour C et C++ : par exemple chez Numega et Rose ?
In article <r7vetq4mt9.fsf@vaugirard.enstimac.fr>,
Paul.Gaborit@invalid.invalid says...
Le "ralentissement" est minime sauf si vous traitez de très grosses
quantités d'information. L'intérêt de le laisser se verra le jour où
il bloquera quelque chose... Le signe que vos tests de couvertures
n'étaient pas complets ;-)
Hum, oui, mais justement j'y reviens : en matière de couverture,
n'existe-t-il pas de soft d'analyse tels que ceux que l'on trouve pour C
et C++ : par exemple chez Numega et Rose ?
Le "ralentissement" est minime sauf si vous traitez de très grosses quantités d'information. L'intérêt de le laisser se verra le jour où il bloquera quelque chose... Le signe que vos tests de couvertures n'étaient pas complets ;-)
Hum, oui, mais justement j'y reviens : en matière de couverture, n'existe-t-il pas de soft d'analyse tels que ceux que l'on trouve pour C et C++ : par exemple chez Numega et Rose ?
Emmanuel Florac
Le Mon, 03 Apr 2006 21:46:42 +0200, Asterbing a écrit :
Hum, oui, mais justement j'y reviens : en matière de couverture, n'existe-t-il pas de soft d'analyse tels que ceux que l'on trouve pour C et C++ : par exemple chez Numega et Rose ?
Il y a les modules Test::More et Devel::Cover. En pratique, tu écris un script de test qui utilise Test::More, et tu le lances en utilisant Devel::Cover, qui va générer un rapport ultra-détaillé sur la couverture du code.
-- Le commissaire : Comment vous appelez-vous? Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut vous intéresser. Prévert,"les enfants du Paradis".
Le Mon, 03 Apr 2006 21:46:42 +0200, Asterbing a écrit :
Hum, oui, mais justement j'y reviens : en matière de couverture,
n'existe-t-il pas de soft d'analyse tels que ceux que l'on trouve pour C
et C++ : par exemple chez Numega et Rose ?
Il y a les modules Test::More et Devel::Cover. En pratique, tu écris un
script de test qui utilise Test::More, et tu le lances en utilisant
Devel::Cover, qui va générer un rapport ultra-détaillé sur la
couverture du code.
--
Le commissaire : Comment vous appelez-vous?
Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas
besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut
vous intéresser.
Prévert,"les enfants du Paradis".
Le Mon, 03 Apr 2006 21:46:42 +0200, Asterbing a écrit :
Hum, oui, mais justement j'y reviens : en matière de couverture, n'existe-t-il pas de soft d'analyse tels que ceux que l'on trouve pour C et C++ : par exemple chez Numega et Rose ?
Il y a les modules Test::More et Devel::Cover. En pratique, tu écris un script de test qui utilise Test::More, et tu le lances en utilisant Devel::Cover, qui va générer un rapport ultra-détaillé sur la couverture du code.
-- Le commissaire : Comment vous appelez-vous? Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut vous intéresser. Prévert,"les enfants du Paradis".
Asterbing
In article , says...
Le Mon, 03 Apr 2006 21:46:42 +0200, Asterbing a écrit :
Hum, oui, mais justement j'y reviens : en matière de couverture, n'existe-t-il pas de soft d'analyse tels que ceux que l'on trouve pour C et C++ : par exemple chez Numega et Rose ?
Il y a les modules Test::More et Devel::Cover. En pratique, tu écris un script de test qui utilise Test::More, et tu le lances en utilisant Devel::Cover, qui va générer un rapport ultra-détaillé sur la couverture du code.
OK, merci Emmanuel.
In article <pan.2006.04.03.19.58.53.729944@imaginet.fr>,
eflorac@imaginet.fr says...
Le Mon, 03 Apr 2006 21:46:42 +0200, Asterbing a écrit :
Hum, oui, mais justement j'y reviens : en matière de couverture,
n'existe-t-il pas de soft d'analyse tels que ceux que l'on trouve pour C
et C++ : par exemple chez Numega et Rose ?
Il y a les modules Test::More et Devel::Cover. En pratique, tu écris un
script de test qui utilise Test::More, et tu le lances en utilisant
Devel::Cover, qui va générer un rapport ultra-détaillé sur la
couverture du code.
Le Mon, 03 Apr 2006 21:46:42 +0200, Asterbing a écrit :
Hum, oui, mais justement j'y reviens : en matière de couverture, n'existe-t-il pas de soft d'analyse tels que ceux que l'on trouve pour C et C++ : par exemple chez Numega et Rose ?
Il y a les modules Test::More et Devel::Cover. En pratique, tu écris un script de test qui utilise Test::More, et tu le lances en utilisant Devel::Cover, qui va générer un rapport ultra-détaillé sur la couverture du code.
