J'ai installé la même distribution sur 2 pc différents;
quand je fais un md5sum de certains fichiers (ex: chmod)
la somme de contrôle n'est pas la même sur les 2 pc alors
que la taille est la même.
Je pensais que, en cas d'intrusion par exemple, il suffirait
(à défaut de réinstaller) de 'réinjecter' les fichiers altérés,
au moins momentanément... et le temps de faire un premier état
des lieux.
Sont-ils différents ('recompilés' en fonction de la machine hôte)
bien qu'ayant la même taille ?
Si c'est le cas, la méthode du contrôle d'intégrité ne peut-elle
s'appliquer qu'en comparant les sommes de contrôle dans le temps
(entre le moment de la 1ère installation et le moment présent) ?
Si on 'injecte' un fichier d'une autre installation (mais de la
même distribution sur un autre pc), que va-t-il se passer ?
Ce ne sont pas des fichiers copiés de l'un à l'autre ? non
Dans ce cas, c'est peut-être normal: il se peut que la distribution installe des fichiers différents, en fonction du CPU de la machine cible. je l'ai envisagé (voir mon premier message)
Mais, dans ce cas, il me semble extrèmement douteux qu'il n'y ait qu'un seul octet qui diffère. Pour le savoir, demande des infos sur les fichiers en question. readelf est fait pour celà: readelf -h <le_fichier> ou readelf -h -V <le_fichier> voire readelf -a <le_fichier>
En comparant les deux, tu sauras si c'est la même version de l'executable ou pas. Si ce sont les mêmes versions, regarde ou se trouve l'offset en question: readelf -h -l -S <le_fichier> Si tu ne sais pas interpréter ce dernier résultat, poste le, je te dirais ce que j'en pense.
En suivant tes conseils, détail de mes manips sur le fichier 'cat' par exemple (cat est la version d'un des pc et cat2 est la version de l'autre pc):
il y a donc bien 2 valeurs différentes calculées avec le même pc (les calculs donnent toujours les mêmes résultats; ce qui semble exclure un problème dans 'md5sum')
[ temp]$ readelf -h -V cat > hVcat.txt [ temp]$ readelf -h -V cat2 > hVcat2.txt [ temp]$ kompare hVcat.txt hVcat2.txt me dit: les fichiers sont identiques
[ temp]$ readelf -h -l -S cat > hls_cat.txt [ temp]$ readelf -h -l -S cat2 > hls_cat2.txt [ temp]$ kompare hls_cat.txt hls_cat2.txt me dit: les fichiers sont identiques
[ temp]$ readelf -a cat > a_cat.txt [ temp]$ readelf -a cat2 > a_cat2.txt [ temp]$ kompare a_cat.txt a_cat2.txt et là, kompare trouve des différences:
I) Fichier a_cat.txt (résultat de la commande: readelf -a cat > a_cat.txt) (j'ai éliminé les lignes identiques)
[...]
OK, j'en déduis que les différences que tu as sont normales: il semble que la distribution fasse une sorte de "prelink" à l'installation des executables pour pouvoir les charger plus rapidement ensuite. Il se trouve aussi que la distribution utilise une libc optimisée pour le processeur sur lequel elle tourne. Comme les libc sont différentes, les informations du "prelink" le sont également. Tu peux voire celà de façon très explicite ici:
Liste de libraire de la section « .gnu.liblist » contenant 2 entrées: Library Time Stamp Checksum Version Flags
Library Time Stamp Checksum Version Flags 0: libc.so.6 2005-02-06T15:43:05 0x78f0327e 0 0 1: /lib/ld-linux.so.2 2005-02-06T15:43:05 0x80c9b51b 0 0
Tu vois que les librairies de base du système ne sont pas les mêmes (les checksum sont différents). De plus, le fait que les distributions n'aient pas été installées en même temps fait que les timestamp sont différents (ce n'est pas raisonable, une install à 3 h du mat ;-) ).
Si il n'y avait pas de prelink, tu n'aurais sans doute que les librairies de base (libc, ld-linux, ...) qui diffèreraient. Avec le prelink, toutes les librairies et executables ont du subir des modifications à l'install sur chacune des 2 machines.
En conclusion, ce n'est pas un problème hardware mais plutôt une optimisation de la distribution qui cause tes frayeurs.
Je suis perdu et dépassé. Mais j'apprends plein de trucs !
C'est le but, non ? ;-)
On Tue, 22 Feb 2005 13:50:53 +0100, jip wrote:
Ce ne sont pas des fichiers copiés de l'un à l'autre ?
non
Dans ce cas, c'est peut-être normal: il se peut que la distribution
installe des fichiers différents, en fonction du CPU de la machine cible.
je l'ai envisagé (voir mon premier message)
Mais, dans ce cas, il me semble extrèmement douteux qu'il n'y ait qu'un
seul octet qui diffère.
Pour le savoir, demande des infos sur les fichiers en question.
readelf est fait pour celà:
readelf -h <le_fichier>
ou
readelf -h -V <le_fichier>
voire
readelf -a <le_fichier>
En comparant les deux, tu sauras si c'est la même version de l'executable
ou pas. Si ce sont les mêmes versions, regarde ou se trouve l'offset en
question:
readelf -h -l -S <le_fichier>
Si tu ne sais pas interpréter ce dernier résultat, poste le, je te
dirais ce que j'en pense.
En suivant tes conseils, détail de mes manips sur le fichier 'cat' par
exemple (cat est la version d'un des pc et cat2 est la version de l'autre
pc):
il y a donc bien 2 valeurs différentes calculées avec le même pc
(les calculs donnent toujours les mêmes résultats; ce qui semble exclure
un problème dans 'md5sum')
[monpc@linux temp]$ readelf -h -V cat > hVcat.txt
[monpc@linux temp]$ readelf -h -V cat2 > hVcat2.txt
[monpc@linux temp]$ kompare hVcat.txt hVcat2.txt
me dit: les fichiers sont identiques
[monpc@linux temp]$ readelf -h -l -S cat > hls_cat.txt
[monpc@linux temp]$ readelf -h -l -S cat2 > hls_cat2.txt
[monpc@linux temp]$ kompare hls_cat.txt hls_cat2.txt
me dit: les fichiers sont identiques
[monpc@linux temp]$ readelf -a cat > a_cat.txt
[monpc@linux temp]$ readelf -a cat2 > a_cat2.txt
[monpc@linux temp]$ kompare a_cat.txt a_cat2.txt
et là, kompare trouve des différences:
I) Fichier a_cat.txt (résultat de la commande: readelf -a cat > a_cat.txt)
(j'ai éliminé les lignes identiques)
[...]
OK, j'en déduis que les différences que tu as sont normales:
il semble que la distribution fasse une sorte de "prelink" à
l'installation des executables pour pouvoir les charger plus rapidement
ensuite.
Il se trouve aussi que la distribution utilise une libc optimisée pour le
processeur sur lequel elle tourne.
Comme les libc sont différentes, les informations du "prelink" le sont
également. Tu peux voire celà de façon très explicite ici:
Liste de libraire de la section « .gnu.liblist » contenant 2 entrées:
Library Time Stamp Checksum Version Flags
Library Time Stamp Checksum Version Flags
0: libc.so.6 2005-02-06T15:43:05 0x78f0327e 0 0
1: /lib/ld-linux.so.2 2005-02-06T15:43:05 0x80c9b51b 0 0
Tu vois que les librairies de base du système ne sont pas les mêmes (les
checksum sont différents). De plus, le fait que les distributions n'aient
pas été installées en même temps fait que les timestamp sont
différents (ce n'est pas raisonable, une install à 3 h du mat ;-) ).
Si il n'y avait pas de prelink, tu n'aurais sans doute que les librairies
de base (libc, ld-linux, ...) qui diffèreraient. Avec le prelink, toutes
les librairies et executables ont du subir des modifications à l'install
sur chacune des 2 machines.
En conclusion, ce n'est pas un problème hardware mais plutôt une
optimisation de la distribution qui cause tes frayeurs.
Je suis perdu et dépassé. Mais j'apprends plein de trucs !
Ce ne sont pas des fichiers copiés de l'un à l'autre ? non
Dans ce cas, c'est peut-être normal: il se peut que la distribution installe des fichiers différents, en fonction du CPU de la machine cible. je l'ai envisagé (voir mon premier message)
Mais, dans ce cas, il me semble extrèmement douteux qu'il n'y ait qu'un seul octet qui diffère. Pour le savoir, demande des infos sur les fichiers en question. readelf est fait pour celà: readelf -h <le_fichier> ou readelf -h -V <le_fichier> voire readelf -a <le_fichier>
En comparant les deux, tu sauras si c'est la même version de l'executable ou pas. Si ce sont les mêmes versions, regarde ou se trouve l'offset en question: readelf -h -l -S <le_fichier> Si tu ne sais pas interpréter ce dernier résultat, poste le, je te dirais ce que j'en pense.
En suivant tes conseils, détail de mes manips sur le fichier 'cat' par exemple (cat est la version d'un des pc et cat2 est la version de l'autre pc):
il y a donc bien 2 valeurs différentes calculées avec le même pc (les calculs donnent toujours les mêmes résultats; ce qui semble exclure un problème dans 'md5sum')
[ temp]$ readelf -h -V cat > hVcat.txt [ temp]$ readelf -h -V cat2 > hVcat2.txt [ temp]$ kompare hVcat.txt hVcat2.txt me dit: les fichiers sont identiques
[ temp]$ readelf -h -l -S cat > hls_cat.txt [ temp]$ readelf -h -l -S cat2 > hls_cat2.txt [ temp]$ kompare hls_cat.txt hls_cat2.txt me dit: les fichiers sont identiques
[ temp]$ readelf -a cat > a_cat.txt [ temp]$ readelf -a cat2 > a_cat2.txt [ temp]$ kompare a_cat.txt a_cat2.txt et là, kompare trouve des différences:
I) Fichier a_cat.txt (résultat de la commande: readelf -a cat > a_cat.txt) (j'ai éliminé les lignes identiques)
[...]
OK, j'en déduis que les différences que tu as sont normales: il semble que la distribution fasse une sorte de "prelink" à l'installation des executables pour pouvoir les charger plus rapidement ensuite. Il se trouve aussi que la distribution utilise une libc optimisée pour le processeur sur lequel elle tourne. Comme les libc sont différentes, les informations du "prelink" le sont également. Tu peux voire celà de façon très explicite ici:
Liste de libraire de la section « .gnu.liblist » contenant 2 entrées: Library Time Stamp Checksum Version Flags
Library Time Stamp Checksum Version Flags 0: libc.so.6 2005-02-06T15:43:05 0x78f0327e 0 0 1: /lib/ld-linux.so.2 2005-02-06T15:43:05 0x80c9b51b 0 0
Tu vois que les librairies de base du système ne sont pas les mêmes (les checksum sont différents). De plus, le fait que les distributions n'aient pas été installées en même temps fait que les timestamp sont différents (ce n'est pas raisonable, une install à 3 h du mat ;-) ).
Si il n'y avait pas de prelink, tu n'aurais sans doute que les librairies de base (libc, ld-linux, ...) qui diffèreraient. Avec le prelink, toutes les librairies et executables ont du subir des modifications à l'install sur chacune des 2 machines.
En conclusion, ce n'est pas un problème hardware mais plutôt une optimisation de la distribution qui cause tes frayeurs.
Je suis perdu et dépassé. Mais j'apprends plein de trucs !
C'est le but, non ? ;-)
jip
Je suis perdu et dépassé. Mais j'apprends plein de trucs !
C'est le but, non ? ;-)
merci l'Indien (et aux autres) c'était un vrai cours complet.
moralité (au cas particulier): - faire des copies des fichiers sensibles dès la fin de l'install A PARTIR du pc lui-même (et les graver pour que le support soit sûr); ces copies pourront servir: - à des contrôles d'intégrité via md5sum - à des (éventuelles) réparations de secours - se méfier des différences entre pc, même avec la même distribution !!!
En passant: à part ces interrogations sur l'Aurox 10.1: très bonne distribution: c'est la première fois que tout fonctionne du premier coup (son, vidéo, réseau, gravage...); très stable, propre, bien francisée: du très beau boulot.
bonne journée, jip
Je suis perdu et dépassé. Mais j'apprends plein de trucs !
C'est le but, non ? ;-)
merci l'Indien (et aux autres)
c'était un vrai cours complet.
moralité (au cas particulier):
- faire des copies des fichiers sensibles dès la fin de l'install A PARTIR
du pc lui-même (et les graver pour que le support soit sûr); ces copies
pourront servir:
- à des contrôles d'intégrité via md5sum
- à des (éventuelles) réparations de secours
- se méfier des différences entre pc, même avec la même distribution !!!
En passant: à part ces interrogations sur l'Aurox 10.1:
très bonne distribution:
c'est la première fois que tout fonctionne du premier coup
(son, vidéo, réseau, gravage...); très stable, propre, bien francisée:
du très beau boulot.
Je suis perdu et dépassé. Mais j'apprends plein de trucs !
C'est le but, non ? ;-)
merci l'Indien (et aux autres) c'était un vrai cours complet.
moralité (au cas particulier): - faire des copies des fichiers sensibles dès la fin de l'install A PARTIR du pc lui-même (et les graver pour que le support soit sûr); ces copies pourront servir: - à des contrôles d'intégrité via md5sum - à des (éventuelles) réparations de secours - se méfier des différences entre pc, même avec la même distribution !!!
En passant: à part ces interrogations sur l'Aurox 10.1: très bonne distribution: c'est la première fois que tout fonctionne du premier coup (son, vidéo, réseau, gravage...); très stable, propre, bien francisée: du très beau boulot.
bonne journée, jip
GERBIER Eric
jip wrote:
Je suis perdu et dépassé. Mais j'apprends plein de trucs !
En passant: à part ces interrogations sur l'Aurox 10.1: très bonne distribution: c'est la première fois que tout fonctionne du premier coup (son, vidéo, réseau, gravage...); très stable, propre, bien francisée: du très beau boulot.
il me semble que l'aurox utilise le systeme de paquetage rpm si tu veux controler l'integrité de tes paquetages : rpm -Va
jip wrote:
Je suis perdu et dépassé. Mais j'apprends plein de trucs !
En passant: à part ces interrogations sur l'Aurox 10.1:
très bonne distribution:
c'est la première fois que tout fonctionne du premier coup
(son, vidéo, réseau, gravage...); très stable, propre, bien francisée:
du très beau boulot.
il me semble que l'aurox utilise le systeme de paquetage rpm
si tu veux controler l'integrité de tes paquetages :
rpm -Va
Je suis perdu et dépassé. Mais j'apprends plein de trucs !
En passant: à part ces interrogations sur l'Aurox 10.1: très bonne distribution: c'est la première fois que tout fonctionne du premier coup (son, vidéo, réseau, gravage...); très stable, propre, bien francisée: du très beau boulot.
il me semble que l'aurox utilise le systeme de paquetage rpm si tu veux controler l'integrité de tes paquetages : rpm -Va
