Bien sûr que si, sauf que je ne connais pas exactement le format d'écriture qu'il faut pour faire ça. Mais évidemment c'est ce que fait mkdir, il ne fait jamais que des write tout ce qu'il y a de plus stupides sur un fichier.
Par contre il faut évidemment une information supplémentaire provenant de l'OS, le numéro de l'inode affecté à un fichier qui doit nécessairement se trouver dans le répertoire pour qu'on puisse accéder audit fichier. Mais ca c'est exactement le même problème qu'on crée un fichier ordinaire ou un répertoire.
Tu dis des bêtises. Si un simple write permettant, en connaissant le numéro de l'inode (qu'on obtient facilement d'un simple ls -i) et le format des répertoires (qu'on peut connaître par imitations de répertoires déjà existants, ou en lisant les sources), de modifier un répertoire pour y lier un fichier, ce serait un trou de sécurité énorme.
En effet, il suffirait d'intuiter le numéro d'inode, ce qui n'est pas très difficile, et peut se faire par force brute, pour accéder à n'importe quelle fichier publiquement lisible d'une partition dans laquelle on possède un répertoire, même si le fichier en question est dans un répertoire privé.
Tout ceci n'est pas très clair. Suppose ceci :
/home -> une partition /home/talon -> ton répertoire, en 700 /home/talon/informations_confidentielles -> en 644, tu t'en fous, il est dans un répertoire protégé /home/george -> mon répertoire
Dans mon répertoire : mkdir hack, puis des write dedans pour y lier des fichiers d'inodes aléatoires, et hop, au bout de quelques essais, je trouve un fichier en 644 dont tu es le propriétaire.
Heureusement, aucun Unix ne permet ça !
talon@lpthe.jussieu.fr, dans le message
<ch59lv$2d9$3@rose.lpthe.jussieu.fr>, a écrit :
Bien sûr que si, sauf que je ne connais pas exactement le format d'écriture
qu'il faut pour faire ça. Mais évidemment c'est ce que fait mkdir, il ne fait
jamais que des write tout ce qu'il y a de plus stupides sur un fichier.
Par contre il faut évidemment une information supplémentaire provenant de
l'OS, le numéro de l'inode affecté à un fichier qui doit nécessairement se
trouver dans le répertoire pour qu'on puisse accéder audit fichier. Mais ca
c'est exactement le même problème qu'on crée un fichier ordinaire ou un
répertoire.
Tu dis des bêtises. Si un simple write permettant, en connaissant le
numéro de l'inode (qu'on obtient facilement d'un simple ls -i) et le
format des répertoires (qu'on peut connaître par imitations de
répertoires déjà existants, ou en lisant les sources), de modifier un
répertoire pour y lier un fichier, ce serait un trou de sécurité énorme.
En effet, il suffirait d'intuiter le numéro d'inode, ce qui n'est pas
très difficile, et peut se faire par force brute, pour accéder à
n'importe quelle fichier publiquement lisible d'une partition dans
laquelle on possède un répertoire, même si le fichier en question est
dans un répertoire privé.
Tout ceci n'est pas très clair. Suppose ceci :
/home -> une partition
/home/talon -> ton répertoire, en 700
/home/talon/informations_confidentielles -> en 644, tu t'en fous, il est
dans un répertoire protégé
/home/george -> mon répertoire
Dans mon répertoire : mkdir hack, puis des write dedans pour y lier des
fichiers d'inodes aléatoires, et hop, au bout de quelques essais, je
trouve un fichier en 644 dont tu es le propriétaire.
Bien sûr que si, sauf que je ne connais pas exactement le format d'écriture qu'il faut pour faire ça. Mais évidemment c'est ce que fait mkdir, il ne fait jamais que des write tout ce qu'il y a de plus stupides sur un fichier.
Par contre il faut évidemment une information supplémentaire provenant de l'OS, le numéro de l'inode affecté à un fichier qui doit nécessairement se trouver dans le répertoire pour qu'on puisse accéder audit fichier. Mais ca c'est exactement le même problème qu'on crée un fichier ordinaire ou un répertoire.
Tu dis des bêtises. Si un simple write permettant, en connaissant le numéro de l'inode (qu'on obtient facilement d'un simple ls -i) et le format des répertoires (qu'on peut connaître par imitations de répertoires déjà existants, ou en lisant les sources), de modifier un répertoire pour y lier un fichier, ce serait un trou de sécurité énorme.
En effet, il suffirait d'intuiter le numéro d'inode, ce qui n'est pas très difficile, et peut se faire par force brute, pour accéder à n'importe quelle fichier publiquement lisible d'une partition dans laquelle on possède un répertoire, même si le fichier en question est dans un répertoire privé.
Tout ceci n'est pas très clair. Suppose ceci :
/home -> une partition /home/talon -> ton répertoire, en 700 /home/talon/informations_confidentielles -> en 644, tu t'en fous, il est dans un répertoire protégé /home/george -> mon répertoire
Dans mon répertoire : mkdir hack, puis des write dedans pour y lier des fichiers d'inodes aléatoires, et hop, au bout de quelques essais, je trouve un fichier en 644 dont tu es le propriétaire.
Heureusement, aucun Unix ne permet ça !
Michel Talon
Nicolas George wrote:
, dans le message
Tu dis des bêtises. Si un simple write permettant, en connaissant le
Dans mon répertoire : mkdir hack, puis des write dedans pour y lier des fichiers d'inodes aléatoires, et hop, au bout de quelques essais, je trouve un fichier en 644 dont tu es le propriétaire.
Heureusement, aucun Unix ne permet ça !
Je ne comprends pas ce que tu veux dire. Les permissions sont dans l'inode, pas dans le répertoire, sauf erreur. Donc même si tu lies mon fichier dans ton répertoire tu ne peux le lire. Corriges moi si je me souviens mal, mais je crois que toutes les informations associées à un fichier (taille, dates variées, nombre de liens, permissions et numéros de blocs composant le fichier- au moins les directs, sont dans l'inode, suf les noms du fichier. Le répertoire ne contient que des noms et l'inode sur lequel ils pointent. Ce qui permet d'implémenter ln, simplement en écrivant un nouveau nom pointant sur le même inode, et de s'assurer de la cohérence - tous les alias pointent sur le même objet, tout modification sur un alias est répercutée sur tous les autres, etc.
Nicolas George wrote:
talon@lpthe.jussieu.fr, dans le message
Tu dis des bêtises. Si un simple write permettant, en connaissant le
Dans mon répertoire : mkdir hack, puis des write dedans pour y lier des
fichiers d'inodes aléatoires, et hop, au bout de quelques essais, je
trouve un fichier en 644 dont tu es le propriétaire.
Heureusement, aucun Unix ne permet ça !
Je ne comprends pas ce que tu veux dire. Les permissions sont dans
l'inode, pas dans le répertoire, sauf erreur. Donc même si tu lies mon
fichier dans ton répertoire tu ne peux le lire. Corriges moi si je me
souviens mal, mais je crois que toutes les informations associées à un
fichier (taille, dates variées, nombre de liens, permissions et numéros
de blocs composant le fichier- au moins les directs, sont dans l'inode,
suf les noms du fichier. Le répertoire ne contient que des noms et
l'inode sur lequel ils pointent. Ce qui permet d'implémenter ln,
simplement en écrivant un nouveau nom pointant sur le même inode, et
de s'assurer de la cohérence - tous les alias pointent sur le même
objet, tout modification sur un alias est répercutée sur tous les
autres, etc.
Tu dis des bêtises. Si un simple write permettant, en connaissant le
Dans mon répertoire : mkdir hack, puis des write dedans pour y lier des fichiers d'inodes aléatoires, et hop, au bout de quelques essais, je trouve un fichier en 644 dont tu es le propriétaire.
Heureusement, aucun Unix ne permet ça !
Je ne comprends pas ce que tu veux dire. Les permissions sont dans l'inode, pas dans le répertoire, sauf erreur. Donc même si tu lies mon fichier dans ton répertoire tu ne peux le lire. Corriges moi si je me souviens mal, mais je crois que toutes les informations associées à un fichier (taille, dates variées, nombre de liens, permissions et numéros de blocs composant le fichier- au moins les directs, sont dans l'inode, suf les noms du fichier. Le répertoire ne contient que des noms et l'inode sur lequel ils pointent. Ce qui permet d'implémenter ln, simplement en écrivant un nouveau nom pointant sur le même inode, et de s'assurer de la cohérence - tous les alias pointent sur le même objet, tout modification sur un alias est répercutée sur tous les autres, etc.
Nicolas George
Michel Talon , dans le message <4136388c$0$26998$, a écrit :
Je ne comprends pas ce que tu veux dire. Les permissions sont dans l'inode, pas dans le répertoire, sauf erreur. Donc même si tu lies mon fichier dans ton répertoire tu ne peux le lire. Corriges moi si je me souviens mal, mais je crois que toutes les informations associées à un fichier (taille, dates variées, nombre de liens, permissions et numéros de blocs composant le fichier- au moins les directs, sont dans l'inode, suf les noms du fichier.
Toutes les informations sur le fichier sauf son nom sont bien dans l'inode. Mais pour les droits d'accès, il y a plus que ces informations qui entrent en jeu : il y a toutes les protections des répertoires à traverser. Je rappelle le scénario que j'avais évoqué :
/home/talon -> ton répertoire, en 700 /home/talon/informations_confidentielles -> en 644, tu t'en fous, il est dans un répertoire protégé
Ton fichier est, par lui-même, publiquement lisible, mais protégé par sa présence dans un répertoire protégé.
Dans ces conditions, si j'arrive à avoir un lien vers ce fichier dans un répertoire qui m'est accessible, tu as perdu.
Michel Talon , dans le message <4136388c$0$26998$626a14ce@news.free.fr>,
a écrit :
Je ne comprends pas ce que tu veux dire. Les permissions sont dans
l'inode, pas dans le répertoire, sauf erreur. Donc même si tu lies mon
fichier dans ton répertoire tu ne peux le lire. Corriges moi si je me
souviens mal, mais je crois que toutes les informations associées à un
fichier (taille, dates variées, nombre de liens, permissions et numéros
de blocs composant le fichier- au moins les directs, sont dans l'inode,
suf les noms du fichier.
Toutes les informations sur le fichier sauf son nom sont bien dans
l'inode. Mais pour les droits d'accès, il y a plus que ces informations
qui entrent en jeu : il y a toutes les protections des répertoires à
traverser. Je rappelle le scénario que j'avais évoqué :
/home/talon -> ton répertoire, en 700
/home/talon/informations_confidentielles -> en 644, tu t'en fous, il est
dans un répertoire protégé
Ton fichier est, par lui-même, publiquement lisible, mais protégé par sa
présence dans un répertoire protégé.
Dans ces conditions, si j'arrive à avoir un lien vers ce fichier dans un
répertoire qui m'est accessible, tu as perdu.
Michel Talon , dans le message <4136388c$0$26998$, a écrit :
Je ne comprends pas ce que tu veux dire. Les permissions sont dans l'inode, pas dans le répertoire, sauf erreur. Donc même si tu lies mon fichier dans ton répertoire tu ne peux le lire. Corriges moi si je me souviens mal, mais je crois que toutes les informations associées à un fichier (taille, dates variées, nombre de liens, permissions et numéros de blocs composant le fichier- au moins les directs, sont dans l'inode, suf les noms du fichier.
Toutes les informations sur le fichier sauf son nom sont bien dans l'inode. Mais pour les droits d'accès, il y a plus que ces informations qui entrent en jeu : il y a toutes les protections des répertoires à traverser. Je rappelle le scénario que j'avais évoqué :
/home/talon -> ton répertoire, en 700 /home/talon/informations_confidentielles -> en 644, tu t'en fous, il est dans un répertoire protégé
Ton fichier est, par lui-même, publiquement lisible, mais protégé par sa présence dans un répertoire protégé.
Dans ces conditions, si j'arrive à avoir un lien vers ce fichier dans un répertoire qui m'est accessible, tu as perdu.
Michel Talon
Nicolas George wrote:
Michel Talon , dans le message <4136388c$0$26998$,
x
Ton fichier est, par lui-même, publiquement lisible, mais protégé par sa présence dans un répertoire protégé.
Dans ces conditions, si j'arrive à avoir un lien vers ce fichier dans un répertoire qui m'est accessible, tu as perdu.
Je suis d'accord et je pense que c'est possible. Je crois même que c'est essentiellement la base de l'attaque qui consiste à accéder aux fichiers en accédant directement au device (quand celui-ci est lisible par tout le monde), et en particulier à échapper aux jails si on peut faire un mknod dans la jail.
Nicolas George wrote:
Michel Talon , dans le message <4136388c$0$26998$626a14ce@news.free.fr>,
x
Ton fichier est, par lui-même, publiquement lisible, mais protégé par sa
présence dans un répertoire protégé.
Dans ces conditions, si j'arrive à avoir un lien vers ce fichier dans un
répertoire qui m'est accessible, tu as perdu.
Je suis d'accord et je pense que c'est possible. Je crois même que c'est
essentiellement la base de l'attaque qui consiste à accéder aux fichiers
en accédant directement au device (quand celui-ci est lisible par tout
le monde), et en particulier à échapper aux jails si on peut faire un
mknod dans la jail.
Michel Talon , dans le message <4136388c$0$26998$,
x
Ton fichier est, par lui-même, publiquement lisible, mais protégé par sa présence dans un répertoire protégé.
Dans ces conditions, si j'arrive à avoir un lien vers ce fichier dans un répertoire qui m'est accessible, tu as perdu.
Je suis d'accord et je pense que c'est possible. Je crois même que c'est essentiellement la base de l'attaque qui consiste à accéder aux fichiers en accédant directement au device (quand celui-ci est lisible par tout le monde), et en particulier à échapper aux jails si on peut faire un mknod dans la jail.
Miod Vallat
Dans ces conditions, si j'arrive à avoir un lien vers ce fichier dans un répertoire qui m'est accessible, tu as perdu.
<luc2> Non car ce n'est pas CONVIVIAL ! </>
Dans ces conditions, si j'arrive à avoir un lien vers ce fichier dans un
répertoire qui m'est accessible, tu as perdu.
open(".",0x8009,0666) ERR#21 'Is a directory' open(".",0x209,0666) ERR#21 'Is a directory' (FreeBSD 5)
Essaie sur ce que tu veux, on ne peut pas ouvrir un répertoire en écriture, c'est tout.
Je crois même que c'est essentiellement la base de l'attaque qui consiste à accéder aux fichiers en accédant directement au device (quand celui-ci est lisible par tout le monde), et en particulier à échapper aux jails si on peut faire un mknod dans la jail.
Si on peut accéder au device en écriture, on peut _tout_ faire. Il faudrait être vicieux pour s'emmerder à aller créer des répertoires pour accéder aux fichiers, quand on peut accéder aux fichiers eux-mêmes.
Ceci dit, tu as raison sur ce point, on *pourrait* le faire, mais ce serait sans passer par l'API Unix, donc c'est hors propos.
Michel Talon , dans le message <41363e37$0$26998$626a14ce@news.free.fr>,
a écrit :
Je suis d'accord et je pense que c'est possible.
Eh bien moi, je te dis que ça ne l'est pas.
open(".", O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE, 0666) = -1 EISDIR (Is a directory)
open(".", O_WRONLY|O_APPEND|O_NOCTTY|O_LARGEFILE) = -1 EISDIR (Is a directory)
(Linux 2.6)
open(".",0x8009,0666) ERR#21 'Is a directory'
open(".",0x209,0666) ERR#21 'Is a directory'
(FreeBSD 5)
Essaie sur ce que tu veux, on ne peut pas ouvrir un répertoire en
écriture, c'est tout.
Je crois même que c'est
essentiellement la base de l'attaque qui consiste à accéder aux fichiers
en accédant directement au device (quand celui-ci est lisible par tout
le monde), et en particulier à échapper aux jails si on peut faire un
mknod dans la jail.
Si on peut accéder au device en écriture, on peut _tout_ faire. Il
faudrait être vicieux pour s'emmerder à aller créer des répertoires pour
accéder aux fichiers, quand on peut accéder aux fichiers eux-mêmes.
Ceci dit, tu as raison sur ce point, on *pourrait* le faire, mais ce
serait sans passer par l'API Unix, donc c'est hors propos.
open(".",0x8009,0666) ERR#21 'Is a directory' open(".",0x209,0666) ERR#21 'Is a directory' (FreeBSD 5)
Essaie sur ce que tu veux, on ne peut pas ouvrir un répertoire en écriture, c'est tout.
Je crois même que c'est essentiellement la base de l'attaque qui consiste à accéder aux fichiers en accédant directement au device (quand celui-ci est lisible par tout le monde), et en particulier à échapper aux jails si on peut faire un mknod dans la jail.
Si on peut accéder au device en écriture, on peut _tout_ faire. Il faudrait être vicieux pour s'emmerder à aller créer des répertoires pour accéder aux fichiers, quand on peut accéder aux fichiers eux-mêmes.
Ceci dit, tu as raison sur ce point, on *pourrait* le faire, mais ce serait sans passer par l'API Unix, donc c'est hors propos.
talon
Nicolas George <nicolas$ wrote:
Michel Talon , dans le message <41363e37$0$26998$, a écrit :
Je suis d'accord et je pense que c'est possible.
Eh bien moi, je te dis que ça ne l'est pas.
Je suis d'accord avec toi, il y a effectivement une protection en écriture d'un répertoire, ce qui empêche de faire ce dont tu parlais.
rose% mkdir b rose% cat a > b zsh: is a directory: b
Ceci dit, tu as raison sur ce point, on *pourrait* le faire, mais ce serait sans passer par l'API Unix, donc c'est hors propos.
C'est tout à fait exact, si on s'interdit l'accés direct aux inodes (comme avec fsdb) il n'est pas possible de transformer un fichier standard en répertoire, etc. donc la cohérence du système est préservée. Enfin sur le point qui était évoqué au début, il reste vrai que dans le système de fichiers il y a une certaine uniformité entre fichier et répertoire, tandis que la partie cachée par le système mais fondamentale, est les inodes.
-- Michel Talon
Nicolas George <nicolas$george@salle-s.org> wrote:
Michel Talon , dans le message <41363e37$0$26998$626a14ce@news.free.fr>,
a écrit :
Je suis d'accord et je pense que c'est possible.
Eh bien moi, je te dis que ça ne l'est pas.
Je suis d'accord avec toi, il y a effectivement une protection en écriture
d'un répertoire, ce qui empêche de faire ce dont tu parlais.
rose% mkdir b
rose% cat a > b
zsh: is a directory: b
Ceci dit, tu as raison sur ce point, on *pourrait* le faire, mais ce
serait sans passer par l'API Unix, donc c'est hors propos.
C'est tout à fait exact, si on s'interdit l'accés direct aux inodes
(comme avec fsdb) il n'est pas possible de transformer un fichier standard
en répertoire, etc. donc la cohérence du système est préservée.
Enfin sur le point qui était évoqué au début, il reste vrai que dans le
système de fichiers il y a une certaine uniformité entre fichier et
répertoire, tandis que la partie cachée par le système mais fondamentale, est
les inodes.
Michel Talon , dans le message <41363e37$0$26998$, a écrit :
Je suis d'accord et je pense que c'est possible.
Eh bien moi, je te dis que ça ne l'est pas.
Je suis d'accord avec toi, il y a effectivement une protection en écriture d'un répertoire, ce qui empêche de faire ce dont tu parlais.
rose% mkdir b rose% cat a > b zsh: is a directory: b
Ceci dit, tu as raison sur ce point, on *pourrait* le faire, mais ce serait sans passer par l'API Unix, donc c'est hors propos.
C'est tout à fait exact, si on s'interdit l'accés direct aux inodes (comme avec fsdb) il n'est pas possible de transformer un fichier standard en répertoire, etc. donc la cohérence du système est préservée. Enfin sur le point qui était évoqué au début, il reste vrai que dans le système de fichiers il y a une certaine uniformité entre fichier et répertoire, tandis que la partie cachée par le système mais fondamentale, est les inodes.
-- Michel Talon
Michel Billaud
writes:
Nicolas George <nicolas$ wrote:
Michel Talon , dans le message <41363e37$0$26998$, a écrit :
Je suis d'accord et je pense que c'est possible.
Eh bien moi, je te dis que ça ne l'est pas.
Je suis d'accord avec toi, il y a effectivement une protection en écriture d'un répertoire, ce qui empêche de faire ce dont tu parlais.
rose% mkdir b rose% cat a > b zsh: is a directory: b
Ceci dit, tu as raison sur ce point, on *pourrait* le faire, mais ce serait sans passer par l'API Unix, donc c'est hors propos.
C'est tout à fait exact, si on s'interdit l'accés direct aux inodes (comme avec fsdb) il n'est pas possible de transformer un fichier standard en répertoire, etc. donc la cohérence du système est préservée. Enfin sur le point qui était évoqué au début, il reste vrai que dans le système de fichiers il y a une certaine uniformité entre fichier et répertoire, tandis que la partie cachée par le système mais fondamentale, est les inodes.
Bon, donc pour résumer: comme tout est fichier les répertoires sont donc des fichiers, sauf que c'est pas vraiment des fichiers.
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
talon@lpthe.jussieu.fr writes:
Nicolas George <nicolas$george@salle-s.org> wrote:
Michel Talon , dans le message <41363e37$0$26998$626a14ce@news.free.fr>,
a écrit :
Je suis d'accord et je pense que c'est possible.
Eh bien moi, je te dis que ça ne l'est pas.
Je suis d'accord avec toi, il y a effectivement une protection en écriture
d'un répertoire, ce qui empêche de faire ce dont tu parlais.
rose% mkdir b
rose% cat a > b
zsh: is a directory: b
Ceci dit, tu as raison sur ce point, on *pourrait* le faire, mais ce
serait sans passer par l'API Unix, donc c'est hors propos.
C'est tout à fait exact, si on s'interdit l'accés direct aux inodes
(comme avec fsdb) il n'est pas possible de transformer un fichier standard
en répertoire, etc. donc la cohérence du système est préservée.
Enfin sur le point qui était évoqué au début, il reste vrai que dans le
système de fichiers il y a une certaine uniformité entre fichier et
répertoire, tandis que la partie cachée par le système mais fondamentale, est
les inodes.
Bon, donc pour résumer: comme tout est fichier les répertoires sont donc
des fichiers, sauf que c'est pas vraiment des fichiers.
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
Michel Talon , dans le message <41363e37$0$26998$, a écrit :
Je suis d'accord et je pense que c'est possible.
Eh bien moi, je te dis que ça ne l'est pas.
Je suis d'accord avec toi, il y a effectivement une protection en écriture d'un répertoire, ce qui empêche de faire ce dont tu parlais.
rose% mkdir b rose% cat a > b zsh: is a directory: b
Ceci dit, tu as raison sur ce point, on *pourrait* le faire, mais ce serait sans passer par l'API Unix, donc c'est hors propos.
C'est tout à fait exact, si on s'interdit l'accés direct aux inodes (comme avec fsdb) il n'est pas possible de transformer un fichier standard en répertoire, etc. donc la cohérence du système est préservée. Enfin sur le point qui était évoqué au début, il reste vrai que dans le système de fichiers il y a une certaine uniformité entre fichier et répertoire, tandis que la partie cachée par le système mais fondamentale, est les inodes.
Bon, donc pour résumer: comme tout est fichier les répertoires sont donc des fichiers, sauf que c'est pas vraiment des fichiers.
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
