Enoch a écrit 73 commentaires

Effectivement, je n'avais pas pris en compte la problématique du vieux paquet officiel avec un faille de sécu.

Mais dans ce cas le problème ne viendrais il pas plutôt de la "non-expiration" de la signature des paquets ?

Quoi qu'il en soit, ça serais aussi bien de signer les métadatas, on jamais trop prudent ...

"Connaissant la sensibilité et l'importance de cette interface dire que l'attaque est impossible est un tantinet exagéré."
C'est effectivement impossible est un peu exagéré ...

mais ce que je voulais dire surtout c'est
que dans ce cas précis (ajout d'un paquet modifié, et donc non-signé avec la clé de la distrib, en dépendance a un autre paquet) le système de sécurité par signature des paquets fonctionne ...

Après je ne dit pas que le système en question est parfait (même si ma formulation précédente peut le laisser penser ...).

Ces questions sont intéressantes et il y a effectivement pas mal de choses à faire pour améliorer les systèmes existants mais pour ce qui est de la non-signature des métadonnées, ça me semble pas si dangereux que ça.

Il reste le cas mentionné plus haut ou l'on peut forcer l'installation d'un ancien paquet signé comportant un faille de sécu connue ... mais dans ce cas le problème me semble plus en rapport avec le point précédent ("la signature cryptographique d'un paquet n'a pas de date d'expiration").


"Un utilisateur lassé par les message de sécurité qui clique par réflexe ou sans lire le message, c'est pas vraiment rare comme situation."
C'est ce que j'indiquais par "bug au niveau de l'interface chaise-clavier" ...

Mais je ne pense pas que ce soit au système de paquetage d'empêcher un utilisateur d'installer un paquet non signé.

Il me semble que c'est quand même à la charge de l'utilisateur/administrateur de faire un minimum attention à ce qu'il fait sur son système ...

Surtout que dans certains cas ça peut être utile de pouvoir forcer ce genre d'action (je pense notamment à certains pilotes fournis sur CD en rpm avec du matos serveur qui n'est pas forcément signé).

Donc je ne suis pas sûr que de bloquer complètement ce genre d'actions soit une solution (bon là il n'est plus vraiment question de mise à jour ... donc pas forcément contradictoire avec ce que tu dis)

"* "ah ouais, nous on fait des solutions techniques bétons pour que l'utilisateur ne soit pas emmerdé. Théoriquement, c'est sans faille, prouvé et tout."
* "Comment ça l'utilisateur risque de pas se comporter comme on veut ? On l'emmerde l'utilisateur, c'est son problème la sécurité ! Nous on fait des solutions techniques"
* "Oui, parfaitement, pour que l'utilisateur ne soit pas emmerdé!"

Il y a comme une contradiction dans un sens ..."

Pour moi le système de signature des paquet sert surtout à certifier que le paquet que l'on installe n'a pas été modifié pour rajouter un rootkit, trojan ou autre. C'est pas spécialement conçut pour rendre le système de paquet plus user-friendly mais pour le sécuriser.

"- Les attaques par modification des métadonnées qui deviennent possibles si les gestionnaires de paquets ne signent pas cryptographiquement le fichier racine des métadonnées de paquets. Dans ce cas c'est encore plus simple pour l'attaquant. Il lui suffit de modifier les métadonnées des paquets pour indiquer une nouvelle dépendance qui "embarquera" son logiciel trojané lors de toute nouvelle mise à jour demandée par le client. Par exemple il indiquera dans les métadonnées de tous les logiciels KDE que ces paquets dépendent du paquet "toto". Quand le client fera une mise à jour quelconque d'un logiciel KDE alors "toto" sera installé également.
Encore une fois cette attaque est possible car l'attaquant a le contrôle d'un miroir."

Dans ce cas, le fameux paquet "toto" pleins de de vilains malwares n'est pas signé donc le gestionnaire de paquets affichera un avertissement de sécurité ... du coup ce genre d'attaque ne me semble pas possible avec les systèmes actuels de signature de paquets (sauf dans le cas d'un bug au niveau de l'interface chaise-clavier) ...

Évidemment ça impacte pas mal les perf de chiffrer tout les FS, mais dans ce cas précis c'est pas vraiment destiné à faire tourner sur un portable avec 512Mo de RAM.

C'est une distrib plus orientée serveur, l'impact au niveau perf est moindre sur un gros serveur ...

De toutes façons, je ne pense pas que ce soit le mode d'installation par défaut ...

