"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.
[^] # Re: Modif de métadonnées
Posté par Enoch (site web personnel) . En réponse au journal La sécurité des gestionnaires de paquets. Évalué à 1.
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.