La nouvelle distribution Fedora 12 vient de sortir. Elle nous arrive avec une nouvelle fonctionnalité/faille qui fait pas mal de bruit chez les fédoriens en ce moment : PackageKit. Cet outil permet à un utilisateur non privilégié d’installer des packages sur la machine. Alors, Faille ou Fonctionnalité ?
Regardez plutôt comment ça marche :
Voici une commande que j’exécute avec un compte non privilégié dans une console lancé via l’inteface graphique :
[pierre@localhost ~]$ id uid=500(pierre) gid=500(pierre) groups=500(pierre) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [pierre@localhost ~]$ whereis samba samba: [pierre@localhost ~]$ pkcon install samba Simulating install [=========================] Installing packages [=========================] Getting information [=========================] Resolving dependencies [=========================] The following packages have to be installed: samba-common-3.4.2-47.fc12.i686 Files used by both Samba servers and clients Proceed with changes? [N/y] [=========================] Installing [=========================] Waiting for authentication [=========================] Resolving dependencies [=========================] Downloading packages [=========================] Testing changes [=========================] Installing packages [=========================] Scanning applications [=========================] [pierre@localhost ~]$ whereis samba samba: /etc/samba /usr/lib/samba /usr/share/man/man7/samba.7.gz
En voyant ça, on pourrait se dire que cela pose des problèmes de sécurité et d’administration… Un simple utilisateur pourrait installer des logiciels avec des failles de sécurité, écraser, modifier des fichiers de configuration et surtout d’installer des fichiers suid root potentiellement vulnérables (encore faut il trouver LE package). D’ailleurs, sur les mailing list on peut lire plein de choses sympathiques, dont beaucoup dans le genre : FEDORA 12 REMOTE ROOT EXPLOIT, mais sans preuve de concept (oui tout de suite, ça devient beaucoup plus compliqué).
Avant de s’alarmer, il faut relativiser :
- Cette commande n’est utilisable qu’en local (graphique ou console). Si un pirate compromet un compte via SSH ou trouve une faille dans votre serveur Web et exécute des commandes via l’utilisateur Apache : il ne pourra pas installer de logiciels à partir des dépôts.
- Par défaut, seul les packages du repo signés par Fedora sont installables, or, Fedora les tient à jour, il faudrait donc un 0-day pour rooter le serveur (ce qui complique beaucoup la chose).
- J’ai remarqué en installant samba, que le service n’était pas lancé par défaut, il est donc impossible de lancer directement un service vulnérable via cette commande (à confirmer).
- Et enfin, Fedora c’est plutôt une distribution de test (2 ou 3 nouvelles versions / an), de bureautique et pas trop utilisé en prod, ils ont intégré ce package afin de simplifier la vie des utilisateurs.
La commande pour désactiver packagekit est la suivante :
pklalockdown --lockdown org.freedesktop.packagekit.package-install
En conclusion, même si un Linuxien élite réussit à trouver un trick pour rooter le serveur via PackageSite, l’impact sera très limité.
Par contre, si ça peut vous rassurer, il est nécessaire d’avoir le mot de passe root pour désinstaller des package 
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.
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.
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.