Alors pour la solution de virtualisation, c'est du XEN (en para-virtualisation ou en full-virtualisation).

Pour ce qui est de libvirt, en gros c'est une API qui permet l'administration des machines virtuelles à distance notamment avec une IHM dans le genre de la console VMware (http://virt-manager.et.redhat.com)

Évidemment, vu comme ça c'est un peu moins user firendly ... je pense que ça mérite de prendre le temps d'installer yum et createrepo, c'est qd même pratique ... m'enfin après c'est toi qui voit ...

En tout cas je pense que tu doit pouvoir t'en sortir avec l'option --requires de rpm :

Exemple avec le paquet tomcat :

rpm -q --requires -p tomcat5-5.5.17-8jpp.2.i386.rpm
/bin/sh
/bin/sh
/bin/sh
/bin/sh
/bin/sh
config(tomcat5) = 0:5.5.17-8jpp.2
jakarta-commons-daemon >= 1.0.1
jakarta-commons-launcher >= 0:0.9
java-gcj-compat >= 1.0.31
java-gcj-compat >= 1.0.31
jndi-ldap
jpackage-utils >= 0:1.6.0
libc.so.6
libc.so.6(GLIBC_2.1.3)
libdl.so.2
libgcc_s.so.1
libgcc_s.so.1(GCC_3.0)
libgcj_bc.so.1
libm.so.6
libpthread.so.0
librt.so.1
libz.so.1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rtld(GNU_HASH)
tomcat5-common-lib = 0:5.5.17-8jpp.2
tomcat5-common-lib = 0:5.5.17-8jpp.2
tomcat5-server-lib = 0:5.5.17-8jpp.2
tomcat5-server-lib = 0:5.5.17-8jpp.2
xerces-j2 >= 0:2.7.1
xml-commons-apis >= 1.3

+1

Je pense aussi à un pb matériel, il y a de grandes chances que tu ne puisse pas réparer le système de fichiers.

Tu peux toujours essayer ça :
e2fsck -cp /dev/hda2

Par contre y a des chances que ça dure un bon moment, et c'est absolument pas garanti que tu puisse récupérer tes données.
Et si ton disque est effectivement en train de décéder, il est possible que ça l'achève complètement ... mais dans ta situation, je pense que t'as plus gd choses à perdre ...



man e2fsck :

-c Cette option oblige e2fsck à exécuter le programme badblocks(8) pour trouver les blocs défectueux du système de fichiers. Ils seront alors marqués comme défectueux et ajoutés à l’inode des blocs défectueux.

-p Répare automatiquement (NdT : en anglais «preen» signifie lisser) le système de fichiers sans poser la moindre question.

Au temps pour moi, d'autant plus que j'ai lu un poil trop vite, il était bien question des version antérieur à la v4 dans la phrase précise que j'ai cité :
"Les vieux modem sagem et les freebox < v4 ont ete remplacées gratuitement. Il fallait juste attendre... "

J'étais donc complètement hors sujet avec mon histoire de passage de v4 à v5 ... désolé.

>"Les vieux modem sagem et les freebox < v4 ont ete remplacées gratuitement. Il fallait juste attendre... "

C'est marrant, moi le passage de la freebox V4 à la V5 m'a couté 90€ et l'annulation de mon ancienneté ...

Le changement est gratuit uniquement si ton ancienneté est suffisante pour que les frais tombent à 0€ (à moins qu'il y ai un truc que j'ai raté)

Damned ... j'ai été pris de vitesse ...

Je me contenterais donc d'un lien supplémentaire : http://www.lesechos.fr/info/innovation/4648995.htm?xtor=RSS-(...)

Apparemment, ils ont le soutiens de la FSF.

ça fonctionne très bien sous Linux le 802.11g

après sur certaines distrib, il faut installer un paquet supplémentaire (me rappel plus du nom) pour prendre en charge le WPA ...

Sauf qu'on est que Jeudi ...

Faudrait peut être demander à Cannonical de faire leurs releases que le Vendredi rapport aux Trolls sur LinuxFR toussa ...

Je suis d'accord sur le côté valorisant pour Framasoft, par contre je trouve dommage le "free Copyright © 2008" en bas de chaque page alors qu'il s'agit de copier-coller des articles de Framasoft.

Je ne pense pas que ce soit fait intentionnellement, vu les efforts fait pour bien mettre en avant l'origine de leurs articles avec des liens vers Framasoft mais la licence n'est pas respectée :

Extrait de la licence Attribution-Share Alike 2.0 Generic :

"Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one."

Y a le même genre de restriction dans la LGPL il me semble.


M'enfin la démarche reste "honorable" malgré tout ...

> rsyncd pourrait aussi etre lancer en standalone ( avant xinetd )
Effectivement, je commence à envisager cette solution ... mais ça voudrait dire qu'on ne peux plus utiliser xinetd sans risquer ce genre d'emmerdes, c'est quand même dommage, c'est pratique xinetd ...

> le but de rpc/portmap est de pouvoir se connecter a un service dont le numero de port n'est pas connu à l'avance.
D'accord, mais ce que je ne comprends pas bien c'est pourquoi il utilise des ports inférieurs à 1024 qui sont normalement réservés ...

Je vais continuer à chercher de mon côté et au passage me documenter sur le fonctionnement de RPC/Portmap, n'ayant que des connaissance assez superficielles dessus, ça ne me fera pas de mal ...

Il doit quand même bien exister un moyen de régler ce problème ... je ne suis pas le seul à être confronté à ce genre de "conflit", sinon un projet comme portreserve n'aurait pas de raison d'être...

Apparemment il lui manquait la ligne "Greeter=", je ne sait pas si GDM est capable de la trouver tout seul si on omet l'option ... je peux pas faire de test, je suis au taf ... je suis pas sur que les utilisateurs apprécie que je fasse des crash-tests gdm pendant qu'ils bossent ;)

