Commentaires sur : Fedora12 + PackageKit : Insecure (ou pas) http://www.indahax.com/adminsys/fedora12-packagekit-insecure-ou-pas Thu, 14 Jul 2011 13:50:43 +0000 hourly 1 http://wordpress.org/?v=3.2.1 Par : Marc http://www.indahax.com/adminsys/fedora12-packagekit-insecure-ou-pas/comment-page-1#comment-29 Marc Fri, 20 Nov 2009 12:05:52 +0000 http://www.indahax.com/?p=391#comment-29 Salut Pierre, Excellent ton article, j'ai envie de dire comme d'habitude. Je vois bien la logique recherchée avec packagekit, dans les grosses boîtes où les métiers sont très segmentés on a souvent les admin sys mais également des équipes spécialisées (hosting, dba, production, etc..) et chacun d'entre eux a des besoins en logiciels particuliers. Que ces équipes puissent installer leurs logiciels sans faire appel aux admin sys est clairement un gain en productivité. Je rejoins le point de vue selon lequel ceci doit être le plus restrictif possible au risque de se retrouver avec un joyeux bordel ;). À la prochaine, Marc. Salut Pierre,
Excellent ton article, j’ai envie de dire comme d’habitude.
Je vois bien la logique recherchée avec packagekit, dans les grosses boîtes où les métiers sont très segmentés on a souvent les admin sys mais également des équipes spécialisées (hosting, dba, production, etc..) et chacun d’entre eux a des besoins en logiciels particuliers. Que ces équipes puissent installer leurs logiciels sans faire appel aux admin sys est clairement un gain en productivité.
Je rejoins le point de vue selon lequel ceci doit être le plus restrictif possible au risque de se retrouver avec un joyeux bordel ;) .
À la prochaine,
Marc.

]]> Par : Pierre http://www.indahax.com/adminsys/fedora12-packagekit-insecure-ou-pas/comment-page-1#comment-27 Pierre Thu, 19 Nov 2009 11:10:49 +0000 http://www.indahax.com/?p=391#comment-27 En effet tu joues <strong>beaucoup</strong> sur les mots. Quand je parlais des problèmes d'administration, je sous-entendais le problème d'installation de logiciel, de place, etc. Donc peu importe si *la faille* permet de mettre 20 go sur / ,ce qu'il faut surtout retenir c'est que ce privilège est accessible lorsque l'on a une console graphique ou un terminal, et pour rooter un serveur quand on a un accès physique, il y a bien plus simple. Et concernant mon "sophisme" j'ai bien précisé qu'il restait à confirmer. En effet tu joues beaucoup sur les mots. Quand je parlais des problèmes d’administration, je sous-entendais le problème d’installation de logiciel, de place, etc. Donc peu importe si *la faille* permet de mettre 20 go sur / ,ce qu’il faut surtout retenir c’est que ce privilège est accessible lorsque l’on a une console graphique ou un terminal, et pour rooter un serveur quand on a un accès physique, il y a bien plus simple.

Et concernant mon « sophisme » j’ai bien précisé qu’il restait à confirmer.

]]> Par : Michael http://www.indahax.com/adminsys/fedora12-packagekit-insecure-ou-pas/comment-page-1#comment-26 Michael Thu, 19 Nov 2009 10:55:52 +0000 http://www.indahax.com/?p=391#comment-26 Y a un certain nombre de point qui me géne dans ton argumentaire. Le premier, c'est qu'on désactive pas packagekit via la commande que tu donnes, on bloque l'installation de logiciel sans demander de mot de passe, c'est différent. Pour désactiver packageit, il faut simplement le retirer. Mais je joue sur les mots. Ensuite, il ne faut pas un zero day, il suffit juste de profiter du lag entre l'annonce et la mise à disposition de la mise à jour. Parfois, ça peut prendre 3/4 jours, voir plus, tu le sais bien aussi. Enfin, tu conclus un peu vite sur "j'ai installé samba, samba ne s'est pas lancé, donc aucun service vulnérable ne va être lancé". Déja, sur la forme, c'est un sophisme, c'est mal. Ensuite, malgré le fait qu'un warning rpmlint permette de detecter ce genre d'erreur, je doute que tout les paquets soient parfaitement vérifiés et à jour ( sinon, faut m'expliquer pourquoi erlang ne marche pas en f12 malgré les demandes de rebuild pour le nouveau gcc ). Ensuite, un service n'a pas besoin d'être lancé pour être vulnérable, pulseaudio et les exploits kernels récents de brad spencer sont des exemples parfaits, quelqu'un se croyant protegé car il n'a pas pulseaudio, ( au hasard, un user kde ) peut avoir des surprises. Finalement la sécurité, c'est aussi assurer la continuité d'un service, et on a tendance à l'oublier, et donc permettre à quelqu'un d'installer 20 go de paquets sur / via un script shell qui appelle pkcon, tu peux dire ce que tu veux, ça peut faire mal. Les restrictions et blocs reservés à root sur / ne s'appliquent pas, bien sur. Y a un certain nombre de point qui me géne dans ton argumentaire.

Le premier, c’est qu’on désactive pas packagekit via la commande que tu donnes, on bloque l’installation de logiciel sans demander de mot de passe, c’est différent. Pour désactiver packageit, il faut simplement le retirer. Mais je joue sur les mots.

Ensuite, il ne faut pas un zero day, il suffit juste de profiter du lag entre l’annonce et la mise à disposition de la mise à jour. Parfois, ça peut prendre 3/4 jours, voir plus, tu le sais bien aussi.

Enfin, tu conclus un peu vite sur « j’ai installé samba, samba ne s’est pas lancé, donc aucun service vulnérable ne va être lancé ». Déja, sur la forme, c’est un sophisme, c’est mal.

Ensuite, malgré le fait qu’un warning rpmlint permette de detecter ce genre d’erreur, je doute que tout les paquets soient parfaitement vérifiés et à jour ( sinon, faut m’expliquer pourquoi erlang ne marche pas en f12 malgré les demandes de rebuild pour le nouveau gcc ).

Ensuite, un service n’a pas besoin d’être lancé pour être vulnérable, pulseaudio et les exploits kernels récents de brad spencer sont des exemples parfaits, quelqu’un se croyant protegé car il n’a pas pulseaudio, ( au hasard, un user kde ) peut avoir des surprises.

Finalement la sécurité, c’est aussi assurer la continuité d’un service, et on a tendance à l’oublier, et donc permettre à quelqu’un d’installer 20 go de paquets sur / via un script shell qui appelle pkcon, tu peux dire ce que tu veux, ça peut faire mal. Les restrictions et blocs reservés à root sur / ne s’appliquent pas, bien sur.

]]>