J'ai rien compris à la dépêche, tu donne une lien pour DAFT et nous présente que PAR. C'est quoi le rapport entre les deux ? PAR c'est le protocol et DAFT l'outil ?
J'ai regardé vite fait le readme de github, je vois une dépendance zeromq, faut des noeuds zeromq sur toutes les machines ?
J'ai un doute en lisant ta réponse, si le compteur ne fuyait pas je pourrait toujours faire un overflow. Il s'agit ici bien d'un overflow et non d'un underflow, il faut donc faire 232 appel de syscall, en soit ça il y a rien pour empêcher un programme en userspace d’appeler 232 fois le même syscall. Mais si tu avais pas de fuite du compteur, tu aurais 232 fois l'allocation de l'objet de keyring est niveau mémoire ça passerai difficilement (voir pas avec l'OOM killer qui rentrai en jeu). Parce que si j'ai bien compris, la dés-allocation est faite par le garbage collecteur qui croit qu'il n'y a plus d'objet référencé et donc clean la mémoire. Si j'avais 232 objets alloué le comportement serai le même, il me dés-allouerai le premier objet en croyant qu'il n'existe plus (compteur à 0). Mais avoir 232 allocation du même objet, en mémoire ça passera difficilement.
Y a quelque chose de faux dans mon raisonnement ?
La proposition 4 est intéressante et je me demande pourquoi cela n'est pas fait, sans doute parce cette struct xxx_ops doit être utilisé à beaucoup d'endroit avec des appels vers différentes functions. Si tu remplace le pointeur par un tableau statique tu fais grandir la taille de ta structure (un index par fonction référencé). J'ai bon ?
Les micro-noyaux c'est un autre débats, la méthode est anti-performante dans une architecture monolithique.
Mais pour ma culture personnelle, quel micro noyau existe (en dehors du monde universitaire) ? La plupart du temps les "micro-noyaux" ne sont en fait que des architecture hybride et niveau performance ça pas la panacée.
UDEREF j'ai pas encore creusé le sujet, c'est quoi le principe ? ça marche sur architecture ARM ou c'est uniquement du X86? Et pour quelles contraintes sur les performances ?
le deuxième lien décrit assez bien le problème.
Un problème de "fuite(leak)" d'un compteur dans du code kernel contrôlable facilement par syscall (tu peux incrémenter un compteur sans que les objets qu'est sensé compter se compteur existent). Le compteur est codé sur 32 bits (quelque soit l'architecture 32 ou 64 bit), donc si tu arrive à "overflow" le compteur (tu fait un tour de boucle et donc passe ton compteur à 0), le kernel croit qu'il n'y a plus d'objet référencé et va donc dés-allouer un emplacement mémoire. (use after free attack). Si le compteur ne fuyait pas tu pourrais pas l'overflow car tu te mangerai le Out of Memory Killer bien avant ça.
Suffit alors de ré-allouer l'emplacement mémoire par du code user-space qui va appeler la fonction kernel suivante :
commit_creds(prepare_kernel_cred(0));
Cette fonction aura pour but de te donner l'uid et guid 0 à ton process. (ret2usr attack)
Ré-allouer le même emplacement mémoire est assez simple, l'allocateur mémoire SLAB du kernel linux est facilement prédictible. Pour des raisons de performance si tu demande une allocation d'un bloc mémoire de même taille juste après un dés-allocation, par soucis de performance (et pour pas se prendre la tête et éviter de la fragmentation mémoire), le noyau va te redonner le même emplacement mémoire.
Reste plus qu'a déclencher un syscall, (pour rappel syscall = exeption, passage en ring 0 (kernel)), qui va alors utilisé ton code userspace à toi, qui va appeller la fontion commit_creds.
Voila pour l'explication grosse maille, dans les faits l'exploit est un peu plus élaborer, puisque du code décrementant le compteur utilise le mécanisme de RCU (read copy update) et il est donc plus difficile de savoir quand on a réellement fait l'overflow du compteur. ça demande des synchro a grand coup de sleep. (donc leur exploit prend environ 30 min sur un coeur I7 pour passer root).
Il y a pas mal de mécanisme qu'on peut mettre en place pour se protéger de se genre d'attaque (se protéger du ret2user attack). https://www.usenix.org/sites/default/files/conference/protected-files/sec14_slides_kemerlis.pdf
1) La proposition impossible car complétement anti-performante :
Faire une séparation entre la mémoire user et kernel (arreté de mapper la mémoire kernel dans tous les processus user) et faire un context switch à chaque syscall.
Facile à faire mais complétement irréaliste car ça tuerai toute performance.
2) Identifier les zones mémoires ne devant pas s'exécuter en ring 0 :
Plusieurs techniques soft et aussi hard tels que PaX's KERNEXEC and UDEREF ou PXN (Priviligied Never Execute) sur ARM64.
3) empêcher l'appel à la fonction kernel commit_creds (l'appel ce fait par symbole).
Le symbole (l'emplacement mémoire de la fonction) est facilement connaissable (définie statiquement à la compilation et dépend uniquement de l'architecture utilisée et du compilateur (gcc ici)). Suffit de mettre de l'aléatoire en place à travers la technique de KASLR (Kernel Address Space Layout Randomisation). Dans ce cas il faut alors éviter de laisser des informations fuitées sur l'emplacement des symboles (voir par example kptr_restrict pour censurer /proc/kallsyms).
Voila ce que j'en ai compris (ps: je suis pas expert en sécurité donc il y a certainement quelques raccourcies).
J'utilise Mesos pour gérer mon déploiement de containeurs docker, il s'occupe alors lui même de supprimer les containers qui ne sont plus utilisés (voir l'option --docker_remove_delay).
Parler d'un vrai système de fichier en réseau alors que c'est implémenté en userpace (basé sur FUSE) et dire que ça tiens la comparaison avec NFS faut oser. Niveau perf c'est le jour et la nuit, dès que ta plein de petits fichiers les performances s'écroulent. SSHFS c'est juste pas la bonne architecture (comme tout ce qui est basé sur FUSE), c'est rigolo pour s'amuser mais niveau perf c'est pas bon.
J'ai toujours trouvé bizarre l'idée d'associer dans un même outil, la gestion des dépendances et la gestion de code source (espace de travail). Ce que je veux dire par la, c'est que pour gérer mon espace de travail qui est composé de plusieurs git, j'utilise un outils dédié (dans mon cas l'outil repo d'android). De plus avec git-lfs ce n'est plus un problème de versionner aussi ses binaires à travers git. Ceci me permet de régénérer n'importe où ma base de code et ceci quelque soit le langage de programmation. Ensuite suivant le langage la partie gestion de dépendance de build et de runtime est géré par le système de build que je choisie.
En C/C++, pour un petit projet, j'aime assez bien la syntaxe android (android.mk).
Pour des projets plus complexes et devant intégrer plusieurs code open-source (qui viennent chacun avec leur système de build), j'utilise le "meta-build-system" yocto mais en prenant soins d'écrire une majorité de mes recettes en utilisant la bbclass "externalsrc" ou avec un git local.
Merci pour le lien vers peru que je ne connaissais pas. Néanmoins il à l'air d'utiliser git submodules, ce dont je ne veux pas. je veux juste un repo avec deux trois options supplémentaire et quand je regarde le code source de repo (python et orienté objet sans aucune doc) bah je me dis que je ferais mieux de partir from scratch avec un script bash pour la "hackabilité" de la chose et le coté zéro dépendance. Après go pourrait être une alternative intéressante aussi.
Quand je trouverai le temps de coder un peu pour moi, gws sera surement un bonne base de départ.
Effectivement je voudrais remplacer repo par gws.
Je vois pas en quoi ces deux projets sont si différents, dans les deux cas on a un fichier qui référence les gits qu'on utilise dans son espace de travail (un manifest), leur emplacement et leur version (fonctionnalité manquant pour gws à l'instant mais pas très compliqué à rajouter).
Le besoin de faire des shallow clones c'est des usages avancés, j'ai des gros git avec beaucoup d'historique et vu gagner sur le temps du git clone.
Changer entre deux version de ton répertoire de travail c'est si tu utilise gws comme repo, passer d'une version à une autre simplement (et en ne présupposant pas qu'entre les deux versions , il a y exactement le meme nombre de git et/ou au même endroit).
Le prochain est intéressant, j'ai l'idée de faire la meme chose qui trotte dans ma tete depuis pas mal de temps a force d'utiliser les manifests repo d'android pour gérer mes workspaces et trouver certaines limitations dans cette outils.
Le choix de faire du bash est vraiment un bon choix je trouve, pour ce genre d'outil je veux avoir le minimun de dépendances. Par contre pour le choix du format de fichier .gws j'aurai utilisé le fichier INI du gitconfig et utilisé git config pour l'analyser.
Y a une fonctionnalité présente dans repo qui manque a gws, c'est le cache local, repo crée un .repo qui va contenir les gits en mode "bare metal", ce qui permet de switcher rapidement entre deux version du workspace sans à devoir tout re-télécharger depuis les serveurs distants.
Deux autres fonctionnalités que j'aimerai voir implémenter (et qui celle la n'est pas dans repo) c'est :
1 la possibilité de choisir ces options de clone/fetch (je veux clonner certains gits en mode bare-metal, d'autre en mode shallow etc…)
2 la possibilité de rajouté un post hook, je vais un gws qui va me générer un workspace, qui va ensuite automatiquement m'appeler un script qui est dans mon workspace. C'est vraiment utile pour versionner des installeur sur lequel on a pas la main.7
En tout cas bravo pour le job. Faudrait que je trouve le temps d'y contribuer un peu.
En un poil plus bourrin tu fais tourner un conteneur docker dans lequel tu as ton VPN et ton appli qui l'utilise.
C'est un peu plus bourrin car tu fera aussi du namespace PID, cgroup en plus du namespace réseau … Mais tu te pausera moins de question puisque c'est l'outil docker qui s'occupera de configurer ton réseau à ta place . Tout dépend de ce que tu veux maîtriser.
Il n'est pas la référence et il n'est pas implémenté partout parce qu'il n'est pas le seul. Par exemple dans l'embarqué, le système de paquet logiciel reconnu et poussé par les industrielles est Yocto (projet de la linux fondation) qui repose sur bitbake et openembedded.
Tu es étais où les 20 dernières années ? Non parce que redhat fait ça depuis le début. Soit tu paye pour avoir du redhat, soit tu utilise du centos.
Et dire que RedHat c'est pas libre c'est très très fort de café, ils ont fait énormément pour le libre dans de très nombreux domaine, les développeurs ne vivent pas que d'amour et d'eaux fraîches. Je suis pragmatique est je comprend très bien les positions de Mozilla ou de RedHat, protégé son nom n'a rien d'abusif. Faut pas mélanger les torchons et les serviettes. La liberté du code c'est la liberté du code , un point c'est tout.
Microsoft change, ouverture de C# avec migration de codeplex vers github, partenaria docker , ouverture de msbuild, compilo LLVM pour .NET Core (https://github.com/dotnet/llilc).
Depuis l'arrivé du dernier CTO y a un vrai virage vers de l'opensource qui a été pris et pas uniquement marketing y a eu de la liberation de code aussi. On peut pas juste dire que c'est du librewashing parce que c'est windows, c'est trop facile.
Mouais, sur ARM, on n'a pas de couche d'abstraction/introspection comme BIOS/ACPI/EFI/…
Donc on n'a pas "one kernel to rule them all" (alors que sur mes vieux PC d'il y a 15 ans, je peux encore booter un CD d'une distro linux quelconque). Donc c'est autrement plus complexe à maintenir (le device-tree améliore la donne, mais ça reste imparfait) et la pérennité de tes machines est largement discutable lorsque le constructeur en cesse le support.
Les choses bougent dans se domaine, il y a de plus en plus de board arm qui sont compatible avec un seul kernel (via devicetree). Et y a plusieurs travaux en cours au niveau du développement du kernel. L'un est de rendre le decivetree dynamique (pour gérer les capes à la beaglebone) et un autre qui vise à unifier ACPI et devicetree (par la j'entends avoir une API commune niveau kernel qui dispose d'un backend ACPI pour X86 et devicetree pour ARM ou POWERPC).
Après contenant les critères qui feront décolle ARM sur le marché du serveur le prix est un facteur important oui mais l'écosystème n'est pas à négliger non plus. J'ai beau avoir une stack Java (que je peux donc faire tourner sur ARM facilement) j'ai sans doute autour des outils de monitoring, de log, d'agent de déploiement etc… qui ne sont pas forcément disponible sur ARM. Et on va pas demander à un admin sys de faire de la cross compilation.
Yocto (ou pour etre précis bitbake et openembedded) permet déjà de répondre à tout tes problèmes :
Multi-plateformes (x86,arm,powerpc …) et multi-build système (make,autotools,scons,cmake…)
Gestion des dépendances (à la compilation et au runtime)
Multi-fetcher (git,svn,tarball,mercurial …)
Facile à modifier, étendre (patch et via layer)
Système de cache (ne rebuild que ce qu'il faut)
Système de package (rmp, deb ou opkg)
Il peut auto-construire ça propre toolchain
Peut exporté un SDK (Software development Kit)
Honnêtement, l'essayer c'est l'adopter. Y a juste deux bémol :
La taille (on arrive vite à plusieurs Go (entre les sources, le cache)
N'est pas vraiment pensé pour une développement en mode "agile". (Sauf si tu gère la partie fetch toit meme (avec repo android tools par example ) et en utilisant la classe externalsrc).
Comment le rappel le journal, ils ont libéré .NET et MSBUILD. Ce n'est pas rien. Ils ont tous mis sur github et non sur codeplex ce qui est aussi un changement de culture important. Donc dire que Microsoft fait de l'openwashing c'est du microsoftbashing .
Effectivement l'OS de microsoft ne va pas etre liberé du jour au lendemain mais je ne pense pas que cette phrase ne soit que du buzz. Y a un vraiment tournant qui a été pris depuis l'arrivé du nouveau CTO.
Pourquoi forcément au pire ?
Google arrive à prédire des épidémies de grippe plusieurs jours avant les systèmes traditionnel de santé vigilance. (https://www.google.org/flutrends/) Je trouve ça intéressant (et dans ce cas les infos peuvent être anonymisé). Tu peux gagner des informations précieuse sans forcément tomber dans la pire dictature.
Tout dépend comment cela est fait, par qui et dans quel but. Le qui étant le plus important (le but et le comment découlant souvent du qui).
Armes et couteaux sont toutes les deux "ni bonnes, ni mauvaise". Dans les deux cas ce ne sont pas les armes ou les couteaux qui tuent mais ce qui s'en servent. Après on fait un calcul de risque par rapport et on estime que le risque d'une arme est plus élevé que le risque d'un couteau et donc on en contrôle leur accès (permis d'arme).
Une arme est estimé plus "dangereuse" qu'un couteau mais ça n'a pas grand chose à voir avec "bon" ou "mauvais". Une arme peut servir à de "bonne chose" (Ou alors faut considérer que toutes les force de l'ordre et les chasseurs comme des pourris).
Qui estime qu'internet fait plutôt le bien ? A part quelques personnes convaincu que c'est la troisième évolution majeur de l'humanité après l'écriture et l'imprimerie, y a malheureusement beaucoup de personne qu'y le voit internet d'un mauvais oeil (Un repaire de pedo-nazi-terroriste-pirate incontrôlé).
Les inquisitions sur la technologies ça m'inquiété. Non une technologie n'est ni bonne ni mauvaise. On peut faire des choses géniales avec les big data comme de la surveillance de masse. Le problème n'est pas les big data mais à ce qu'on en fait. Sinon on fait juste plus rien, toute technologie peut etre utilisé à de mauvaise fin. Si j'écrase la tête de quelqu'un on fait quoi ? On interdit tout les marteaux même pour leur usages légitime de planter des clous ?
Le rapport entre Docker et ZooKeeper ou etcd ? L'éco-système, docker est la brique de base qui te permet de faire de l'isolation mais dès que tu veux faire du déploiement multi machine tu as d'autre besoin que juste l'isolation tels que le load balancing, la haute dispo, la découverte automatique de service etc… Et ça Mesos peut l'apporter. Mais le coeur de Mesos repose sur l'algo à consensus Zookeeper qui n'est pas celui choisi par d'autre projet gravitant autour de Docker. Kubernetes de google utilise etcd et coreOS aussi. Y a un port en cours pour intégrer Kubernetes avec Mesos. Et avoir zookeeper et etcd en parallèle c'est un peu bancal comme architecture. Donc y a un travail en cours pour avoir un backend etcd à Mesos. Y a aussi un travail en cours pour intégrer l'api de Docker Swarm.
Et pour faire tourner du Hadoop, Spark et Storm sur le meme cluster tu as besoin d'isolation, avant Mesos proposait sa propre implémentation (toujours à base de cgroups) mais depuis la version 0.20 docker est devenue une brique "1st citizen". Il se repose dessus pour fournir leur isolation. L'ancienne implémentation reste disponible, tout ceci est configurable a travers la ligne de commande qui lance le mesos-slave. Mais meme si tu fait tourner du Storm et du Spark tu as tout de meme besoin d'isolation entre ses framework et tu peux utiliser docker comme conteneur.
Docker n'est pas un framework Mesos de plus, c'est pas au même niveau dans la "stack Mesos", tu as tout en haut les frameworks (Storm,Hadoop,ElasticSearch,Jenkins,MPI,Aurora,Marathon…) et en bas, au niveau des executeurs, (sur les slave mesos) tu as le conteneur (soit l'implémentation mesos de base, soit depuis la 0.20 docker). Donc je me permet d'insister, au vue de développement en cours (le jira mesos est public), il y de plus en plus de développement qui sont fait pour s'intégrer avec l'eco-système Docker (Docker Swarm,Kubernete,support etcd) et Docker est maintenant une brique de base de la stack Mesos (Elle n'est pas irremplaçable puisque l'ancienne implémentation reste disponible mais c'est tout de même une brique de base).
Concernant LXC, oui Docker était une surcouche à LXC et ils ont implémenté libcontaineur parce qu'il en avait marre de gérer les api breaks et les X versions différentes de LXC. J'ai la flemme de me replonger dans les mailings list docker mais ça transpire même dans l'annonce officiel : http://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
This drastically reduces the number of moving parts, and insulates Docker from the side-effects introduced across versions and distributions of LXC. In fact, libcontainer delivered such a boost to stability that we decided to make it the default
Au passage pour ne pas opposé docker et LXC, la libcontainer dispose de plusieurs backend (celui par défaut en go) mais rien ne t’empêche d'utiliser LXC ou LMCTFY de google etc…
Mais si tu me relis tu verra que je dis que Docker n'apporte pas grand chose technologiquement parlant mais je suis pas d'accord pour dire que le hard work était LXC. C'était tout autant du hard work d'arriver à fédérer une communauté ouverte avec des gros acteurs du domaine, qui s'accorde pour dire : "on fait plus les choses dans notre coin, on utilise docker comme API de containérisation, on parle le même language et on bâti nos outils autour de cette solution car on a une techno simple à utiliser, clairement documenté, avec un processus de décision clair et ouvert.
LXC bien que beaucoup plus vieux que Docker n'a jamais décollé parce que centré sur lui même, de la technique pur mais aucune communication autour ni vraiment de doc (Ubuntu la dessus à rater une belle occasion et maintenant il tente de ce rattraper avec lxd).
Après je pense que la discussion va devenir stérile, on parle de la même chose mais avec une vue différente, tu parle technique, je parle éco-système. Je préfère mille fois une techno "non parfaite" utilisé par tous et avec un processus de qualité (Doc,livraison,roadmap,processus pour participer clairement établie) qu'une techno "parfaite" mais peu utilisé et mal documenté …
Pour toi Mesos et Docker sont complément disjoint et techniquement parlant tu as raison.
Pour moi il forme un tout cohérent et d'un point de vue service j'ai raison.
```
# Besoin de plus d'info
Posté par Tangi Colin . En réponse au journal première sortie de "DAFT Allows File Transfers". Évalué à 10.
J'ai rien compris à la dépêche, tu donne une lien pour DAFT et nous présente que PAR. C'est quoi le rapport entre les deux ? PAR c'est le protocol et DAFT l'outil ?
J'ai regardé vite fait le readme de github, je vois une dépendance zeromq, faut des noeuds zeromq sur toutes les machines ?
Bref ça manque clairement d'informations.
[^] # Re: Journal bookmark inutile.
Posté par Tangi Colin . En réponse au journal faille Linux 0 day du 19 janvier 2016 . Évalué à 3.
J'ai un doute en lisant ta réponse, si le compteur ne fuyait pas je pourrait toujours faire un overflow. Il s'agit ici bien d'un overflow et non d'un underflow, il faut donc faire 232 appel de syscall, en soit ça il y a rien pour empêcher un programme en userspace d’appeler 232 fois le même syscall. Mais si tu avais pas de fuite du compteur, tu aurais 232 fois l'allocation de l'objet de keyring est niveau mémoire ça passerai difficilement (voir pas avec l'OOM killer qui rentrai en jeu). Parce que si j'ai bien compris, la dés-allocation est faite par le garbage collecteur qui croit qu'il n'y a plus d'objet référencé et donc clean la mémoire. Si j'avais 232 objets alloué le comportement serai le même, il me dés-allouerai le premier objet en croyant qu'il n'existe plus (compteur à 0). Mais avoir 232 allocation du même objet, en mémoire ça passera difficilement.
Y a quelque chose de faux dans mon raisonnement ?
La proposition 4 est intéressante et je me demande pourquoi cela n'est pas fait, sans doute parce cette struct xxx_ops doit être utilisé à beaucoup d'endroit avec des appels vers différentes functions. Si tu remplace le pointeur par un tableau statique tu fais grandir la taille de ta structure (un index par fonction référencé). J'ai bon ?
Les micro-noyaux c'est un autre débats, la méthode est anti-performante dans une architecture monolithique.
Mais pour ma culture personnelle, quel micro noyau existe (en dehors du monde universitaire) ? La plupart du temps les "micro-noyaux" ne sont en fait que des architecture hybride et niveau performance ça pas la panacée.
UDEREF j'ai pas encore creusé le sujet, c'est quoi le principe ? ça marche sur architecture ARM ou c'est uniquement du X86? Et pour quelles contraintes sur les performances ?
```
[^] # Re: Journal bookmark inutile.
Posté par Tangi Colin . En réponse au journal faille Linux 0 day du 19 janvier 2016 . Évalué à 10. Dernière modification le 20 janvier 2016 à 21:05.
le deuxième lien décrit assez bien le problème.
Un problème de "fuite(leak)" d'un compteur dans du code kernel contrôlable facilement par syscall (tu peux incrémenter un compteur sans que les objets qu'est sensé compter se compteur existent). Le compteur est codé sur 32 bits (quelque soit l'architecture 32 ou 64 bit), donc si tu arrive à "overflow" le compteur (tu fait un tour de boucle et donc passe ton compteur à 0), le kernel croit qu'il n'y a plus d'objet référencé et va donc dés-allouer un emplacement mémoire. (use after free attack). Si le compteur ne fuyait pas tu pourrais pas l'overflow car tu te mangerai le Out of Memory Killer bien avant ça.
Suffit alors de ré-allouer l'emplacement mémoire par du code user-space qui va appeler la fonction kernel suivante :
commit_creds(prepare_kernel_cred(0));
Cette fonction aura pour but de te donner l'uid et guid 0 à ton process. (ret2usr attack)
Ré-allouer le même emplacement mémoire est assez simple, l'allocateur mémoire SLAB du kernel linux est facilement prédictible. Pour des raisons de performance si tu demande une allocation d'un bloc mémoire de même taille juste après un dés-allocation, par soucis de performance (et pour pas se prendre la tête et éviter de la fragmentation mémoire), le noyau va te redonner le même emplacement mémoire.
Reste plus qu'a déclencher un syscall, (pour rappel syscall = exeption, passage en ring 0 (kernel)), qui va alors utilisé ton code userspace à toi, qui va appeller la fontion commit_creds.
Voila pour l'explication grosse maille, dans les faits l'exploit est un peu plus élaborer, puisque du code décrementant le compteur utilise le mécanisme de RCU (read copy update) et il est donc plus difficile de savoir quand on a réellement fait l'overflow du compteur. ça demande des synchro a grand coup de sleep. (donc leur exploit prend environ 30 min sur un coeur I7 pour passer root).
Il y a pas mal de mécanisme qu'on peut mettre en place pour se protéger de se genre d'attaque (se protéger du ret2user attack). https://www.usenix.org/sites/default/files/conference/protected-files/sec14_slides_kemerlis.pdf
1) La proposition impossible car complétement anti-performante :
Faire une séparation entre la mémoire user et kernel (arreté de mapper la mémoire kernel dans tous les processus user) et faire un context switch à chaque syscall.
Facile à faire mais complétement irréaliste car ça tuerai toute performance.
2) Identifier les zones mémoires ne devant pas s'exécuter en ring 0 :
Plusieurs techniques soft et aussi hard tels que PaX's KERNEXEC and UDEREF ou PXN (Priviligied Never Execute) sur ARM64.
Cette protection peut malheureusement aussi être contourner si on arrive à utiliser la zone mémoire physmap (voir https://www.usenix.org/sites/default/files/conference/protected-files/sec14_slides_kemerlis.pdf). Mais on complique déjà la vie des attaquant avec ces protections.
3) empêcher l'appel à la fonction kernel commit_creds (l'appel ce fait par symbole).
Le symbole (l'emplacement mémoire de la fonction) est facilement connaissable (définie statiquement à la compilation et dépend uniquement de l'architecture utilisée et du compilateur (gcc ici)). Suffit de mettre de l'aléatoire en place à travers la technique de KASLR (Kernel Address Space Layout Randomisation). Dans ce cas il faut alors éviter de laisser des informations fuitées sur l'emplacement des symboles (voir par example kptr_restrict pour censurer /proc/kallsyms).
Voila ce que j'en ai compris (ps: je suis pas expert en sécurité donc il y a certainement quelques raccourcies).
[^] # Re: Bof
Posté par Tangi Colin . En réponse au journal faille Linux 0 day du 19 janvier 2016 . Évalué à 5.
Tu raisonne serveur mais si tu pense aux rootkit android la faille est déjà beaucoup plus sérieuse.
[^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++
Posté par Tangi Colin . En réponse au journal Adieu Biicode, bonjour Conan. Évalué à 1.
Docker fonctionne très bien avec des applis graphique, vu juste pensé à "binder" la socket Xorg du "host" au lancement de son conteneur.
[^] # Re: Verrouillage?
Posté par Tangi Colin . En réponse au journal CPython abandonne Mercurial et passe à Git et Github. Évalué à 4.
si ton problème c'est d'héberger une instance de github sur ta propre machine tu peux le faire, ils ont des offres payantes qui permettent cela.
# Mesos comme ramasse-miette
Posté par Tangi Colin . En réponse au journal Un ramasse-miette pour docker. Évalué à 3.
J'utilise Mesos pour gérer mon déploiement de containeurs docker, il s'occupe alors lui même de supprimer les containers qui ne sont plus utilisés (voir l'option --docker_remove_delay).
[^] # Re: code des drones parrot ?
Posté par Tangi Colin . En réponse au journal Qualcomm & les drones & Ubuntu. Évalué à 1.
En soft open source pour piloter des drones il y a Openpilot qui a l'air assez sérieux : https://www.openpilot.org/
[^] # Re: un petit résumé de ce qu'est ansible?
Posté par Tangi Colin . En réponse au journal Obtenir un inventaire ansible depuis GLPI. Évalué à 3.
Sur chef ou puppet tu as un client installé sur chaque machine. Ansible c'est du "clientless" ou tout ce fait a travers du ssh.
# Comparer NFS avec un fs implémenté par FUSE faut oser comme meme
Posté par Tangi Colin . En réponse au journal SSHFS est un vrai système de fichiers en réseau. Évalué à 8.
Parler d'un vrai système de fichier en réseau alors que c'est implémenté en userpace (basé sur FUSE) et dire que ça tiens la comparaison avec NFS faut oser. Niveau perf c'est le jour et la nuit, dès que ta plein de petits fichiers les performances s'écroulent. SSHFS c'est juste pas la bonne architecture (comme tout ce qui est basé sur FUSE), c'est rigolo pour s'amuser mais niveau perf c'est pas bon.
# Gestion de code source (espace de travail) != Gestion des dépendances
Posté par Tangi Colin . En réponse au journal biicode, c'est fini. Évalué à 1.
J'ai toujours trouvé bizarre l'idée d'associer dans un même outil, la gestion des dépendances et la gestion de code source (espace de travail). Ce que je veux dire par la, c'est que pour gérer mon espace de travail qui est composé de plusieurs git, j'utilise un outils dédié (dans mon cas l'outil repo d'android). De plus avec git-lfs ce n'est plus un problème de versionner aussi ses binaires à travers git. Ceci me permet de régénérer n'importe où ma base de code et ceci quelque soit le langage de programmation. Ensuite suivant le langage la partie gestion de dépendance de build et de runtime est géré par le système de build que je choisie.
En C/C++, pour un petit projet, j'aime assez bien la syntaxe android (android.mk).
Pour des projets plus complexes et devant intégrer plusieurs code open-source (qui viennent chacun avec leur système de build), j'utilise le "meta-build-system" yocto mais en prenant soins d'écrire une majorité de mes recettes en utilisant la bbclass "externalsrc" ou avec un git local.
[^] # Re: Fonctionnalité manquantes par rapport à android repo
Posté par Tangi Colin . En réponse à la dépêche Gérer son espace de travail git avec "gws". Évalué à 1.
Merci pour le lien vers peru que je ne connaissais pas. Néanmoins il à l'air d'utiliser git submodules, ce dont je ne veux pas. je veux juste un repo avec deux trois options supplémentaire et quand je regarde le code source de repo (python et orienté objet sans aucune doc) bah je me dis que je ferais mieux de partir from scratch avec un script bash pour la "hackabilité" de la chose et le coté zéro dépendance. Après go pourrait être une alternative intéressante aussi.
Quand je trouverai le temps de coder un peu pour moi, gws sera surement un bonne base de départ.
[^] # Re: Fonctionnalité manquantes par rapport à android repo
Posté par Tangi Colin . En réponse à la dépêche Gérer son espace de travail git avec "gws". Évalué à 1.
Effectivement je voudrais remplacer repo par gws.
Je vois pas en quoi ces deux projets sont si différents, dans les deux cas on a un fichier qui référence les gits qu'on utilise dans son espace de travail (un manifest), leur emplacement et leur version (fonctionnalité manquant pour gws à l'instant mais pas très compliqué à rajouter).
Le besoin de faire des shallow clones c'est des usages avancés, j'ai des gros git avec beaucoup d'historique et vu gagner sur le temps du git clone.
Changer entre deux version de ton répertoire de travail c'est si tu utilise gws comme repo, passer d'une version à une autre simplement (et en ne présupposant pas qu'entre les deux versions , il a y exactement le meme nombre de git et/ou au même endroit).
# Fonctionnalité manquantes par rapport à android repo
Posté par Tangi Colin . En réponse à la dépêche Gérer son espace de travail git avec "gws". Évalué à 3.
Le prochain est intéressant, j'ai l'idée de faire la meme chose qui trotte dans ma tete depuis pas mal de temps a force d'utiliser les manifests repo d'android pour gérer mes workspaces et trouver certaines limitations dans cette outils.
Le choix de faire du bash est vraiment un bon choix je trouve, pour ce genre d'outil je veux avoir le minimun de dépendances. Par contre pour le choix du format de fichier .gws j'aurai utilisé le fichier INI du gitconfig et utilisé git config pour l'analyser.
Y a une fonctionnalité présente dans repo qui manque a gws, c'est le cache local, repo crée un .repo qui va contenir les gits en mode "bare metal", ce qui permet de switcher rapidement entre deux version du workspace sans à devoir tout re-télécharger depuis les serveurs distants.
Deux autres fonctionnalités que j'aimerai voir implémenter (et qui celle la n'est pas dans repo) c'est :
1 la possibilité de choisir ces options de clone/fetch (je veux clonner certains gits en mode bare-metal, d'autre en mode shallow etc…)
2 la possibilité de rajouté un post hook, je vais un gws qui va me générer un workspace, qui va ensuite automatiquement m'appeler un script qui est dans mon workspace. C'est vraiment utile pour versionner des installeur sur lequel on a pas la main.7
En tout cas bravo pour le job. Faudrait que je trouve le temps d'y contribuer un peu.
[^] # Re: Persistence de tout ça
Posté par Tangi Colin . En réponse au journal Vacances & Réseaux hostiles. Évalué à 4.
En un poil plus bourrin tu fais tourner un conteneur docker dans lequel tu as ton VPN et ton appli qui l'utilise.
C'est un peu plus bourrin car tu fera aussi du namespace PID, cgroup en plus du namespace réseau … Mais tu te pausera moins de question puisque c'est l'outil docker qui s'occupera de configurer ton réseau à ta place . Tout dépend de ce que tu veux maîtriser.
[^] # Re: Question à 1 million.
Posté par Tangi Colin . En réponse à la dépêche pkgsrc 2015Q2. Évalué à 2.
Il n'est pas la référence et il n'est pas implémenté partout parce qu'il n'est pas le seul. Par exemple dans l'embarqué, le système de paquet logiciel reconnu et poussé par les industrielles est Yocto (projet de la linux fondation) qui repose sur bitbake et openembedded.
# Retour vers le futur
Posté par Tangi Colin . En réponse au journal Quand le libre est un faux nez pour de la vraie propriété intellectuelle. Évalué à 10.
Tu es étais où les 20 dernières années ? Non parce que redhat fait ça depuis le début. Soit tu paye pour avoir du redhat, soit tu utilise du centos.
Et dire que RedHat c'est pas libre c'est très très fort de café, ils ont fait énormément pour le libre dans de très nombreux domaine, les développeurs ne vivent pas que d'amour et d'eaux fraîches. Je suis pragmatique est je comprend très bien les positions de Mozilla ou de RedHat, protégé son nom n'a rien d'abusif. Faut pas mélanger les torchons et les serviettes. La liberté du code c'est la liberté du code , un point c'est tout.
[^] # Re: Les temps ne changent pas partout
Posté par Tangi Colin . En réponse au journal Les temps changent. Évalué à 9.
Pour C# y a quoi qui te va pas ici : https://github.com/dotnet/roslyn ?
Microsoft change, ouverture de C# avec migration de codeplex vers github, partenaria docker , ouverture de msbuild, compilo LLVM pour .NET Core (https://github.com/dotnet/llilc).
Depuis l'arrivé du dernier CTO y a un vrai virage vers de l'opensource qui a été pris et pas uniquement marketing y a eu de la liberation de code aussi. On peut pas juste dire que c'est du librewashing parce que c'est windows, c'est trop facile.
[^] # Re: Manque l'essentiel
Posté par Tangi Colin . En réponse au journal Essai serveur ARM chez cloud.online.net. Évalué à 1.
Les choses bougent dans se domaine, il y a de plus en plus de board arm qui sont compatible avec un seul kernel (via devicetree). Et y a plusieurs travaux en cours au niveau du développement du kernel. L'un est de rendre le decivetree dynamique (pour gérer les capes à la beaglebone) et un autre qui vise à unifier ACPI et devicetree (par la j'entends avoir une API commune niveau kernel qui dispose d'un backend ACPI pour X86 et devicetree pour ARM ou POWERPC).
http://events.linuxfoundation.org/sites/events/files/slides/unified_properties_API_0.pdf
Après contenant les critères qui feront décolle ARM sur le marché du serveur le prix est un facteur important oui mais l'écosystème n'est pas à négliger non plus. J'ai beau avoir une stack Java (que je peux donc faire tourner sur ARM facilement) j'ai sans doute autour des outils de monitoring, de log, d'agent de déploiement etc… qui ne sont pas forcément disponible sur ARM. Et on va pas demander à un admin sys de faire de la cross compilation.
# YOCTO
Posté par Tangi Colin . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 1.
Yocto (ou pour etre précis bitbake et openembedded) permet déjà de répondre à tout tes problèmes :
Multi-plateformes (x86,arm,powerpc …) et multi-build système (make,autotools,scons,cmake…)
Gestion des dépendances (à la compilation et au runtime)
Multi-fetcher (git,svn,tarball,mercurial …)
Facile à modifier, étendre (patch et via layer)
Système de cache (ne rebuild que ce qu'il faut)
Système de package (rmp, deb ou opkg)
Il peut auto-construire ça propre toolchain
Peut exporté un SDK (Software development Kit)
Honnêtement, l'essayer c'est l'adopter. Y a juste deux bémol :
La taille (on arrive vite à plusieurs Go (entre les sources, le cache)
N'est pas vraiment pensé pour une développement en mode "agile". (Sauf si tu gère la partie fetch toit meme (avec repo android tools par example ) et en utilisant la classe externalsrc).
[^] # Re: De l'openwashing
Posté par Tangi Colin . En réponse au journal Windows éventuellement en open source?. Évalué à 10.
Comment le rappel le journal, ils ont libéré .NET et MSBUILD. Ce n'est pas rien. Ils ont tous mis sur github et non sur codeplex ce qui est aussi un changement de culture important. Donc dire que Microsoft fait de l'openwashing c'est du microsoftbashing .
Effectivement l'OS de microsoft ne va pas etre liberé du jour au lendemain mais je ne pense pas que cette phrase ne soit que du buzz. Y a un vraiment tournant qui a été pris depuis l'arrivé du nouveau CTO.
[^] # Re: C'est pire ailleurs
Posté par Tangi Colin . En réponse au journal L'hypocrisie du refus des « boîtes noires » à l'époque des GAFA. Évalué à 2. Dernière modification le 20 mars 2015 à 18:27.
Pourquoi forcément au pire ?
Google arrive à prédire des épidémies de grippe plusieurs jours avant les systèmes traditionnel de santé vigilance. (https://www.google.org/flutrends/) Je trouve ça intéressant (et dans ce cas les infos peuvent être anonymisé). Tu peux gagner des informations précieuse sans forcément tomber dans la pire dictature.
Tout dépend comment cela est fait, par qui et dans quel but. Le qui étant le plus important (le but et le comment découlant souvent du qui).
Armes et couteaux sont toutes les deux "ni bonnes, ni mauvaise". Dans les deux cas ce ne sont pas les armes ou les couteaux qui tuent mais ce qui s'en servent. Après on fait un calcul de risque par rapport et on estime que le risque d'une arme est plus élevé que le risque d'un couteau et donc on en contrôle leur accès (permis d'arme).
Une arme est estimé plus "dangereuse" qu'un couteau mais ça n'a pas grand chose à voir avec "bon" ou "mauvais". Une arme peut servir à de "bonne chose" (Ou alors faut considérer que toutes les force de l'ordre et les chasseurs comme des pourris).
Qui estime qu'internet fait plutôt le bien ? A part quelques personnes convaincu que c'est la troisième évolution majeur de l'humanité après l'écriture et l'imprimerie, y a malheureusement beaucoup de personne qu'y le voit internet d'un mauvais oeil (Un repaire de pedo-nazi-terroriste-pirate incontrôlé).
[^] # Re: C'est pire ailleurs
Posté par Tangi Colin . En réponse au journal L'hypocrisie du refus des « boîtes noires » à l'époque des GAFA. Évalué à 5.
Les inquisitions sur la technologies ça m'inquiété. Non une technologie n'est ni bonne ni mauvaise. On peut faire des choses géniales avec les big data comme de la surveillance de masse. Le problème n'est pas les big data mais à ce qu'on en fait. Sinon on fait juste plus rien, toute technologie peut etre utilisé à de mauvaise fin. Si j'écrase la tête de quelqu'un on fait quoi ? On interdit tout les marteaux même pour leur usages légitime de planter des clous ?
[^] # Re: Conclusion un peu hative
Posté par Tangi Colin . En réponse au journal Docker, la plateforme à la mode. Évalué à 2.
Aucun soucis pour ma part, je me suis pas sentis vexé par tes réactions et ça a été un plaisir de confronter nos point de vue.
[^] # Re: Conclusion un peu hative
Posté par Tangi Colin . En réponse au journal Docker, la plateforme à la mode. Évalué à 6.
Le rapport entre Docker et ZooKeeper ou etcd ? L'éco-système, docker est la brique de base qui te permet de faire de l'isolation mais dès que tu veux faire du déploiement multi machine tu as d'autre besoin que juste l'isolation tels que le load balancing, la haute dispo, la découverte automatique de service etc… Et ça Mesos peut l'apporter. Mais le coeur de Mesos repose sur l'algo à consensus Zookeeper qui n'est pas celui choisi par d'autre projet gravitant autour de Docker. Kubernetes de google utilise etcd et coreOS aussi. Y a un port en cours pour intégrer Kubernetes avec Mesos. Et avoir zookeeper et etcd en parallèle c'est un peu bancal comme architecture. Donc y a un travail en cours pour avoir un backend etcd à Mesos. Y a aussi un travail en cours pour intégrer l'api de Docker Swarm.
Et pour faire tourner du Hadoop, Spark et Storm sur le meme cluster tu as besoin d'isolation, avant Mesos proposait sa propre implémentation (toujours à base de cgroups) mais depuis la version 0.20 docker est devenue une brique "1st citizen". Il se repose dessus pour fournir leur isolation. L'ancienne implémentation reste disponible, tout ceci est configurable a travers la ligne de commande qui lance le mesos-slave. Mais meme si tu fait tourner du Storm et du Spark tu as tout de meme besoin d'isolation entre ses framework et tu peux utiliser docker comme conteneur.
Docker n'est pas un framework Mesos de plus, c'est pas au même niveau dans la "stack Mesos", tu as tout en haut les frameworks (Storm,Hadoop,ElasticSearch,Jenkins,MPI,Aurora,Marathon…) et en bas, au niveau des executeurs, (sur les slave mesos) tu as le conteneur (soit l'implémentation mesos de base, soit depuis la 0.20 docker). Donc je me permet d'insister, au vue de développement en cours (le jira mesos est public), il y de plus en plus de développement qui sont fait pour s'intégrer avec l'eco-système Docker (Docker Swarm,Kubernete,support etcd) et Docker est maintenant une brique de base de la stack Mesos (Elle n'est pas irremplaçable puisque l'ancienne implémentation reste disponible mais c'est tout de même une brique de base).
Concernant LXC, oui Docker était une surcouche à LXC et ils ont implémenté libcontaineur parce qu'il en avait marre de gérer les api breaks et les X versions différentes de LXC. J'ai la flemme de me replonger dans les mailings list docker mais ça transpire même dans l'annonce officiel :
http://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
Au passage pour ne pas opposé docker et LXC, la libcontainer dispose de plusieurs backend (celui par défaut en go) mais rien ne t’empêche d'utiliser LXC ou LMCTFY de google etc…
Mais si tu me relis tu verra que je dis que Docker n'apporte pas grand chose technologiquement parlant mais je suis pas d'accord pour dire que le hard work était LXC. C'était tout autant du hard work d'arriver à fédérer une communauté ouverte avec des gros acteurs du domaine, qui s'accorde pour dire : "on fait plus les choses dans notre coin, on utilise docker comme API de containérisation, on parle le même language et on bâti nos outils autour de cette solution car on a une techno simple à utiliser, clairement documenté, avec un processus de décision clair et ouvert.
LXC bien que beaucoup plus vieux que Docker n'a jamais décollé parce que centré sur lui même, de la technique pur mais aucune communication autour ni vraiment de doc (Ubuntu la dessus à rater une belle occasion et maintenant il tente de ce rattraper avec lxd).
Après je pense que la discussion va devenir stérile, on parle de la même chose mais avec une vue différente, tu parle technique, je parle éco-système. Je préfère mille fois une techno "non parfaite" utilisé par tous et avec un processus de qualité (Doc,livraison,roadmap,processus pour participer clairement établie) qu'une techno "parfaite" mais peu utilisé et mal documenté …
Pour toi Mesos et Docker sont complément disjoint et techniquement parlant tu as raison.
Pour moi il forme un tout cohérent et d'un point de vue service j'ai raison.
```