La différence est que libvirt ne va lister que les choses qui sont managés par libvirt, la ou systemd va lister les choses ou systemd tourne. Cad que si tu lances un container à la main avec lxc, docker ou autre, ça va apparaitre. Il faut voir ça comme un espace de ps pour les containers, la ou libvirt va gérer bien plus de choses et requiert que tout soit fait par le daemon de libvirt.
En ce sens, systemd va être plus léger et offre juste une information qui découle du tracking des processus, information qui est la par design, et parce que ç'est pas trop compliqué de la récolter.
Et je pense que c'est CSv, pas CVS. Mais le changelog semble aussi avoir le souci, vu que ça parle de cvsimport et csvimport. Mais un import cvs dans le cadre de kmymoney n'a pas beaucoup de sens, à mon avis, alors qu'un import csv beaucoup plus.
Y a pas que le support, il y a les certifications. C'est con, mais quand tu va acheter 50 ou 500 serveurs ( car tu négocie en gros tes achats pour avoir des reductions ), tu va vouloir t'assurer que le matos marche au poil, qu'il est testé, et que le support va pas sauter comme ça ( ou que ta carte 1G va pas passer en 100M d'un coup ). Tout comme on ne va pas croire les stickers "supporte linux" sur une carte pci, tu va pas le croire sur un serveur à 5000 boules.
Donc tu passe par des constructeurs qui font des partenariats avec les éditeurs pour la vérif, et des éditeurs qui ont des compétences en internes pour corriger les soucis niveau kernel.
Et c'est pareil pour les logiciels tierces parties, tu veux t'assurer que ça marche, et que ça va pas sauter à une mise à jour mal faite.
Tout ça, c'est visiblement du travail que la communauté du libre ne veux pas faire ( quand je vois par exemple les régressions sur les drivers intels wifi que j'ai eu avant ), tu te dit qu'il faut compter sur autre chose que la bonne volonté, et tu es prêt à payer.
Et des boites comme Suse ou Red hat finance le libre grace à l'argent fait en fournissant ce que les clients demandent.
Et c'est pareil pour les cours et formations, le but est pas "tu as la certif alors tu es un dieu", c'est plus une assurance d'avoir vu le minimum quand tu as pas le temps de vérifier 15 personnes qui passent en presta, etc.
On m'a parlé d'un code python 2.7 qui ne pouvait être exécuté
par un interpréteur 2.8.
Sans doute parce que la version 2.8 de python n'existe pas ?
Python a aussi une politique claire de depreciation, qui va afficher des warnings longtemps à l'avance.
Bien sûr, il n'y à pas que python, si j'en crois apt, lsof
dépend soit de perl < 5.12.3 (sur ma machine actuelle) soit de
libperl4-corelibs-perl
C'est curieux, car lsof est écrit en C. Je vois pas ce que perl vient faire la. Mais dans tout les cas, ça serait sans doute un souci d'ABI, pas d'API.
Dans le cas de systemd, j'ai un gros doute?
Tout comme le kernel. Et le kernel a bien plus de choses qui en dépendent. On a beau dire "les modules proprios sont le mal", le fait est qu'ils existent, que les constructeurs les utilisent, et que ça fait chier de pas avoir d'ABI stable pour les drivers de leur point de vue.
Mais comme c'est Linus qui dit fuck off, on applaudit des 2 mains. Si quelqu'un d'autre le fait avec les mêmes arguments, ça serait anormal, voir même bloquant avant même d'avoir tenté d'étendre quoi que ce soit. J'ai beau tourner ça dans tout les sens, ça reste 2 poids, 2 mesures.
Il y a sans doute une version dans grub, et une dans les BSD, et une sous windows. Bon, peut être readonly pour grub, peut être incomplete pour freebsd et windows.
En fait, le souci a été rapporté plus tôt qu'il y a 4j. Le bug https://bugzilla.redhat.com/show_bug.cgi?id=1141597 date du 14 septembre. Sachant que l'équipe réponds en général sous 24h avec un CVE, je pense que la faille date de ce jour, ce qui a laissé le temps de coordonner , de corriger et de tester le correctif. Ensuite, en effet, la 2eme faille a été bien plus rapide à être corrigé, et je sais que l'équipe a bossé comme des fous sur le sujet.
Il est aussi à noter que l'article dit que CVE-2014-7187 et CVE-2014-7186 sont non publiques, mais il y a une description sur le bugzilla de RH :
Il me semble aussi que postfix n'est pas un vecteur connu ( au contraire de qmail et exim ), car il nettoie les variables comme il faut. Mais je ne trouve rien sur le sujet.
Ça part aussi du principe que l'admin change jamais de boulot, et qu'il n'a jamais personne qui le remplace, et qu'il a jamais une personne pour l'aider qui a son propre jeu de scripts avec des workarounds différents, etc :)
En effet, entres autres. Et je travaille avec du code qui à pas
loin de 10 ans, installé sur des machines dont l'âge varie de 6
ans à dans quelques jours (install et param en cours).
Bien que je préfère ça aussi, je suis parfois hélas obliger de faire face à un monde différent du tien, ou les choses bougent plus vite. Exemple, ruby, ou python. Donc oui, c'est chiant d'avoir des écosystèmes qui bougent, mais c'est le prix à payer pour avoir des améliorations. Et si le libre n'évolue pas, je pense qu'il risque de tomber en désuétude, même sur des domaines ou il est dominant. Exemple, les webmails, les forges, qui ont globalement pris une grande claque via gmail et github ( même si github a aussi bénéficier d'un effet réseau mais pas uniquement ). Je sais que des gens préfèrent jira à bugzilla pour les bugs trackers ( ou confluence à mediawiki, pour les wikis ).
Ensuite, on est pas à l'abri d'une évolution ( genre apache qui a changé son format, chose que j'aurais pas cru possible, surtout si c'est pas pour corriger les fautes de grammaires ).
Enfin, j'ai envie de citer le seul autre outil de journalisation
binaire que j'aie vu, celui de windows. Franchement, pas quelque
chose que j'ai envie de voir arriver sur Linux, vue la galère
que c'est (ou du moins, que c'était à l'époque d'XP) que
d'essayer d'y tirer la moindre information utile
Il y en a d'autres. Par exemple, splunk. Le souci des logs windows, c'est quand même que le contenu ne veut rien dire sauf pour le développeur. Ou alors, c'est l'UI qui est pourri ? Franchement, je t'invite à choper une centos 7 et à jouer avec. mets un serveur ftp, regarde journalctl, etc. Pour ma part, je me demande comment j'ai fait pour me passer de l'option -u.
Je pense que soit tu estimes les logs sont transients, et tu t'en fout de les perdre.
Soit tu estimes qu'ils sont importants, et tu traites ça comme tel ( cad, des backups, ou tu logues en double sur 2 machines, etc ). Et à ce niveau la, journald permet de tirer les logs, ou de les pousser de façon native. On va me dire que les logs non binaire le font aussi, mais c'est un peu moins simple en pratique. En fait, pour la partie "pousser", c'est kifkif.
Tout d'abord pour tirer les logs, car il faut mettre rsync en place pour tirer les logs de façon sécurisé. C'est pas dur, mais c'est un peu chiant si on le fait par ssh ( je passe à chaque fois 5 minutes sur la syntaxe de forcecommand et les options exactes à mettre, donc 4 minutes à retrouver le truc pour les voir ). Ca se fait bien via rsync tout court ( via xinetd par exemple ), mais ç'est en clair, et je suis pas sur que tout le monde soit ok avec ça. On peut monter ça via nfs, ftp, http, etc, mais c'est moins efficace sur des gros fichiers que rsync AMHA.
L'autre souci, c'est la configuration par défaut des distributions et de logrotate. Par défaut sur certaines distribs ( Debian based, Mandriva ), logrotate va renommer les fichiers en utilisant un incrément, ce qui fait qu'un fichier nommé logrotate.2.gz un jour sera logrotate.3.gz plus tard, ce qui est pas terrible pour faire des backups. Il semble que RHEL 7 utilise l'option dateext dans logrotate.conf pour éviter ça, donc on peut éviter ( il semble aussi que ça date de 2007, donc je me prends un peu la honte sur ma demonstration ).
Journald utilise un timestamp ( encodé en hexa , le 3eme champ du nom de fichier cf http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journald-server.c#n273 ) ce qui fait que c'est facile de trier et de retirer les plus anciens. Je regrette ceci dit que le timestamp ne soit pas lisible à l'oeil nu. Mais il a le bon gout d'avoir une taille fixe, ce qui evite des corners cases avec le tri en shell ( genre, oublier de faire un tric sur une valeur numérique au lieu d'une valeur lexicographique, ce qui fait que toto-400 est vu comme avant toto-50, car on compare caractères par caractères ).
Donc rien d'insurmontable bien sur, rien de novateur, mais la force de systemd, c'est aussi d'offrir ça par défaut, ce qui permet de construire par dessus des choses haut niveau réutilisable, et ce qui démocratise la bonne pratique.
Un truc bien fait avec journald, c'est que le logiciel va gérer nativement le faire d'avoir des fichiers de log venant de n'importe ou, car le nommage le permet, et le logiciel en tire parti. On peut tout mettre tel quel dans /var/log/journal, et journal va faire "the right thing". On peut donc suivre les logs sur plusieurs machines, etc, etc. Le nommage des logs classiques implique un post traitement plus complexe, ce qui est faisable encore une fois. Par exemple, splunk, elastic search sont des solutions pour ça qui vont bien au delà de journald. mais qui requiert une infra plus conséquente, la ou journald va juste tirer parti du nommage des fichiers et d'un design simple.
C'est donc vraiment dans l'approche d'offrir un truc parce que c'est facile à faire, une solution intermédiaire entre rien et le truc plus complet et plus compliqué ( un peu comme le protocole de notification de systemd ). Ça règle pas tout les soucis de tout le monde, mais ça peut aider.
Bien sur qu'il vaut mieux plusieurs implémentations, mais l'équipe systemd en a écrit une, il manque plus que les autres pour le faire.
Ensuite, il y a aussi le fait que faire plusieurs implémentations, c'est aussi dupliquer le code, donc c'est pas exactement gratuit en terme de ressources. Si l'unique motivation est d'avoir plusieurs implémentations, ça suffit généralement pas, il y a souvent d'autres raisons ( license, architecture différente, choix d'implémentation, etc ). Sous Linux, on a attendu longtemps d'avoir autre chose que la libjpeg, et je suis pas sur d'avoir vu autre chose que la libpng.
C'est donc arriver par la suite, dans les années 80. Et si je me souviens bien des headers de copyright, les scripts qu'on retrouve au moins sur les distros rpms datent de milieu/fin 90 sur Linux, donc pas très unix à la base.
Ensuite, Apple l'a remplacé du jour au lendemain ( lors de la release 10.4 ). Gentoo l'a remplacé du jour au lendemain ( genre dés le début ). Ubuntu l'a remplacé du jour au lendemain ( même si ils ont eu des journées longues ). Sun l'a remplacé du jour au lendemain ( sur solaris 10 ). Les BSD, qui sont bien plus Unix que Linux par définition n'ont pas sysvinit, sauf erreur de ma part.
Enfin, du jour au lendemain, tu veux sans doute dire "en 2 ou 3 ans".
Et autant que je sache, Solaris a encore le droit de s'appeler Unix, ce que la majorité des distributions Linux n'ont jamais eu le droit. Donc si Solaris et Apple sont assez "Unix" pour l'open group ( que OS X 10.7 avait la certification, et je doute pas que Solaris aussi ), je pense qu'il faut pas être plus royaliste que le roi.
Dans ce cas, tu doit faire que du C ou du perl. Parce que le python, le ruby et le php d'il y a 10 ans, y a des chances que ça marche plus.
je suis d'accord qu'il faut de la stabilité, mais je pense que c'est à la distribution d'assurer ça. Le reste, c'est juste une conséquence de la R&D distribué qu'est le mouvement du logiciel libre. Il y a les outils ou personne n'innove,
Systemd a une page qui liste les interfaces et la promesse de pas les changer, ce qui est largement mieux que la majorité des projets que je connais, même si certains s'en sortent aussi bien voir mieux.
Mais maintenant, je pense qu'on peut pas soutenir les devs kernels qui soutiennent que les interfaces internes du kernel peuvent bouger, alors qu'il y a de la demande pour la stabilité (pour les drivers), que d'autres arrivent à le faire (solaris, windows ), et en même temps réclamer que rien ne change sur les autres projets.
Ça me semblerait juste hypocrite, et je doute qu'une séparation arbitraire il y a un bout de temps entre kernel space et user space soit une raison suffisante pour dire "c'est normal d'être emmerdé pour les drivers, bout de code compilé qui tourne sur ton pc, mais pour les softs en user space, autre truc compilé qui tourne sur ton pc, c'est différent".
Et je pense que le but n'est pas de remplacer init, mais de remplacer les initscripts ( au sens paquet du même nom ). Et en effet, par la suite, d'offrir une API pour gerer la machine tant qu'à faire.
Les initscripts, les trucs qui montent le LVM, lance le réseau, lance les softs, etc. Tout des trucs qui étaient déjà fait à gauche et à droite de façon différente par chaque distro.
Tu donnes l'exemple de la journalisation, mais il faut bien voir que le journal est une conséquence du design et de la position de systemd. Tu voudrais mettre ça en dehors de systemd, mais comment est ce qu'un programme en dehors de systemd accède à stdin et stdout ? Donc une fois que tu te dit "ça serait une idée de choper ça", tu te retrouves à avoir un cache. Et tu te dit "je peux rajouter plus de données". Et ensuite, "je peux sans doute faire des recherches dans ce cache", et le mettre sur le disque et voila, journald dans sa forme actuelle, cad un programme qui va en effet faire le même travail que les fichiers syslog, mais dans une base de données indexé lisible.
Si tu as selinux, alors dhclient va juste avoir le droit de faire ce que la policy dit de faire, ce qui a des chances de grandement limiter les dégats. j'ai pas regardé en détail, mais de ce que je vois aprés 5 minutes d'analyses, c'est quand même limité.
va lister les domaines vers lesquelles dhcp_t peut faire une transition.
sesearch --allow -s dhcpc_t | grep execute
va lister les types que dhclient a le droit d'executer, la majorité sans avoir des droits différents de dhclient lui même ( vu qu'ils sont pas dans la première liste ).
Un rapide examen montre que dhcpc va écrire des fichiers d'un certain type, mais n'a le droit d'execution sur aucun de ceux qu'il va écrire. Donc ça bloque déjà les exploits à base de wget basique. Tu peux sans doute faire un truc avec wget + un interpreteur de commande ceci dit, mais tu sera toujours limité à ce que dhclient peut faire.
A vue de nez, le truc le plus prometteur serait insmod_t, mais je pense que insmod_t ne va pas charger n'importe quel fichier, et surtout pas un fichier que dhclient va écrire, pour cause de mauvais label.
Ensuite, je voit qu'un script pourrait couper le firewall, ce qui est un souci. Le reste, c'est de la manipulation de réseau, ce qui est chiant, mais dans la mesure ou ça implique un dhcp rogue, je pense qu'on peux supposer que le réseau n'a pas besoin d'une faille pour être modifier de façon créative.
Donc voila, je pense que selinux va bloquer assez efficacement la majorité des soucis, même si j'exclue pas qu'un truc passe à travers, ou qu'on puisse enchainer.
Quand à ssh, ça va marcher si le serveur ssh est openssh ou similaire, ie, un serveur ssh avec un shell. Je sais pas ce que ça donnerais sur les implémentations customs d'un serveur pour des besoins spécifiques ( genre github a son propre serveur git en ruby, si je me souviens bien, et ils semblent dire que leur service n'est pas vulnérable https://github.com/blog/1893-security-vulnerability-in-bash-addressed donc je suppose que c'est pareil pour ssh ). Mais je suppose aussi que ce genre d'infrastructure est l'exception plus que la norme.
Ne pas avoir prévu la gestion de la mise en veille/hibernation
pour les points de montage, ça fait fausse note.
En fait, c'est pas la mise en veille le souci, c'est le changement et ou la perte de la connectivité. La mise en veille est juste un déclencheur. Je peux par exemple avoir un point de montage non réseau qui continue de marcher ou qui va dépendre du fait que je retire un cable pendant que le pc est en veille. Ou mettre en veille et revenir dans le même réseau de façon transparente.
Intuitivement, je me dit que ça devrait être fait au niveau du filesystem, mais peut être que les sémantiques et que le code ne permet pas de faire ça de façon optimum.
Perso, j'ai pas de cgi, j'ai mon dhclient qui tourne avec un domaine selinux confiné. Et j'ai pas de serveur git avec forcecommand ( j'ai des rsync par contre, mais ça implique d'avoir la clé à priori ). Donc je vais pas stopper tout pour la mise à jour, je vais finir ma pizza ( au contraire de Linuxfr, qui lui est important )
maintenant, si vous avez gitolite, et que vous êtes dans un hotel chelou rempli de linuxien, ça me parait plus critique que pour moi :)
Pour le moment, le mec a surtout retiré du code, et appliquer des patchs refusés upstream pour musl. L'argument des devs de systemd étant "il faut rajouter le code dans musl", et les devs de musl "il faut rajouter le code partout ailleurs" ( mais bon, y en a qu'un des 2 qui se fait traiter de fachiste pour refuser du code ).
Donc oui, c'est sur qu'en ne faisant que retirer du code d'une vielle version, ça va pas exploser. Bien sur, c'est intenable sur le long terme sauf à ce que rien d'autre ne bouge à coté.
Je suis pas d'accord. Je suis packageur depuis un numbre d'année à 2 chiffres, et j'ai vu les soucis que pose les scripts en bash, à savoir que tout le monde ne maitrise pas le bash, ce qui justement donne des soucis super compliqués.
J'ai donné les exemples de bind, sur debian sur openbsd etc lors des nombreuses discussions sur systemd, mais juste pour montrer les trucs récents sur ansible lié à des fichiers d'init foireux :
Et pourquoi ? parce que les gens qui font les scripts se préoccupent pas des détails comme la synchronisation entre le script et le soft qui est geré, ou des détails comme filer les codes de retour.
Donc je pense que la séparation "j'ai vu comment ça marche, c'est moche", c'est faux. Les conséquences d'avoir du bash à tout les étages sont simple à piger, tu as des scripts dupliqués ( car personne n'envoie les scripts upstream et il y a pas d'unité dans ce que tu fais ), parfois de qualité inégale, du au fait que personne ne peux penser à tout à chaque fois, surtout quand ça requiert des compétences que tout le monde n'a pas ( genre, se préoccuper de l'automatisation, ça te viens pas à l'esprit quand tu es un packageur débutant ). Et tu le voit assez vite quand tu fait du mentoring auprès des nouveaux arrivants.
Ensuite, l'intégration de systemd est plus complexe que celle de sysvinit, mais c'est surtout parce que systemd bouge la ou sysvinit ne bouge pas. mais l'intégration de sysvinit n'etait pas non plus une partie de plaisir y a 6/7 ans quand les gens étaient encore en trian de le faire bouger, et que par exemple, mandriva devait refaire les patchs en bash sur le soft venant de Fedora/RH.
Il faut espérer que systemd va finir par se stabiliser un peu plus et innover moins, pour réduire ta charge de travail.
Sur RHEL 7/Centos 7 et fedora je sais pas combien, les plugins firefox sont restreint via SELinux. Donc si jamais quelqu'un arrive à trouver une faille dans flash et la distribue via un réseau de pub, comme ça arrive souvent, ta clé ssh se fera pas faucher, sauf à contourner SElinux.
( tu peux aussi remplacer "clé ssh" par "fichier de mot de passe firefox" ).
Il me semble aussi qu'il y a eu des choses sur les outils qui font des vignettes, au cas ou tu trouves une clé usb avec un fichier vérolé qui fait planter l'outil de vignette.
Je pense aussi que SElinux permet de s'assurer que le compte guest ( paquet xguest ) est vraiment limité, ce qui sert sur un kiosque.
Il permet également de limiter docker, qui est un outil assez à la mode en ce moment pour les devs ( donc sur un pc personnel ), et je suppose que selinux serviras aussi pour limiter les applications tierces pour ce que Gnome veut faire avec les histoires de sandbox.
[^] # Re: list-machines ?
Posté par Misc (site web personnel) . En réponse à la dépêche systemd versions 212 à 215. Évalué à 8.
La différence est que libvirt ne va lister que les choses qui sont managés par libvirt, la ou systemd va lister les choses ou systemd tourne. Cad que si tu lances un container à la main avec lxc, docker ou autre, ça va apparaitre. Il faut voir ça comme un espace de ps pour les containers, la ou libvirt va gérer bien plus de choses et requiert que tout soit fait par le daemon de libvirt.
En ce sens, systemd va être plus léger et offre juste une information qui découle du tracking des processus, information qui est la par design, et parce que ç'est pas trop compliqué de la récolter.
[^] # Re: Coquille
Posté par Misc (site web personnel) . En réponse au journal KMyMoney 4.8 Beta 1, alias KMyMoney 4.7, est disponible. Évalué à 3.
Et je pense que c'est CSv, pas CVS. Mais le changelog semble aussi avoir le souci, vu que ça parle de cvsimport et csvimport. Mais un import cvs dans le cadre de kmymoney n'a pas beaucoup de sens, à mon avis, alors qu'un import csv beaucoup plus.
[^] # Re: SLES
Posté par Misc (site web personnel) . En réponse au journal Swiss Re migre de Solaris vers Linux, et bientôt Windows vers Linux. Évalué à 10.
Y a pas que le support, il y a les certifications. C'est con, mais quand tu va acheter 50 ou 500 serveurs ( car tu négocie en gros tes achats pour avoir des reductions ), tu va vouloir t'assurer que le matos marche au poil, qu'il est testé, et que le support va pas sauter comme ça ( ou que ta carte 1G va pas passer en 100M d'un coup ). Tout comme on ne va pas croire les stickers "supporte linux" sur une carte pci, tu va pas le croire sur un serveur à 5000 boules.
Donc tu passe par des constructeurs qui font des partenariats avec les éditeurs pour la vérif, et des éditeurs qui ont des compétences en internes pour corriger les soucis niveau kernel.
Et c'est pareil pour les logiciels tierces parties, tu veux t'assurer que ça marche, et que ça va pas sauter à une mise à jour mal faite.
Tout ça, c'est visiblement du travail que la communauté du libre ne veux pas faire ( quand je vois par exemple les régressions sur les drivers intels wifi que j'ai eu avant ), tu te dit qu'il faut compter sur autre chose que la bonne volonté, et tu es prêt à payer.
Et des boites comme Suse ou Red hat finance le libre grace à l'argent fait en fournissant ce que les clients demandent.
Et c'est pareil pour les cours et formations, le but est pas "tu as la certif alors tu es un dieu", c'est plus une assurance d'avoir vu le minimum quand tu as pas le temps de vérifier 15 personnes qui passent en presta, etc.
[^] # Re: Généraliste ?
Posté par Misc (site web personnel) . En réponse au journal Maintenir sa distribution : état des lieux de 0Linux après 4 ans de développement. Évalué à 2.
Les trucs basé sur ostree, comme atomic ?
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 3.
Sans doute parce que la version 2.8 de python n'existe pas ?
Python a aussi une politique claire de depreciation, qui va afficher des warnings longtemps à l'avance.
C'est curieux, car lsof est écrit en C. Je vois pas ce que perl vient faire la. Mais dans tout les cas, ça serait sans doute un souci d'ABI, pas d'API.
Tout comme le kernel. Et le kernel a bien plus de choses qui en dépendent. On a beau dire "les modules proprios sont le mal", le fait est qu'ils existent, que les constructeurs les utilisent, et que ça fait chier de pas avoir d'ABI stable pour les drivers de leur point de vue.
Mais comme c'est Linus qui dit fuck off, on applaudit des 2 mains. Si quelqu'un d'autre le fait avec les mêmes arguments, ça serait anormal, voir même bloquant avant même d'avoir tenté d'étendre quoi que ce soit. J'ai beau tourner ça dans tout les sens, ça reste 2 poids, 2 mesures.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 3.
Il y a sans doute une version dans grub, et une dans les BSD, et une sous windows. Bon, peut être readonly pour grub, peut être incomplete pour freebsd et windows.
[^] # Re: Quelque details
Posté par Misc (site web personnel) . En réponse à la dépêche Une faille nommée « shellshock ». Évalué à 2.
Y a plein de poc sur github :
https://github.com/mubix/shellshocker-pocs
# Quelque details
Posté par Misc (site web personnel) . En réponse à la dépêche Une faille nommée « shellshock ». Évalué à 10.
En fait, le souci a été rapporté plus tôt qu'il y a 4j. Le bug https://bugzilla.redhat.com/show_bug.cgi?id=1141597 date du 14 septembre. Sachant que l'équipe réponds en général sous 24h avec un CVE, je pense que la faille date de ce jour, ce qui a laissé le temps de coordonner , de corriger et de tester le correctif. Ensuite, en effet, la 2eme faille a été bien plus rapide à être corrigé, et je sais que l'équipe a bossé comme des fous sur le sujet.
Il est aussi à noter que l'article dit que CVE-2014-7187 et CVE-2014-7186 sont non publiques, mais il y a une description sur le bugzilla de RH :
https://bugzilla.redhat.com/show_bug.cgi?id=1146791
https://bugzilla.redhat.com/show_bug.cgi?id=1146804
Il me semble aussi que postfix n'est pas un vecteur connu ( au contraire de qmail et exim ), car il nettoie les variables comme il faut. Mais je ne trouve rien sur le sujet.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 3.
Ça part aussi du principe que l'admin change jamais de boulot, et qu'il n'a jamais personne qui le remplace, et qu'il a jamais une personne pour l'aider qui a son propre jeu de scripts avec des workarounds différents, etc :)
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 2.
Bien que je préfère ça aussi, je suis parfois hélas obliger de faire face à un monde différent du tien, ou les choses bougent plus vite. Exemple, ruby, ou python. Donc oui, c'est chiant d'avoir des écosystèmes qui bougent, mais c'est le prix à payer pour avoir des améliorations. Et si le libre n'évolue pas, je pense qu'il risque de tomber en désuétude, même sur des domaines ou il est dominant. Exemple, les webmails, les forges, qui ont globalement pris une grande claque via gmail et github ( même si github a aussi bénéficier d'un effet réseau mais pas uniquement ). Je sais que des gens préfèrent jira à bugzilla pour les bugs trackers ( ou confluence à mediawiki, pour les wikis ).
Ensuite, on est pas à l'abri d'une évolution ( genre apache qui a changé son format, chose que j'aurais pas cru possible, surtout si c'est pas pour corriger les fautes de grammaires ).
Il y en a d'autres. Par exemple, splunk. Le souci des logs windows, c'est quand même que le contenu ne veut rien dire sauf pour le développeur. Ou alors, c'est l'UI qui est pourri ? Franchement, je t'invite à choper une centos 7 et à jouer avec. mets un serveur ftp, regarde journalctl, etc. Pour ma part, je me demande comment j'ai fait pour me passer de l'option -u.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 8.
Je pense que soit tu estimes les logs sont transients, et tu t'en fout de les perdre.
Soit tu estimes qu'ils sont importants, et tu traites ça comme tel ( cad, des backups, ou tu logues en double sur 2 machines, etc ). Et à ce niveau la, journald permet de tirer les logs, ou de les pousser de façon native. On va me dire que les logs non binaire le font aussi, mais c'est un peu moins simple en pratique. En fait, pour la partie "pousser", c'est kifkif.
Tout d'abord pour tirer les logs, car il faut mettre rsync en place pour tirer les logs de façon sécurisé. C'est pas dur, mais c'est un peu chiant si on le fait par ssh ( je passe à chaque fois 5 minutes sur la syntaxe de forcecommand et les options exactes à mettre, donc 4 minutes à retrouver le truc pour les voir ). Ca se fait bien via rsync tout court ( via xinetd par exemple ), mais ç'est en clair, et je suis pas sur que tout le monde soit ok avec ça. On peut monter ça via nfs, ftp, http, etc, mais c'est moins efficace sur des gros fichiers que rsync AMHA.
L'autre souci, c'est la configuration par défaut des distributions et de logrotate. Par défaut sur certaines distribs ( Debian based, Mandriva ), logrotate va renommer les fichiers en utilisant un incrément, ce qui fait qu'un fichier nommé logrotate.2.gz un jour sera logrotate.3.gz plus tard, ce qui est pas terrible pour faire des backups. Il semble que RHEL 7 utilise l'option dateext dans logrotate.conf pour éviter ça, donc on peut éviter ( il semble aussi que ça date de 2007, donc je me prends un peu la honte sur ma demonstration ).
Journald utilise un timestamp ( encodé en hexa , le 3eme champ du nom de fichier cf http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journald-server.c#n273 ) ce qui fait que c'est facile de trier et de retirer les plus anciens. Je regrette ceci dit que le timestamp ne soit pas lisible à l'oeil nu. Mais il a le bon gout d'avoir une taille fixe, ce qui evite des corners cases avec le tri en shell ( genre, oublier de faire un tric sur une valeur numérique au lieu d'une valeur lexicographique, ce qui fait que toto-400 est vu comme avant toto-50, car on compare caractères par caractères ).
Donc rien d'insurmontable bien sur, rien de novateur, mais la force de systemd, c'est aussi d'offrir ça par défaut, ce qui permet de construire par dessus des choses haut niveau réutilisable, et ce qui démocratise la bonne pratique.
Un truc bien fait avec journald, c'est que le logiciel va gérer nativement le faire d'avoir des fichiers de log venant de n'importe ou, car le nommage le permet, et le logiciel en tire parti. On peut tout mettre tel quel dans /var/log/journal, et journal va faire "the right thing". On peut donc suivre les logs sur plusieurs machines, etc, etc. Le nommage des logs classiques implique un post traitement plus complexe, ce qui est faisable encore une fois. Par exemple, splunk, elastic search sont des solutions pour ça qui vont bien au delà de journald. mais qui requiert une infra plus conséquente, la ou journald va juste tirer parti du nommage des fichiers et d'un design simple.
C'est donc vraiment dans l'approche d'offrir un truc parce que c'est facile à faire, une solution intermédiaire entre rien et le truc plus complet et plus compliqué ( un peu comme le protocole de notification de systemd ). Ça règle pas tout les soucis de tout le monde, mais ça peut aider.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 4.
Bien sur qu'il vaut mieux plusieurs implémentations, mais l'équipe systemd en a écrit une, il manque plus que les autres pour le faire.
Ensuite, il y a aussi le fait que faire plusieurs implémentations, c'est aussi dupliquer le code, donc c'est pas exactement gratuit en terme de ressources. Si l'unique motivation est d'avoir plusieurs implémentations, ça suffit généralement pas, il y a souvent d'autres raisons ( license, architecture différente, choix d'implémentation, etc ). Sous Linux, on a attendu longtemps d'avoir autre chose que la libjpeg, et je suis pas sur d'avoir vu autre chose que la libpng.
[^] # Re: Je vais paraître inculte, mais...
Posté par Misc (site web personnel) . En réponse au journal Mettez du Debian et du ArchBSD dans votre FreeBSD : mkjl.sh. Évalué à 6.
C'est quoi le souci de gentoo BSD, en dehors du fait que ça fait pas tourner systemd ( je dit ça juste pour remplir le quota de 80% )
[^] # Re: Surprenant, non ?
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 9.
L'unix de base ( celui des 70s ) n'avait pas l'air d'avoir un système de script d'init, si je regarde le code sur google code
https://code.google.com/p/unix-jun72/source/browse/#svn%2Ftrunk%2Ffs%2Froot%2Fetc
C'est donc arriver par la suite, dans les années 80. Et si je me souviens bien des headers de copyright, les scripts qu'on retrouve au moins sur les distros rpms datent de milieu/fin 90 sur Linux, donc pas très unix à la base.
Ensuite, Apple l'a remplacé du jour au lendemain ( lors de la release 10.4 ). Gentoo l'a remplacé du jour au lendemain ( genre dés le début ). Ubuntu l'a remplacé du jour au lendemain ( même si ils ont eu des journées longues ). Sun l'a remplacé du jour au lendemain ( sur solaris 10 ). Les BSD, qui sont bien plus Unix que Linux par définition n'ont pas sysvinit, sauf erreur de ma part.
Enfin, du jour au lendemain, tu veux sans doute dire "en 2 ou 3 ans".
Et autant que je sache, Solaris a encore le droit de s'appeler Unix, ce que la majorité des distributions Linux n'ont jamais eu le droit. Donc si Solaris et Apple sont assez "Unix" pour l'open group ( que OS X 10.7 avait la certification, et je doute pas que Solaris aussi ), je pense qu'il faut pas être plus royaliste que le roi.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 7.
Dans ce cas, tu doit faire que du C ou du perl. Parce que le python, le ruby et le php d'il y a 10 ans, y a des chances que ça marche plus.
je suis d'accord qu'il faut de la stabilité, mais je pense que c'est à la distribution d'assurer ça. Le reste, c'est juste une conséquence de la R&D distribué qu'est le mouvement du logiciel libre. Il y a les outils ou personne n'innove,
Systemd a une page qui liste les interfaces et la promesse de pas les changer, ce qui est largement mieux que la majorité des projets que je connais, même si certains s'en sortent aussi bien voir mieux.
Mais maintenant, je pense qu'on peut pas soutenir les devs kernels qui soutiennent que les interfaces internes du kernel peuvent bouger, alors qu'il y a de la demande pour la stabilité (pour les drivers), que d'autres arrivent à le faire (solaris, windows ), et en même temps réclamer que rien ne change sur les autres projets.
Ça me semblerait juste hypocrite, et je doute qu'une séparation arbitraire il y a un bout de temps entre kernel space et user space soit une raison suffisante pour dire "c'est normal d'être emmerdé pour les drivers, bout de code compilé qui tourne sur ton pc, mais pour les softs en user space, autre truc compilé qui tourne sur ton pc, c'est différent".
Et je pense que le but n'est pas de remplacer init, mais de remplacer les initscripts ( au sens paquet du même nom ). Et en effet, par la suite, d'offrir une API pour gerer la machine tant qu'à faire.
Les initscripts, les trucs qui montent le LVM, lance le réseau, lance les softs, etc. Tout des trucs qui étaient déjà fait à gauche et à droite de façon différente par chaque distro.
Tu donnes l'exemple de la journalisation, mais il faut bien voir que le journal est une conséquence du design et de la position de systemd. Tu voudrais mettre ça en dehors de systemd, mais comment est ce qu'un programme en dehors de systemd accède à stdin et stdout ? Donc une fois que tu te dit "ça serait une idée de choper ça", tu te retrouves à avoir un cache. Et tu te dit "je peux rajouter plus de données". Et ensuite, "je peux sans doute faire des recherches dans ce cache", et le mettre sur le disque et voila, journald dans sa forme actuelle, cad un programme qui va en effet faire le même travail que les fichiers syslog, mais dans une base de données indexé lisible.
[^] # Re: Il est urgent de mettre à jour
Posté par Misc (site web personnel) . En réponse au journal Mets à jour ton bash. Maintenant.. Évalué à 10.
Si tu as selinux, alors dhclient va juste avoir le droit de faire ce que la policy dit de faire, ce qui a des chances de grandement limiter les dégats. j'ai pas regardé en détail, mais de ce que je vois aprés 5 minutes d'analyses, c'est quand même limité.
sesearch -T --allow -s dhcpc_t | grep type_transition | grep process
va lister les domaines vers lesquelles dhcp_t peut faire une transition.
sesearch --allow -s dhcpc_t | grep execute
va lister les types que dhclient a le droit d'executer, la majorité sans avoir des droits différents de dhclient lui même ( vu qu'ils sont pas dans la première liste ).
Un rapide examen montre que dhcpc va écrire des fichiers d'un certain type, mais n'a le droit d'execution sur aucun de ceux qu'il va écrire. Donc ça bloque déjà les exploits à base de wget basique. Tu peux sans doute faire un truc avec wget + un interpreteur de commande ceci dit, mais tu sera toujours limité à ce que dhclient peut faire.
A vue de nez, le truc le plus prometteur serait insmod_t, mais je pense que insmod_t ne va pas charger n'importe quel fichier, et surtout pas un fichier que dhclient va écrire, pour cause de mauvais label.
Ensuite, je voit qu'un script pourrait couper le firewall, ce qui est un souci. Le reste, c'est de la manipulation de réseau, ce qui est chiant, mais dans la mesure ou ça implique un dhcp rogue, je pense qu'on peux supposer que le réseau n'a pas besoin d'une faille pour être modifier de façon créative.
Donc voila, je pense que selinux va bloquer assez efficacement la majorité des soucis, même si j'exclue pas qu'un truc passe à travers, ou qu'on puisse enchainer.
Quand à ssh, ça va marcher si le serveur ssh est openssh ou similaire, ie, un serveur ssh avec un shell. Je sais pas ce que ça donnerais sur les implémentations customs d'un serveur pour des besoins spécifiques ( genre github a son propre serveur git en ruby, si je me souviens bien, et ils semblent dire que leur service n'est pas vulnérable
https://github.com/blog/1893-security-vulnerability-in-bash-addressed donc je suppose que c'est pareil pour ssh ). Mais je suppose aussi que ce genre d'infrastructure est l'exception plus que la norme.
[^] # Re: Conflicts=sleep.target
Posté par Misc (site web personnel) . En réponse au journal Où systemd résout des problèmes de cifs. Évalué à 8.
En fait, c'est pas la mise en veille le souci, c'est le changement et ou la perte de la connectivité. La mise en veille est juste un déclencheur. Je peux par exemple avoir un point de montage non réseau qui continue de marcher ou qui va dépendre du fait que je retire un cable pendant que le pc est en veille. Ou mettre en veille et revenir dans le même réseau de façon transparente.
Intuitivement, je me dit que ça devrait être fait au niveau du filesystem, mais peut être que les sémantiques et que le code ne permet pas de faire ça de façon optimum.
# pas si validé que ça
Posté par Misc (site web personnel) . En réponse au journal Mets à jour ton bash. Maintenant.. Évalué à 7.
https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c23
Il semblerais que ça ne soit pas fini. Bon, ben j'ai bien fait d'automatiser avec ansible mes upgrades d serveur.
[^] # Re: Whaou
Posté par Misc (site web personnel) . En réponse au journal Où systemd résout des problèmes de cifs. Évalué à 10.
A vue de nez, l'intégration. Cad que je mets mon pc en veille en fermant le capot, ça le fera tout seul.
Bien sur, si systemd l'a fait, alors tu peux le faire aussi en refaisant ce qu'il fait, cad en écoutant les événements en lançant ton truc suite à ça.
[^] # Re: Alternatives
Posté par Misc (site web personnel) . En réponse au journal Mets à jour ton bash. Maintenant.. Évalué à 7.
Sauf à faire pointer sh vers zsh, je pense que ça va pas changer grand chose. J'ai pas testé ce que ça donne avec dash par contre.
# Quitte à citer
Posté par Misc (site web personnel) . En réponse au journal Mets à jour ton bash. Maintenant.. Évalué à 10.
Quitte à pointer vers une ressource du grand satan pousseur de systemd avec un chapeau rouge, autant pointer vers le blog qui explique les détails :
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
Et vers le thread sur oss-sec :
http://www.openwall.com/lists/oss-security/2014/09/24/10
Notamment
http://www.openwall.com/lists/oss-security/2014/09/24/12
Perso, j'ai pas de cgi, j'ai mon dhclient qui tourne avec un domaine selinux confiné. Et j'ai pas de serveur git avec forcecommand ( j'ai des rsync par contre, mais ça implique d'avoir la clé à priori ). Donc je vais pas stopper tout pour la mise à jour, je vais finir ma pizza ( au contraire de Linuxfr, qui lui est important )
maintenant, si vous avez gitolite, et que vous êtes dans un hotel chelou rempli de linuxien, ça me parait plus critique que pour moi :)
[^] # Re: Ah ah
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 6.
Marrant, moi, j'ai un service de base qui va lancer /etc/rc.d/rc.local start. Donc j'aurais tendance à dire que ça marche de base.
( l'unité, c'est /usr/lib/systemd/system/rc-local.service )
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 8.
Pour le moment, le mec a surtout retiré du code, et appliquer des patchs refusés upstream pour musl. L'argument des devs de systemd étant "il faut rajouter le code dans musl", et les devs de musl "il faut rajouter le code partout ailleurs" ( mais bon, y en a qu'un des 2 qui se fait traiter de fachiste pour refuser du code ).
Donc oui, c'est sur qu'en ne faisant que retirer du code d'une vielle version, ça va pas exploser. Bien sur, c'est intenable sur le long terme sauf à ce que rien d'autre ne bouge à coté.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 10.
Je suis pas d'accord. Je suis packageur depuis un numbre d'année à 2 chiffres, et j'ai vu les soucis que pose les scripts en bash, à savoir que tout le monde ne maitrise pas le bash, ce qui justement donne des soucis super compliqués.
J'ai donné les exemples de bind, sur debian sur openbsd etc lors des nombreuses discussions sur systemd, mais juste pour montrer les trucs récents sur ansible lié à des fichiers d'init foireux :
Le fichier de nginx sur ubuntu :
https://github.com/ansible/ansible/issues/9108
le fichier de proftpd
https://github.com/ansible/ansible/issues/9069
https://github.com/ansible/ansible/issues/7918
https://github.com/ansible/ansible/issues/6286
Postgresql :
https://github.com/ansible/ansible/issues/8183
https://github.com/ansible/ansible/issues/7695
Et pourquoi ? parce que les gens qui font les scripts se préoccupent pas des détails comme la synchronisation entre le script et le soft qui est geré, ou des détails comme filer les codes de retour.
Donc je pense que la séparation "j'ai vu comment ça marche, c'est moche", c'est faux. Les conséquences d'avoir du bash à tout les étages sont simple à piger, tu as des scripts dupliqués ( car personne n'envoie les scripts upstream et il y a pas d'unité dans ce que tu fais ), parfois de qualité inégale, du au fait que personne ne peux penser à tout à chaque fois, surtout quand ça requiert des compétences que tout le monde n'a pas ( genre, se préoccuper de l'automatisation, ça te viens pas à l'esprit quand tu es un packageur débutant ). Et tu le voit assez vite quand tu fait du mentoring auprès des nouveaux arrivants.
Ensuite, l'intégration de systemd est plus complexe que celle de sysvinit, mais c'est surtout parce que systemd bouge la ou sysvinit ne bouge pas. mais l'intégration de sysvinit n'etait pas non plus une partie de plaisir y a 6/7 ans quand les gens étaient encore en trian de le faire bouger, et que par exemple, mandriva devait refaire les patchs en bash sur le soft venant de Fedora/RH.
Il faut espérer que systemd va finir par se stabiliser un peu plus et innover moins, pour réduire ta charge de travail.
[^] # Re: Aucun, et, à quoi ça sert
Posté par Misc (site web personnel) . En réponse au sondage Quel mécanisme de contrôle d'accès utilisez-vous pour votre système d'exploitation ?. Évalué à 10.
Sur RHEL 7/Centos 7 et fedora je sais pas combien, les plugins firefox sont restreint via SELinux. Donc si jamais quelqu'un arrive à trouver une faille dans flash et la distribue via un réseau de pub, comme ça arrive souvent, ta clé ssh se fera pas faucher, sauf à contourner SElinux.
( tu peux aussi remplacer "clé ssh" par "fichier de mot de passe firefox" ).
Il me semble aussi qu'il y a eu des choses sur les outils qui font des vignettes, au cas ou tu trouves une clé usb avec un fichier vérolé qui fait planter l'outil de vignette.
Cf https://danwalsh.livejournal.com/54092.html
Je pense aussi que SElinux permet de s'assurer que le compte guest ( paquet xguest ) est vraiment limité, ce qui sert sur un kiosque.
Il permet également de limiter docker, qui est un outil assez à la mode en ce moment pour les devs ( donc sur un pc personnel ), et je suppose que selinux serviras aussi pour limiter les applications tierces pour ce que Gnome veut faire avec les histoires de sandbox.