Nous avons deux disques USB "My Passport" d'un To (modèles WDBACX0010BBL
et WDBACX0010BRD). J'ai une question sur le fonctionnement des buffers
disques.
Avec l'un ou l'autre disque, monté en ntfs-g3, je lance plusieurs fois la
commande suivante :
# time tar -C $repertoire_disque -c ./ > /dev/null
La 1ère fois, elle met environ 1'10" à se terminer
Un coup d'oeil sur le site de WDt me dit que le taux de transfert peut
atteindre 480Mo/s en USB-2, ce qui est le cas de mon système.
Déjà là, on dépasse la vitesse théorique de 50% !
Mais la 2ème fois, la commande prend 12", à la 3ème 5,2", puis 4.7", etc.
La comande du se comporte de la même manière ; 1'8" puis 3.7" en
enchaînant les appels avec un disque; mais 53" puis 13" avec l'autre.
Je n'ai que 2Go de RAM, il est impossible que les données des disques
soient bufferisées là. Quelqu'un pourrait me dire si cette évolution des
temps de transfert est normale et à quoi elle est dûe dans ce cas ?
Non, mais il permet de faire : je trouve une archive, je la télécharge, je la décompresse, je clique sur un truc qui est un exécutable mais j'avais pas vu, ça ne me le lance pas.
Je trouve que ça devient très capilotracté. D'autant que tu peux obtenir le même effet en utilisant une extension qui sera reconnue comme un script dans un langage qui permet de faire des appels système ou d'exécuter des commandes externes. Sur certains systèmes, un simple fichier .tex peut faire ça.
la procédure habituelle n'étant pas de télécharger des programmes venus de nulle part comme ça (oui, ça dépend de ton utilisation bien sûr).
La procédure habituelle, on ne sait pas ce que c'est. D'ailleurs, si on va dans cette direction : la procédure habituelle n'est pas de lancer des programmes en cliquant sur leur exécutable : les exécutables sont rangés dans /bin et on les lance en passant par leur entrée de menu (ou en ligne de commande, mais ce n'est pas de ça qu'on parle).
Donc s'il y a un problème dans ce que tu décris, c'est dans le fait que l'interface graphique permette d'exécuter des choses aussi facilement, pas dans le fait que le noyau ne l'en empêche pas.
Yliur , dans le message <20111124121300.22b1d31f@alcheringa>, a écrit :
Non, mais il permet de faire : je trouve une archive, je la télécharge,
je la décompresse, je clique sur un truc qui est un exécutable mais
j'avais pas vu, ça ne me le lance pas.
Je trouve que ça devient très capilotracté. D'autant que tu peux obtenir le
même effet en utilisant une extension qui sera reconnue comme un script dans
un langage qui permet de faire des appels système ou d'exécuter des
commandes externes. Sur certains systèmes, un simple fichier .tex peut faire
ça.
la procédure habituelle n'étant pas de télécharger
des programmes venus de nulle part comme ça (oui, ça dépend de ton
utilisation bien sûr).
La procédure habituelle, on ne sait pas ce que c'est. D'ailleurs, si on va
dans cette direction : la procédure habituelle n'est pas de lancer des
programmes en cliquant sur leur exécutable : les exécutables sont rangés
dans /bin et on les lance en passant par leur entrée de menu (ou en ligne de
commande, mais ce n'est pas de ça qu'on parle).
Donc s'il y a un problème dans ce que tu décris, c'est dans le fait que
l'interface graphique permette d'exécuter des choses aussi facilement, pas
dans le fait que le noyau ne l'en empêche pas.
Non, mais il permet de faire : je trouve une archive, je la télécharge, je la décompresse, je clique sur un truc qui est un exécutable mais j'avais pas vu, ça ne me le lance pas.
Je trouve que ça devient très capilotracté. D'autant que tu peux obtenir le même effet en utilisant une extension qui sera reconnue comme un script dans un langage qui permet de faire des appels système ou d'exécuter des commandes externes. Sur certains systèmes, un simple fichier .tex peut faire ça.
la procédure habituelle n'étant pas de télécharger des programmes venus de nulle part comme ça (oui, ça dépend de ton utilisation bien sûr).
La procédure habituelle, on ne sait pas ce que c'est. D'ailleurs, si on va dans cette direction : la procédure habituelle n'est pas de lancer des programmes en cliquant sur leur exécutable : les exécutables sont rangés dans /bin et on les lance en passant par leur entrée de menu (ou en ligne de commande, mais ce n'est pas de ça qu'on parle).
Donc s'il y a un problème dans ce que tu décris, c'est dans le fait que l'interface graphique permette d'exécuter des choses aussi facilement, pas dans le fait que le noyau ne l'en empêche pas.
Nicolas George
Hugues , dans le message , a écrit :
Pour /var/run, ok, mais pour /var/lock ?
Je ne pense à rien qui mérite de rester d'un boot à l'autre dans /var/lock, et il me semble que certaines distributions nettoient /var/lock au boot au même titre que /var/run, donc je pense que tu ne cours vraiment aucun risque.
Hugues , dans le message <87pqgh4wev.fsf@paranoid.sweethome>, a écrit :
Pour /var/run, ok, mais pour /var/lock ?
Je ne pense à rien qui mérite de rester d'un boot à l'autre dans /var/lock,
et il me semble que certaines distributions nettoient /var/lock au boot au
même titre que /var/run, donc je pense que tu ne cours vraiment aucun
risque.
Je ne pense à rien qui mérite de rester d'un boot à l'autre dans /var/lock, et il me semble que certaines distributions nettoient /var/lock au boot au même titre que /var/run, donc je pense que tu ne cours vraiment aucun risque.
Hugues
Ce cher Nicolas George <nicolas$ a posté :
Hugues , dans le message , a écrit :
Pour /var/run, ok, mais pour /var/lock ?
Je ne pense à rien qui mérite de rester d'un boot à l'autre dans /var/lock, et il me semble que certaines distributions nettoient /var/lock au boot au même titre que /var/run,
En principe. :-)
donc je pense que tu ne cours vraiment aucun risque.
Ok, merci de ton avis !
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Ce cher Nicolas George <nicolas$george@salle-s.org> a posté :
Hugues , dans le message <87pqgh4wev.fsf@paranoid.sweethome>, a écrit :
Pour /var/run, ok, mais pour /var/lock ?
Je ne pense à rien qui mérite de rester d'un boot à l'autre dans /var/lock,
et il me semble que certaines distributions nettoient /var/lock au boot au
même titre que /var/run,
En principe. :-)
donc je pense que tu ne cours vraiment aucun risque.
Je ne pense à rien qui mérite de rester d'un boot à l'autre dans /var/lock, et il me semble que certaines distributions nettoient /var/lock au boot au même titre que /var/run,
En principe. :-)
donc je pense que tu ne cours vraiment aucun risque.
Ok, merci de ton avis !
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
JKB
Le Thu, 24 Nov 2011 00:01:15 +0100, NiKo écrivait :
Le 23/11/2011 23:23, Nicolas George a écrit :
NiKo , dans le message <4ecd6966$0$27879$, a écrit :
Quelle bande de bras cassés tous ces gars qui se servent de /dev/shm !
Là, clairement bras cassé. Allez, les plus flagrantes.
* « Je ne saurais trop vous conseillez », « tmpfs est trés simple à utliser et peux »... no comment.
* Monter /tmp en noexec : merci pour les ./configure qui y font des tests de compilation et d'exécution.
Quel est le rapport avec /dev/shm ? Parce qu'il y a des fautes d'orthographe ? Surement que les gens qui sont derrière Arch ou Gentoo sont des bras cassés à coté de Monsieur George !
J'aimerais aussi savoir quel script configure se permet d'aller écrire dans /tmp pour effectuer des tests. L'intérêt de configure, c'est justement de faire abstration de l'OS le temps de pondre un config.h ou/et un certain nombre de scripts de compilation. Supposer qu'il y a déjà un /tmp est une connerie sans nom parce que cela revient à mettre la charrue avant les boeufs.
Quant au noexec,nodev,nosuid sur /tmp, c'est la base de l’administration des systèmes unix que de ne pas permettre l'exécution dans les répertoires qui ne sont pas censés contenir des exécutables. Et surtout dans des répertoires accessibles en écriture à tout le monde tel /tmp. Mais peut être auraient-ils du, il y a 40 ans, consulter Monsieur George qui leur aurait expliqué que c'était une aberration !
Ce qui est assez amusant, c'est que les mêmes qui affirment haut et fort que /tmp (et les autres du même acabit) doivent être montés sans l'option -noexec sont aussi ceux qui viennent pleurer des conséquences de leur choix.
Pour revenir au sujet : je trouve assez bizarre d'attaquer quelque chose dans /dev lorsque je ne veux pas attaquer directement un device. Mais rien ne m'empêche de le faire. La collision de nom est possible, mais comme avec tous les autres noms de fichiers dans tous les autres répertoires. Tu vas me dire qu'on est avancé, mais /dev/shm n'est là que pour implanter les segments de mémoire partagés POSIX car les SysV posent un certain nombres des problèmes. Après, il faut être au courant de la chose et éviter de faire n'importe quoi. Lorsqu'on ouvre un segment de mémoire partagée, il a à être par défaut en 0600. Je te mets donc au défi de casser quelque chose d'autre qu'un programme que tu as lancé dans la même session. Tu me diras aussi que ce segment peut être en 0666 voire en 0777. Mais là, autant toujours bosser en root ou changer d'OS.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Thu, 24 Nov 2011 00:01:15 +0100,
NiKo <NiKo@nomail.svp> écrivait :
Le 23/11/2011 23:23, Nicolas George a écrit :
NiKo , dans le message <4ecd6966$0$27879$426a74cc@news.free.fr>, a
écrit :
Quelle bande de bras cassés tous ces gars qui se servent de /dev/shm !
Là, clairement bras cassé. Allez, les plus flagrantes.
* « Je ne saurais trop vous conseillez », « tmpfs est trés simple à utliser
et peux »... no comment.
* Monter /tmp en noexec : merci pour les ./configure qui y font des tests de
compilation et d'exécution.
Quel est le rapport avec /dev/shm ? Parce qu'il y a des fautes
d'orthographe ? Surement que les gens qui sont derrière Arch ou Gentoo
sont des bras cassés à coté de Monsieur George !
J'aimerais aussi savoir quel script configure se permet d'aller
écrire dans /tmp pour effectuer des tests. L'intérêt de configure,
c'est justement de faire abstration de l'OS le temps de pondre un
config.h ou/et un certain nombre de scripts de compilation. Supposer
qu'il y a déjà un /tmp est une connerie sans nom parce que cela
revient à mettre la charrue avant les boeufs.
Quant au noexec,nodev,nosuid sur /tmp, c'est la base de l’administration
des systèmes unix que de ne pas permettre l'exécution dans les
répertoires qui ne sont pas censés contenir des exécutables. Et surtout
dans des répertoires accessibles en écriture à tout le monde tel /tmp.
Mais peut être auraient-ils du, il y a 40 ans, consulter Monsieur George
qui leur aurait expliqué que c'était une aberration !
Ce qui est assez amusant, c'est que les mêmes qui affirment haut et
fort que /tmp (et les autres du même acabit) doivent être montés
sans l'option -noexec sont aussi ceux qui viennent pleurer des
conséquences de leur choix.
Pour revenir au sujet : je trouve assez bizarre d'attaquer quelque
chose dans /dev lorsque je ne veux pas attaquer directement un
device. Mais rien ne m'empêche de le faire. La collision de nom est
possible, mais comme avec tous les autres noms de fichiers dans tous
les autres répertoires. Tu vas me dire qu'on est avancé, mais
/dev/shm n'est là que pour implanter les segments de mémoire
partagés POSIX car les SysV posent un certain nombres des problèmes.
Après, il faut être au courant de la chose et éviter de faire
n'importe quoi. Lorsqu'on ouvre un segment de mémoire partagée, il a
à être par défaut en 0600. Je te mets donc au défi de casser quelque
chose d'autre qu'un programme que tu as lancé dans la même session.
Tu me diras aussi que ce segment peut être en 0666 voire en 0777.
Mais là, autant toujours bosser en root ou changer d'OS.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Là, clairement bras cassé. Allez, les plus flagrantes.
* « Je ne saurais trop vous conseillez », « tmpfs est trés simple à utliser et peux »... no comment.
* Monter /tmp en noexec : merci pour les ./configure qui y font des tests de compilation et d'exécution.
Quel est le rapport avec /dev/shm ? Parce qu'il y a des fautes d'orthographe ? Surement que les gens qui sont derrière Arch ou Gentoo sont des bras cassés à coté de Monsieur George !
J'aimerais aussi savoir quel script configure se permet d'aller écrire dans /tmp pour effectuer des tests. L'intérêt de configure, c'est justement de faire abstration de l'OS le temps de pondre un config.h ou/et un certain nombre de scripts de compilation. Supposer qu'il y a déjà un /tmp est une connerie sans nom parce que cela revient à mettre la charrue avant les boeufs.
Quant au noexec,nodev,nosuid sur /tmp, c'est la base de l’administration des systèmes unix que de ne pas permettre l'exécution dans les répertoires qui ne sont pas censés contenir des exécutables. Et surtout dans des répertoires accessibles en écriture à tout le monde tel /tmp. Mais peut être auraient-ils du, il y a 40 ans, consulter Monsieur George qui leur aurait expliqué que c'était une aberration !
Ce qui est assez amusant, c'est que les mêmes qui affirment haut et fort que /tmp (et les autres du même acabit) doivent être montés sans l'option -noexec sont aussi ceux qui viennent pleurer des conséquences de leur choix.
Pour revenir au sujet : je trouve assez bizarre d'attaquer quelque chose dans /dev lorsque je ne veux pas attaquer directement un device. Mais rien ne m'empêche de le faire. La collision de nom est possible, mais comme avec tous les autres noms de fichiers dans tous les autres répertoires. Tu vas me dire qu'on est avancé, mais /dev/shm n'est là que pour implanter les segments de mémoire partagés POSIX car les SysV posent un certain nombres des problèmes. Après, il faut être au courant de la chose et éviter de faire n'importe quoi. Lorsqu'on ouvre un segment de mémoire partagée, il a à être par défaut en 0600. Je te mets donc au défi de casser quelque chose d'autre qu'un programme que tu as lancé dans la même session. Tu me diras aussi que ce segment peut être en 0666 voire en 0777. Mais là, autant toujours bosser en root ou changer d'OS.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
JKB
Le 24 Nov 2011 08:24:40 GMT, Nicolas George <nicolas$ écrivait :
YBM , dans le message <4ecdbc00$0$613$, a écrit :
Oui, que "noexec" est en réalité sans intérêt au niveau sécurité.
Je suis content que quelqu'un soulève la question, parce que c'est un point sans rapport avec la discussion présente qu'il m'embêtait de laisser en suspens, pour la pollution dans les esprits qu'il propage.
Cette manie de coller du noexec,nodev,nosuid partout est typique des gens qui appliquent la sécurité comme un dogme, sans comprendre les mécanismes en jeu. N'importe qui qui a un tant soit peu étudié la question sait que ça conduit invariablement, comme le « plan vigipirate », à des mesures qui incommodent les usagers légitimes mais ne freinent pas du tout les attaquants.
Dans le cas de noexec, il existe de nombreuses méthodes : invoquer le chargeur dynamique directement, utiliser un langage interprété (NiKo en a parlé), on peut aussi produire une bibliothèque partagée et forcer un binaire normal du système à la charger.
Il peut y avoir un sens à mettre les partitions en noexec sur un système ultra-sécurisé, où on a pris soin de n'installer que le strict minimum, de mettre tous les binaires en statique, de n'autoriser l'exécution absolument nulle part, etc. Mais sur une machine d'usage régulier, mettre /tmp en noexec, c'est comme donner deux tours de verrou à une porte posée sans chambranle en bordure d'un champ.
Et c'est même pire, parce que beaucoup de programmes légitimes s'attendent à ce que /tmp permette d'exécuter des programmes : ça ne freine pas les pirates, ça gène les utilisateurs.
Dans la même série, il y avait nosuid : si on est en position de poser un binaire SUID, c'est qu'on a déjà les droits du compte incriminé, le piratage a déjà eu lieu. Poser un binaire SUID, ça permet juste de garder ces droits au chaud pour plus tard, et ce n'est qu'une manière parmi beaucoup d'autres de le faire.
Et le nodev, encore pire : si on peut créer des devices, c'est qu'on est root, et si on est root, ce ne sont pas les options sur un filesystem qui vont nous gêner.
Pour autant, le nodev,nosuid ont un usage légitime pour la sécurité, juste pas celui que NiKo et ses semblables croient : ces options sont prévues pour les cas où on importe un filesystem entier auquel on ne peut pas faire confiance, en général par réseau ou sur un support amovible. Il est très facile de graver un CD avec un équivalent de /dev/mem en écriture publique ou un shell SUID root, donc si le système permet à n'importe quel utilisateur de monter un CD, il doit le faire avec ces options nodev,nosuid.
D'ailleurs, le man de mount indique que les différentes options qui permettent à un simple utilisateur de monter un filesystem (user, group, owner) impliquent par défaut ces deux options (mais pas noexec). Eux, heureusement, comprennent les problèmes en jeu.
Tu zappes juste un truc avec le noexec. Lorsque tu as des serveurs apache, par exemple, le noexec est vraiment utile parce qu'un grand classique, c'est l'injection qui va écrire quelque part dans un /tmp et qui lance ni vu ni connu son script au travers de l'une des nombreuses failles des outils écrits en php par des pieds. Le noexec n'est pas utile lorsqu'on a déjà un accès local, mais en prévention. De toute façon, le type qui a réussi à avoir un accès local va mettre ses merdouilles dans un répertoire du style '.. ' et comme l'immense majorité des distributions vient avec un zoli compilo C, c'est assez rapidement la fête, noexec ou non.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le 24 Nov 2011 08:24:40 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :
YBM , dans le message <4ecdbc00$0$613$426a74cc@news.free.fr>, a écrit :
Oui, que "noexec" est en réalité sans intérêt au niveau sécurité.
Je suis content que quelqu'un soulève la question, parce que c'est un point
sans rapport avec la discussion présente qu'il m'embêtait de laisser en
suspens, pour la pollution dans les esprits qu'il propage.
Cette manie de coller du noexec,nodev,nosuid partout est typique des gens
qui appliquent la sécurité comme un dogme, sans comprendre les mécanismes en
jeu. N'importe qui qui a un tant soit peu étudié la question sait que ça
conduit invariablement, comme le « plan vigipirate », à des mesures qui
incommodent les usagers légitimes mais ne freinent pas du tout les
attaquants.
Dans le cas de noexec, il existe de nombreuses méthodes : invoquer le
chargeur dynamique directement, utiliser un langage interprété (NiKo en a
parlé), on peut aussi produire une bibliothèque partagée et forcer un
binaire normal du système à la charger.
Il peut y avoir un sens à mettre les partitions en noexec sur un système
ultra-sécurisé, où on a pris soin de n'installer que le strict minimum, de
mettre tous les binaires en statique, de n'autoriser l'exécution absolument
nulle part, etc. Mais sur une machine d'usage régulier, mettre /tmp en
noexec, c'est comme donner deux tours de verrou à une porte posée sans
chambranle en bordure d'un champ.
Et c'est même pire, parce que beaucoup de programmes légitimes s'attendent à
ce que /tmp permette d'exécuter des programmes : ça ne freine pas les
pirates, ça gène les utilisateurs.
Dans la même série, il y avait nosuid : si on est en position de poser un
binaire SUID, c'est qu'on a déjà les droits du compte incriminé, le piratage
a déjà eu lieu. Poser un binaire SUID, ça permet juste de garder ces droits
au chaud pour plus tard, et ce n'est qu'une manière parmi beaucoup d'autres
de le faire.
Et le nodev, encore pire : si on peut créer des devices, c'est qu'on est
root, et si on est root, ce ne sont pas les options sur un filesystem qui
vont nous gêner.
Pour autant, le nodev,nosuid ont un usage légitime pour la sécurité, juste
pas celui que NiKo et ses semblables croient : ces options sont prévues pour
les cas où on importe un filesystem entier auquel on ne peut pas faire
confiance, en général par réseau ou sur un support amovible. Il est très
facile de graver un CD avec un équivalent de /dev/mem en écriture publique
ou un shell SUID root, donc si le système permet à n'importe quel
utilisateur de monter un CD, il doit le faire avec ces options nodev,nosuid.
D'ailleurs, le man de mount indique que les différentes options qui
permettent à un simple utilisateur de monter un filesystem (user, group,
owner) impliquent par défaut ces deux options (mais pas noexec). Eux,
heureusement, comprennent les problèmes en jeu.
Tu zappes juste un truc avec le noexec. Lorsque tu as des serveurs
apache, par exemple, le noexec est vraiment utile parce qu'un grand
classique, c'est l'injection qui va écrire quelque part dans un /tmp
et qui lance ni vu ni connu son script au travers de l'une des
nombreuses failles des outils écrits en php par des pieds. Le noexec
n'est pas utile lorsqu'on a déjà un accès local, mais en prévention.
De toute façon, le type qui a réussi à avoir un accès local va mettre ses
merdouilles dans un répertoire du style '.. ' et comme l'immense
majorité des distributions vient avec un zoli compilo C, c'est assez
rapidement la fête, noexec ou non.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le 24 Nov 2011 08:24:40 GMT, Nicolas George <nicolas$ écrivait :
YBM , dans le message <4ecdbc00$0$613$, a écrit :
Oui, que "noexec" est en réalité sans intérêt au niveau sécurité.
Je suis content que quelqu'un soulève la question, parce que c'est un point sans rapport avec la discussion présente qu'il m'embêtait de laisser en suspens, pour la pollution dans les esprits qu'il propage.
Cette manie de coller du noexec,nodev,nosuid partout est typique des gens qui appliquent la sécurité comme un dogme, sans comprendre les mécanismes en jeu. N'importe qui qui a un tant soit peu étudié la question sait que ça conduit invariablement, comme le « plan vigipirate », à des mesures qui incommodent les usagers légitimes mais ne freinent pas du tout les attaquants.
Dans le cas de noexec, il existe de nombreuses méthodes : invoquer le chargeur dynamique directement, utiliser un langage interprété (NiKo en a parlé), on peut aussi produire une bibliothèque partagée et forcer un binaire normal du système à la charger.
Il peut y avoir un sens à mettre les partitions en noexec sur un système ultra-sécurisé, où on a pris soin de n'installer que le strict minimum, de mettre tous les binaires en statique, de n'autoriser l'exécution absolument nulle part, etc. Mais sur une machine d'usage régulier, mettre /tmp en noexec, c'est comme donner deux tours de verrou à une porte posée sans chambranle en bordure d'un champ.
Et c'est même pire, parce que beaucoup de programmes légitimes s'attendent à ce que /tmp permette d'exécuter des programmes : ça ne freine pas les pirates, ça gène les utilisateurs.
Dans la même série, il y avait nosuid : si on est en position de poser un binaire SUID, c'est qu'on a déjà les droits du compte incriminé, le piratage a déjà eu lieu. Poser un binaire SUID, ça permet juste de garder ces droits au chaud pour plus tard, et ce n'est qu'une manière parmi beaucoup d'autres de le faire.
Et le nodev, encore pire : si on peut créer des devices, c'est qu'on est root, et si on est root, ce ne sont pas les options sur un filesystem qui vont nous gêner.
Pour autant, le nodev,nosuid ont un usage légitime pour la sécurité, juste pas celui que NiKo et ses semblables croient : ces options sont prévues pour les cas où on importe un filesystem entier auquel on ne peut pas faire confiance, en général par réseau ou sur un support amovible. Il est très facile de graver un CD avec un équivalent de /dev/mem en écriture publique ou un shell SUID root, donc si le système permet à n'importe quel utilisateur de monter un CD, il doit le faire avec ces options nodev,nosuid.
D'ailleurs, le man de mount indique que les différentes options qui permettent à un simple utilisateur de monter un filesystem (user, group, owner) impliquent par défaut ces deux options (mais pas noexec). Eux, heureusement, comprennent les problèmes en jeu.
Tu zappes juste un truc avec le noexec. Lorsque tu as des serveurs apache, par exemple, le noexec est vraiment utile parce qu'un grand classique, c'est l'injection qui va écrire quelque part dans un /tmp et qui lance ni vu ni connu son script au travers de l'une des nombreuses failles des outils écrits en php par des pieds. Le noexec n'est pas utile lorsqu'on a déjà un accès local, mais en prévention. De toute façon, le type qui a réussi à avoir un accès local va mettre ses merdouilles dans un répertoire du style '.. ' et comme l'immense majorité des distributions vient avec un zoli compilo C, c'est assez rapidement la fête, noexec ou non.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Nicolas George
JKB , dans le message , a écrit :
c'est l'injection qui va écrire quelque part dans un /tmp et qui lance ni vu ni connu son script au travers de l'une des nombreuses failles des outils écrits en php par des pieds.
Je ne vois pas ce que ça change, il faudra juste utiliser les bonnes options pour exécuter le truc.
Accessoirement, si on a la sécurité en vue, on commence par désactiver PHP, avant de changer les options de montage de /tmp.
JKB , dans le message <slrnjcsgh2.4rm.jkb@rayleigh.systella.fr>, a
écrit :
c'est l'injection qui va écrire quelque part dans un /tmp
et qui lance ni vu ni connu son script au travers de l'une des
nombreuses failles des outils écrits en php par des pieds.
Je ne vois pas ce que ça change, il faudra juste utiliser les bonnes options
pour exécuter le truc.
Accessoirement, si on a la sécurité en vue, on commence par désactiver PHP,
avant de changer les options de montage de /tmp.
c'est l'injection qui va écrire quelque part dans un /tmp et qui lance ni vu ni connu son script au travers de l'une des nombreuses failles des outils écrits en php par des pieds.
Je ne vois pas ce que ça change, il faudra juste utiliser les bonnes options pour exécuter le truc.
Accessoirement, si on a la sécurité en vue, on commence par désactiver PHP, avant de changer les options de montage de /tmp.
Nicolas George
JKB , dans le message , a écrit :
J'aimerais aussi savoir quel script configure se permet d'aller écrire dans /tmp pour effectuer des tests.
Le Wed, 23 Nov 2011 20:14:18 +0000, Nicolas George a écrit:
Cette phrase ne dit pas ce que tu crois qu'elle veut dire et que tu expliques juste au dessus. [...] la libc, de leur point de vue, n'est qu'une bibliothèque parmi d'autres.
Ok, ok.
Du coup, tu cours le risque d'entrer en conflit avec ce que la libc s'attend à trouver dans ce répertoire, puisque tu modifies son contenu sans passer par les fonctions idoines.
Dit comme ça, ça me paraît relever d'un principe de précaution à la limite de l'excès. Où puis-je me renseigner pour savoir ce que la libc est censée écrire dans ce répertoire ?
Tu devrais lire plus attentivement la description de cette option,
Ok, ok.
Qu'il y ait conflit de noms, c'est toujours possible ; comme dans /tmp .
La différence, c'est que l'usage de /dev/shm est normalement réservé à la glibc,
Je n'arrive pas à trouver où une telle chose serait écrite.
Non, il ne doit pas créer des fichiers dans /dev/shm,
Ben il n'est pas convaincu du bien-fondé de cette directive en général, mais il évitera de le faire sur un serveur qu'il n'administre pas personellement sans consulter l'admin, disons.
pas plus qu'il ne doit créer des fichiers dans /var/lock ou ~/.fontconfig. S'il veut créer des fichiers temporaires, il les crée dans /tmp.
Comme tout finit par arriver, un utilisateur finira bien à saturer /dev/ shm (qui n'est pas très grand) un soir après le départ de l'admin. Donc on peut, en effet, déconseiller fortement cette pratique sur une machine partagée.
à + -- Hervé
Le Wed, 23 Nov 2011 20:14:18 +0000, Nicolas George a écrit:
Cette phrase ne dit pas ce que tu crois qu'elle veut dire et que tu
expliques juste au dessus.
[...] la libc, de leur
point de vue, n'est qu'une bibliothèque parmi d'autres.
Ok, ok.
Du coup, tu cours le risque d'entrer en conflit avec ce que la libc
s'attend à trouver dans ce répertoire, puisque tu modifies son contenu
sans passer par les fonctions idoines.
Dit comme ça, ça me paraît relever d'un principe de précaution à la
limite de l'excès. Où puis-je me renseigner pour savoir ce que la libc
est censée écrire dans ce répertoire ?
Tu devrais lire plus attentivement la description de cette option,
Ok, ok.
Qu'il y ait conflit de noms, c'est toujours possible ; comme dans /tmp
.
La différence, c'est que l'usage de /dev/shm est normalement réservé à
la glibc,
Je n'arrive pas à trouver où une telle chose serait écrite.
Non, il ne doit pas créer des fichiers dans /dev/shm,
Ben il n'est pas convaincu du bien-fondé de cette directive en général,
mais il évitera de le faire sur un serveur qu'il n'administre pas
personellement sans consulter l'admin, disons.
pas plus qu'il ne
doit créer des fichiers dans /var/lock ou ~/.fontconfig. S'il veut créer
des fichiers temporaires, il les crée dans /tmp.
Comme tout finit par arriver, un utilisateur finira bien à saturer /dev/
shm (qui n'est pas très grand) un soir après le départ de l'admin. Donc
on peut, en effet, déconseiller fortement cette pratique sur une machine
partagée.
Le Wed, 23 Nov 2011 20:14:18 +0000, Nicolas George a écrit:
Cette phrase ne dit pas ce que tu crois qu'elle veut dire et que tu expliques juste au dessus. [...] la libc, de leur point de vue, n'est qu'une bibliothèque parmi d'autres.
Ok, ok.
Du coup, tu cours le risque d'entrer en conflit avec ce que la libc s'attend à trouver dans ce répertoire, puisque tu modifies son contenu sans passer par les fonctions idoines.
Dit comme ça, ça me paraît relever d'un principe de précaution à la limite de l'excès. Où puis-je me renseigner pour savoir ce que la libc est censée écrire dans ce répertoire ?
Tu devrais lire plus attentivement la description de cette option,
Ok, ok.
Qu'il y ait conflit de noms, c'est toujours possible ; comme dans /tmp .
La différence, c'est que l'usage de /dev/shm est normalement réservé à la glibc,
Je n'arrive pas à trouver où une telle chose serait écrite.
Non, il ne doit pas créer des fichiers dans /dev/shm,
Ben il n'est pas convaincu du bien-fondé de cette directive en général, mais il évitera de le faire sur un serveur qu'il n'administre pas personellement sans consulter l'admin, disons.
pas plus qu'il ne doit créer des fichiers dans /var/lock ou ~/.fontconfig. S'il veut créer des fichiers temporaires, il les crée dans /tmp.
Comme tout finit par arriver, un utilisateur finira bien à saturer /dev/ shm (qui n'est pas très grand) un soir après le départ de l'admin. Donc on peut, en effet, déconseiller fortement cette pratique sur une machine partagée.
à + -- Hervé
JKB
Le 24 Nov 2011 13:50:54 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
c'est l'injection qui va écrire quelque part dans un /tmp et qui lance ni vu ni connu son script au travers de l'une des nombreuses failles des outils écrits en php par des pieds.
Je ne vois pas ce que ça change, il faudra juste utiliser les bonnes options pour exécuter le truc.
Sauf que tu n'as pas _forcément_ accès à un shell ou à autre chose pour changer lesdites options.
Accessoirement, si on a la sécurité en vue, on commence par désactiver PHP, avant de changer les options de montage de /tmp.
Mauvaise réponse. Souvent, tu ne _peux_ pas le désactiver parce qu'une application écrite par un pied tourne dessus.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le 24 Nov 2011 13:50:54 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :
JKB , dans le message <slrnjcsgh2.4rm.jkb@rayleigh.systella.fr>, a
écrit :
c'est l'injection qui va écrire quelque part dans un /tmp
et qui lance ni vu ni connu son script au travers de l'une des
nombreuses failles des outils écrits en php par des pieds.
Je ne vois pas ce que ça change, il faudra juste utiliser les bonnes options
pour exécuter le truc.
Sauf que tu n'as pas _forcément_ accès à un shell ou à autre chose
pour changer lesdites options.
Accessoirement, si on a la sécurité en vue, on commence par désactiver PHP,
avant de changer les options de montage de /tmp.
Mauvaise réponse. Souvent, tu ne _peux_ pas le désactiver parce
qu'une application écrite par un pied tourne dessus.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le 24 Nov 2011 13:50:54 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
c'est l'injection qui va écrire quelque part dans un /tmp et qui lance ni vu ni connu son script au travers de l'une des nombreuses failles des outils écrits en php par des pieds.
Je ne vois pas ce que ça change, il faudra juste utiliser les bonnes options pour exécuter le truc.
Sauf que tu n'as pas _forcément_ accès à un shell ou à autre chose pour changer lesdites options.
Accessoirement, si on a la sécurité en vue, on commence par désactiver PHP, avant de changer les options de montage de /tmp.
Mauvaise réponse. Souvent, tu ne _peux_ pas le désactiver parce qu'une application écrite par un pied tourne dessus.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
JKB
Le 24 Nov 2011 13:54:49 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
J'aimerais aussi savoir quel script configure se permet d'aller écrire dans /tmp pour effectuer des tests.
Mauvaise réponse. mktemp crée un fichier temporaire. Rien ne te garantit qu'il est créé dans /tmp. Je peux te citer au moins deux systèmes Unix où ce n'est pas vrai.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le 24 Nov 2011 13:54:49 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :
JKB , dans le message <slrnjcsg5u.4rm.jkb@rayleigh.systella.fr>, a
écrit :
J'aimerais aussi savoir quel script configure se permet d'aller
écrire dans /tmp pour effectuer des tests.
Mauvaise réponse. mktemp crée un fichier temporaire. Rien ne te
garantit qu'il est créé dans /tmp. Je peux te citer au moins deux
systèmes Unix où ce n'est pas vrai.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Mauvaise réponse. mktemp crée un fichier temporaire. Rien ne te garantit qu'il est créé dans /tmp. Je peux te citer au moins deux systèmes Unix où ce n'est pas vrai.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