En tout cas, il me semble que /usr/lib/gdm/gdmlogin correspond à la version "moche" de gdm (sans thèmes et autres fioritures) qui est souvent utilisé pour les connexion distantes XDMCP vu que c'est moins lourd.

Essaye avec Greeter=/usr/lib/gdm/gdmgreeter ça devrait être plus joli, ou ça va planter à nouveau si le problème viens de gdmgreeter ...

(Si tu ne connait pas, tu peux relancer ton interface graphique avec ctrl+alt+backspace, par contre si tu a une session ouverte ça va te la fermer un poil violemment, si tu des trucs en cours, ferme les appli et enregistre ton boulot avant ...)

Merci pour ta réponse, mais ça ne règle pas mon problème ...

Le problème c'est que le démon en question (et les autres utilisant rpc comme mountd) se voit attribuer un port par rpc et donc risque à chaque reboot de la machine d'utiliser un port normalement réservé à un autre démon comme c'est arrivé avec rsync.

En changeant le port de rsyncd, le problème reste le même, le nouveau port risque également d'être occupé par un démon géré par rpc ...

>Le premier logiciel qui listen sur ce port gagne
justement, vu que rsyncd est lancé à la demande par xinetd, il se lance forcément après les démons gérés par rpc. Donc c'est toujours lui qui perd à ce petit jeu.

Pour moi la solution serait de paramétrer rpc pour exclure une plage de ports ou certains ports précis comme le permet portreserve.
Mais je recherche une façon de faire ça qui n'implique pas d'installer un paquet potentiellement instable (apparemment en version 0.0.0-6 actuellement)

Description du paquet portserv :
"The portreserve program aims to help services with well-known ports that lie in the bindresvport() range (currently 600-1023). It prevents programs requesting a port to the libc from occupying a real service's port by occupying it itself, until the real service tells it to release the port (generally in its init script). "

C'est précisément ce que je cherche à faire, mais sans utiliser portserve.

Vu le nombre de ports dispo, la probabilité que cet incident se reproduise est très faible mais ça me déplaît fortement d'avoir cette épée de damoclès au dessus de la tête ...

J'ai pas de Lenny d'installé pour l'instant donc je peux pas regarder à quoi ressemble le gdm.conf ... tu te rappelle ce que tu à modifié ?

Quand tu parle de "changer l'apparence" de gdm, t'as fait quoi plus précisément (simple modif de paramètres, install de packages de thèmes, ajout de thèmes manuels, ...) ?

Histoire de contraster un peu avec les différentes critiques (constructives mais néanmoins négatives), j'ai noté un gros point positif au niveau des performances de l'ensemble.

Jusqu'à présent les dépêches/journaux comportant beaucoup de commentaires/trolls ramaient sévère rendant la lecture des longs argumentaires/trolls assez pénible (défilement ultra saccadé, temps de chargements des pages rébarbatif )

Et avec cette nouvelle version, ça tourne au poil, le défilement est fluide, c'est réactif ... c'est génial :)


D'une façon générale je trouve que tout ça est plein de bonne idées comme la notion d'intérêt ou la possibilité de noter tous les contenus.

Et ça fait du bien un peu de changement, ça évite de tomber dans la routine ...

Même si je partage l'avis de nombreux autres concernant le côté bordélique de la page d'accueil, dans l'ensemble le changement est positif pour moi ...

Il reste évidemment quelques bugs à corriger et quelques ajustements et/ou habitudes à prendre concernant les nouveautés.

Quoi qu'il en soit, c'est de l'excellent travail, merci beaucoup pour vos efforts et votre implication.

Je pense que tu aurais pu t'éviter pas mal de désagréments en y allant par étapes et en utilisant aptitude au lieu d'apt-get (ce qui est d'ailleurs recommandé par les notes de publications de Etch) :

- Mise à jour si nécessaire de ta Etch histoire de partir sur de bonnes bases.
- Ajout des dépôts Lenny en plus de ceux de Etch dans ton source.list (ça peut être utile pour revenir à la version précédente d'un paquet en cas de probème)
- aptitude update puis aptitude upgrade (pour mettre à jour les paquets installés sans en installer de nouveaux ou en supprimer)
- Un petit reboot
- Si ça n'a pas été fait par l'upgrade : aptitude install du kernel de Lenny (en gardant bien l'ancien pour pouvoir rebooter dessus en cas de pb) suivi d'un reboot.
- Et enfin un aptitude dist-upgrade (ou plusieurs selon ce qui reste à mettre à jour, dans certains cas il faut rebooter après le dist-upgrade pour pouvoir installer la suite, genre après la mise à jour d'udev par exemple).

C'est un peu plus long mais je n'ai jamais eu de mauvaises surprises avec cette méthode (tirée en grande partie des recommandation des releases notes de la distrib).

Le plus simple dans ton cas aurait quand même été d'installer directement avec un CD Lenny comme dit plus haut ...

Releases notes de Etch.
http://www.debian.org/releases/stable/i386/release-notes/ch-(...)


Au passage je reviens rapidement sur un petit détail :

>Gnome n'arrivait pas à lancer le gestionnaire de connexion (vous savez, le truc ou on rentre son login et mdp pour lancer l'OS).

Alors pour précision ce n'est pas gnome qui lance le gestionnaire de connexion (probablement GDM dans ton cas) mais l'inverse, cad gestionnaire de connexion lance ton gestionnaire de fenêtre (Gnome ou autre ...).

Ayant déjà eu le soucis à maintes reprises en testing (en stable aussi mais c'est moins fréquent).

C'est souvent au niveau du démarrage de xorg que ça bloque à cause d'un module compilé pour l'ancienne version du kernel (genre le pilote nvidia qui ne "marche plus" suite à une mise à jour de kernel, il faut alors recompiler le module en relançant le script d'install).

... scan le résultat et envoi l'image bmp en pièce jointe par mail.

Si si, je vous assure, ça existe ... on a le cas de temps en temps au boulot.

Si le câble est débranché, le ping ne te renvoi rien pdt un moment puis te met "Destination Host Unreachable" quand le timeout est écoulé.

Une bonne façon de tester ça est de passer en commande (avec Ctrl+Alt+F1, ça ne fonctionne pas avec un terminal graphique)

Une fois sur la console tu débranche le câble, il devrait t'afficher "skge eth0: Link is down" et quand tu rebranche "skge eth0: Link is up at 1000 Mbps, ..."

Si rien ne s'affiche essaye sur l'autre interface réseau de la carte mère et vérifie que l'autre extrémité du câble est bien branché (on sait jamais, il suffit d'une prise RJ45 un peu foireuse ...)

Petite précision : j'ai aussi une Marvell Yukon 88E8001/8003/8010 PCI Gigabit sur ma carte mère et elle fonctionne parfaitement bien sous debian testing sans avoir à installer un pilote particulier. Ce qui confirme ce que tu à pu voir avec lsmod ...

Effectivement tout à l'air bien paramétré mais il me semble qu'il y a deux interfaces réseau sur cette carte mère. Il est possible que ton interface eth0 corresponde à la carte nforce et non pas à la Marvell.

Essaye de te brancher sur l'autre interface pour voir si le ping passe.

Pour "partager" l'accès internet de pc1 il faut activer le routage et le masquerading :

Pour le routage, il faut éditer le fichier /etc/network/option et tu met ip_forward=yes au lieu de ip_forward=no

Pour le masquerading (en supposant que eth0 est la carte reliée au net) :

# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# iptables-save