La gestion de sécurité est complexe, car on la fait reposer soit sur les exécutables, soit sur des droits de chaque utilisateurs. Cela marche depuis SELinux, mais c'est hyper complexe. Le système de base root/user a le mérite d'être simple à mettre en œuvre.
Je pensais que la modèle de sécurité a été "plié" en utilisant la méthode du moindre privilège : en gros, un exécutable root bien élevé est cessé faire tomber tous les privilèges dont il n'a pas besoin (et ni lui, ni ses enfants ne peuvent les récupérer). Si on reprend l'exemple de tcpdump, avec une telle approche le script obtenu ne serait pas vraiment root.
On peut utiliser aussi ce principe pour lancer des utilitaires "wrappés".
Il y a un gros reproche à faire à tous ses modes de sécurités : souvent il est question de l'intégrité de la machine, mais souvent l'utilisateur s'en fout, il a surtout peur de perdre les 10 ans de photos à cause d'un crypto-locker. Et même un programme ayant simplement l'id de l'utilisateur peut faire très mal.
Je pense qu'il faudrait repenser les "capabilities" en fonction des données utilisateurs qui est finalement ce qu'il le plus de valeurs dans le système (perte de données ou fuite de données).
Si vous arrivez à faire en sorte qu'une faille mozilla soit impossible à utiliser pour sortir des données, le tout sans 3 tonnes de configuration, vous êtes très fort.
"Reste alors à vérifier par exemple qu'il ne s'agit pas de tas de petites allocations de ~1-8 octets (métrique min_size)"
Il y a des gens qui font des allocations de 8 octets ?! Une si petite allocation implique l'utilisation massive de pointeurs, qui prennent de la place, qui implique beaucoup d'indirection dans la mémoire, et une utilisation des mémoires caches toutes pourris (une ligne de cache L1 est de 32 octets, cela veut dire qu'à chaque lecture, 32 octets sont transférés). Le CPU et gcc veulent des gros morceaux de mémoire (multiple de 2 ou 4 Mo, pour utiliser les 'huge' pages) avec des accès séquentiels ou avec un pattern qui peut se prédire, de 32 ou 64 octets. De préférence, il faut grouper lectures, puis écritures, pour éviter de forcer l'unité mémoire à vérifier, que l'on ne relit pas, ce que l'on est en train d'écrire, ce qui créé des cycles d'attentes.
"Formel" dans beaucoup de cas veux simplement dire "correctement définit", par exemple en C, "(i <> 32" ne donne pas tout le temps le même résultat. Ensuite, il faut un moyen pour décrire les attendus ("théorème" ou "spec" ou "HLR"), et ensuite, il faut bien les trouver, ce qui est souvent beaucoup plus complexe qu'on ne le croit.
Une bonne suite de teste permet de vérifier le comportement attendu mais à tendance à congeler le code. Car il devient couteux de le modifier si la suite de teste n'est pas assez souple. Le cas typique est le fait de changer une constante dans le code, ce qui prend 1 min, mais qui nécessite de recalculer à la main des centaines de valeurs de testes. Personne ne veut le faire.
Il y a une nouvelle méthode de teste qui permet de vérifier que les tests sont corrects. C'est bien plus intéressant que la couverture de code qui ne vérifie que la "traversé" du code et non son résultat. Cela permet de trafiquer les entrée pour augmenter le taux de couverture sans rajouter un seul test.
Il s'agit de la technique de "mutation testing". L'idée est de modifier un peu le code automatiquement et de vérifier que cela plante bien un teste.
Un moyen assez simple pour éviter de congeler une application est d'avoir un "golden model", en gros la même application recodé autrement, ou par une autre équipe (l'équipe de teste ?). Ce code de test permet de calculer les sorties attendues, et sa complexité ne dépasse jamais celle de l'application testée. Ainsi, changer une constante prendra seulement 2 fois 1 min.
Le teste consiste a vérifier que les 2 codes se comportent de la même façon. il faut évidement travailler en "boite noir", sinon le copier-coller va tuer l’intérêt de la méthode.
Il reste à générer les entrées du code comme le font déjà les "fuzzers".
Pour faire ça, il faudrait encore avoir des cours et des livres de C++ "moderne". Les 3 quart ne font que reprendre le livre d'origine complètement obsolète sur les bonnes manières de faire.
J'ai écrit un peu vite. Je ne connais pas Akka. Pour cassandra, il y a une tentative de réécriture en C++ qui annonce des perf bien supérieur à la version d'origine.
Dans les applications temps réel, le plus simple est de ne pas faire d'allocation mémoire, tout est statique. Ainsi, il n'y a jamais de problème de new ou de delete, ni de latence associé.
Unity c'est ~20 millions de ligne de C++, et un jeu c# rajoute ~100k ligne dessus. La partie temps réel dure est à 100% en C++.
Le problème des GC est qu'il rajoute des latences à peu n'importe où, et un peu n'importe quand. Golang dispose d'un gc avec des latences ajouté super courte (9ms de mémoire), mais au pris d'un usage du cpu plus gros. Avec l'augmentation de la RAM, un GC n'est pas raisonnable. C'est amusant de lire les exploits techniques des systèmes de bases de données en "RAM". Ce sont des grappes de x86, avec des To de RAM. Il est plus rapide de faire un reset que de se prendre le full GC de java. Il y a donc une foule de technique pour l'éviter.
si on lit les américains sur la culture des armes. Ils font clairement la distinction entre 3 types d'armes.
Les armes de point qui peuvent se cacher, qui est typiquement une arme de voyou et de voleur. C'est ce genre d'arme qui fait le plus de morts au USA. J'imagine qu'un jour ils arriveront à les faire enregistrer.
Il y a les armes longues, type fusil de chasse. Visible, pour "protéger ta famille". Bref, le genre de machin qu'un bon père de famille a chez lui, voir dans son camion. Il sera presque impossible pour le législateur de demander un enregistrement de ce genre d'arme, sans être vu comme un moyen d'aller ensuite les prendre et d’empêcher l'amériain moyen de se défendre.
Il y a les armes automatiques, ou les gros chargeurs, ou les kit pour transformer une arme longue en arme automatique. C'est l'arme des tueries de masse, mais ce n'est pas le type d'arme qui fait le plus de morts. Beaucoup sont pour l'interdiction de vente de ce genre d'armes.
Bref, vu le nombre d'arme en circulation là-bas, l'interdiction n'aurait aucun sens. Par contre, une segmentation de la réglementation en fonction du type d'arme seraient beaucoup mieux accepté.
J'ai adoré le coté, "je fais un serveur web applicatif en 10 lignes, qui tient la charge". Mais bon, j'ai ensuite vu tout ce qu'il fallait écrire pour utiliser un truc comme go-kit. C'est tellement verbeux, que certains ont essayé d'écrire des générateurs de code. Mais aucun n'est vraiment finalisé.
Que go est simple et donc peut devenir très verbeux, que si on a les type sum et la généricité sous la main, je comprends que l'on a pas envie de revenir à Golang.
si la précision est réellement limité sur la mesure, cela rend le DPA moisn efficace, bien sûr.
Le 2ième point oublié, c'est la possibilité de pirater linky et qu'un pirate installe un firmware de son cru. A priori, il a juste à broadcaster sur la ligne 220 en CPL.
[^] # Re: Petite question ...
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 6.
La gestion de sécurité est complexe, car on la fait reposer soit sur les exécutables, soit sur des droits de chaque utilisateurs. Cela marche depuis SELinux, mais c'est hyper complexe. Le système de base root/user a le mérite d'être simple à mettre en œuvre.
Je pensais que la modèle de sécurité a été "plié" en utilisant la méthode du moindre privilège : en gros, un exécutable root bien élevé est cessé faire tomber tous les privilèges dont il n'a pas besoin (et ni lui, ni ses enfants ne peuvent les récupérer). Si on reprend l'exemple de tcpdump, avec une telle approche le script obtenu ne serait pas vraiment root.
On peut utiliser aussi ce principe pour lancer des utilitaires "wrappés".
Il y a un gros reproche à faire à tous ses modes de sécurités : souvent il est question de l'intégrité de la machine, mais souvent l'utilisateur s'en fout, il a surtout peur de perdre les 10 ans de photos à cause d'un crypto-locker. Et même un programme ayant simplement l'id de l'utilisateur peut faire très mal.
Je pense qu'il faudrait repenser les "capabilities" en fonction des données utilisateurs qui est finalement ce qu'il le plus de valeurs dans le système (perte de données ou fuite de données).
Si vous arrivez à faire en sorte qu'une faille mozilla soit impossible à utiliser pour sortir des données, le tout sans 3 tonnes de configuration, vous êtes très fort.
"La première sécurité est la liberté"
[^] # Re: simd explicite ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pythran - 0.8.7. Évalué à 3.
Mais appeler ses libs ne demandent pas d'utiliser des intrasecs SIMD, si ?
C'est vrai aussi que les compilo ont rarement remplacé des bouts de code, par des fonctions optimisé, en dehors de memcpy().
"La première sécurité est la liberté"
[^] # Re: simd explicite ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pythran - 0.8.7. Évalué à 3. Dernière modification le 20 septembre 2018 à 12:32.
Je ne comprends pas trop l"exemple. Il n'existe pas d'instructions SIMD pour cos(). Sinon, Le code de l'addition est correctement vectorisé, non ?
"La première sécurité est la liberté"
[^] # Re: J’ai testé MALT
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Profileurs mémoire MALT et NUMAPROF. Évalué à 3.
Il y a des gens qui font des allocations de 8 octets ?! Une si petite allocation implique l'utilisation massive de pointeurs, qui prennent de la place, qui implique beaucoup d'indirection dans la mémoire, et une utilisation des mémoires caches toutes pourris (une ligne de cache L1 est de 32 octets, cela veut dire qu'à chaque lecture, 32 octets sont transférés). Le CPU et gcc veulent des gros morceaux de mémoire (multiple de 2 ou 4 Mo, pour utiliser les 'huge' pages) avec des accès séquentiels ou avec un pattern qui peut se prédire, de 32 ou 64 octets. De préférence, il faut grouper lectures, puis écritures, pour éviter de forcer l'unité mémoire à vérifier, que l'on ne relit pas, ce que l'on est en train d'écrire, ce qui créé des cycles d'attentes.
"La première sécurité est la liberté"
# simd explicite ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pythran - 0.8.7. Évalué à 4.
Pourquoi utiliser du SIMD explicite ? Les intrasec et vectorisation automatique de GCC ne suffisent pas ?
"La première sécurité est la liberté"
[^] # Re: Méthodes formelles ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Un peu d’Open Hardware pour la rentrée (et beaucoup de LinuxBoot). Évalué à 4.
"Formel" dans beaucoup de cas veux simplement dire "correctement définit", par exemple en C, "(i <> 32" ne donne pas tout le temps le même résultat. Ensuite, il faut un moyen pour décrire les attendus ("théorème" ou "spec" ou "HLR"), et ensuite, il faut bien les trouver, ce qui est souvent beaucoup plus complexe qu'on ne le croit.
Une bonne suite de teste permet de vérifier le comportement attendu mais à tendance à congeler le code. Car il devient couteux de le modifier si la suite de teste n'est pas assez souple. Le cas typique est le fait de changer une constante dans le code, ce qui prend 1 min, mais qui nécessite de recalculer à la main des centaines de valeurs de testes. Personne ne veut le faire.
Il y a une nouvelle méthode de teste qui permet de vérifier que les tests sont corrects. C'est bien plus intéressant que la couverture de code qui ne vérifie que la "traversé" du code et non son résultat. Cela permet de trafiquer les entrée pour augmenter le taux de couverture sans rajouter un seul test.
Il s'agit de la technique de "mutation testing". L'idée est de modifier un peu le code automatiquement et de vérifier que cela plante bien un teste.
Un moyen assez simple pour éviter de congeler une application est d'avoir un "golden model", en gros la même application recodé autrement, ou par une autre équipe (l'équipe de teste ?). Ce code de test permet de calculer les sorties attendues, et sa complexité ne dépasse jamais celle de l'application testée. Ainsi, changer une constante prendra seulement 2 fois 1 min.
Le teste consiste a vérifier que les 2 codes se comportent de la même façon. il faut évidement travailler en "boite noir", sinon le copier-coller va tuer l’intérêt de la méthode.
Il reste à générer les entrées du code comme le font déjà les "fuzzers".
"La première sécurité est la liberté"
[^] # Re: Méthodes formelles ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Un peu d’Open Hardware pour la rentrée (et beaucoup de LinuxBoot). Évalué à 4. Dernière modification le 03 septembre 2018 à 08:05.
De quelles genres de méthodes formelles vous parlez ? "formel" est utilisé pour beaucoup de chose très différent.
"La première sécurité est la liberté"
[^] # Re: Beaucoup de bruit pour rien
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le comble du ridicule. Évalué à 3. Dernière modification le 09 août 2018 à 17:21.
pour être à la page, il ferait mieux de dessiner des vulves à la place.
"La première sécurité est la liberté"
[^] # Re: *cough*
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le comble du ridicule. Évalué à 5.
En fait, il n'assume rien des conséquences, justement.
"La première sécurité est la liberté"
[^] # Re: *cough*
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le comble du ridicule. Évalué à 9.
comme la libcaca, en gros :)
"La première sécurité est la liberté"
[^] # Re: Conclusion?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 4.
Pour faire ça, il faudrait encore avoir des cours et des livres de C++ "moderne". Les 3 quart ne font que reprendre le livre d'origine complètement obsolète sur les bonnes manières de faire.
"La première sécurité est la liberté"
[^] # Re: Image from scratch + Go = 🎉
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Une image de base docker. Évalué à 6.
L'isolation avec le reste, l'outillage de gestion.
"La première sécurité est la liberté"
[^] # Re: À la fois troll, à la fois fait divers
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 3.
J'ai écrit un peu vite. Je ne connais pas Akka. Pour cassandra, il y a une tentative de réécriture en C++ qui annonce des perf bien supérieur à la version d'origine.
"La première sécurité est la liberté"
[^] # Re: À la fois troll, à la fois fait divers
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 4.
Des trucs comme Kafka et akka, sont surtout IO bound, donc cela concerne surtout la qualité des lib réseau et disque.
"La première sécurité est la liberté"
[^] # Re: Mon avis personnel
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 4.
Ce que tu dis de C++ est vrai pour Golang.
"La première sécurité est la liberté"
[^] # Re: Phobie du GC
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 10.
Dans les applications temps réel, le plus simple est de ne pas faire d'allocation mémoire, tout est statique. Ainsi, il n'y a jamais de problème de new ou de delete, ni de latence associé.
"La première sécurité est la liberté"
[^] # Re: Phobie du GC
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 10.
Unity c'est ~20 millions de ligne de C++, et un jeu c# rajoute ~100k ligne dessus. La partie temps réel dure est à 100% en C++.
Le problème des GC est qu'il rajoute des latences à peu n'importe où, et un peu n'importe quand. Golang dispose d'un gc avec des latences ajouté super courte (9ms de mémoire), mais au pris d'un usage du cpu plus gros. Avec l'augmentation de la RAM, un GC n'est pas raisonnable. C'est amusant de lire les exploits techniques des systèmes de bases de données en "RAM". Ce sont des grappes de x86, avec des To de RAM. Il est plus rapide de faire un reset que de se prendre le full GC de java. Il y a donc une foule de technique pour l'éviter.
"La première sécurité est la liberté"
# La culture des armes
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des armes en Open-Source. Évalué à 4.
si on lit les américains sur la culture des armes. Ils font clairement la distinction entre 3 types d'armes.
Les armes de point qui peuvent se cacher, qui est typiquement une arme de voyou et de voleur. C'est ce genre d'arme qui fait le plus de morts au USA. J'imagine qu'un jour ils arriveront à les faire enregistrer.
Il y a les armes longues, type fusil de chasse. Visible, pour "protéger ta famille". Bref, le genre de machin qu'un bon père de famille a chez lui, voir dans son camion. Il sera presque impossible pour le législateur de demander un enregistrement de ce genre d'arme, sans être vu comme un moyen d'aller ensuite les prendre et d’empêcher l'amériain moyen de se défendre.
Il y a les armes automatiques, ou les gros chargeurs, ou les kit pour transformer une arme longue en arme automatique. C'est l'arme des tueries de masse, mais ce n'est pas le type d'arme qui fait le plus de morts. Beaucoup sont pour l'interdiction de vente de ce genre d'armes.
Bref, vu le nombre d'arme en circulation là-bas, l'interdiction n'aurait aucun sens. Par contre, une segmentation de la réglementation en fonction du type d'arme seraient beaucoup mieux accepté.
"La première sécurité est la liberté"
[^] # Re: C++ -> Python -> Go -> Rust
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Ready At Dawn passe à Rust. Évalué à 4.
J'ai adoré le coté, "je fais un serveur web applicatif en 10 lignes, qui tient la charge". Mais bon, j'ai ensuite vu tout ce qu'il fallait écrire pour utiliser un truc comme go-kit. C'est tellement verbeux, que certains ont essayé d'écrire des générateurs de code. Mais aucun n'est vraiment finalisé.
"La première sécurité est la liberté"
[^] # Re: C++ -> Python -> Go -> Rust
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Ready At Dawn passe à Rust. Évalué à 8. Dernière modification le 26 juillet 2018 à 17:48.
Que go est simple et donc peut devenir très verbeux, que si on a les type sum et la généricité sous la main, je comprends que l'on a pas envie de revenir à Golang.
"La première sécurité est la liberté"
[^] # Re: Ne mélangeons pas tout
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Compteur communiquant linky et collecte de la courbe de charge. Évalué à 3.
Pour la limite temporelle, le CPL("g3") est super lent, genre quelques bps, donc, c'est fort possible que 2 min soit réellement un minimum.
cf https://twitter.com/d0cTB/status/981105488439009280
Par contre, la mise à jour du firmware, c'est pas glop :
https://twitter.com/d0cTB/status/981265458115604480
"La première sécurité est la liberté"
[^] # Re: Tu extrapoles un peu vite
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Compteur communiquant linky et collecte de la courbe de charge. Évalué à 6. Dernière modification le 24 juillet 2018 à 17:26.
On récupérerait les clef RSA avec la consomation électrique.
https://fr.wikipedia.org/wiki/Analyse_de_consommation_(cryptographie)
si la précision est réellement limité sur la mesure, cela rend le DPA moisn efficace, bien sûr.
Le 2ième point oublié, c'est la possibilité de pirater linky et qu'un pirate installe un firmware de son cru. A priori, il a juste à broadcaster sur la ligne 220 en CPL.
"La première sécurité est la liberté"
[^] # Re: Information et transfert de responsabilité
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Légalité de l'interception du flux SSL au sein d'une entreprise. Évalué à 6.
On peut même ajouter que certaines boites noir MiM utilisent des versions de openSSL complètement obsolètes et troués.
"La première sécurité est la liberté"
# business modèle ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Open Earth View - Consultation avant création d'une startup. Évalué à 3.
J'imagine que tu dois commencer par une plateforme comme open street map ou google map, avec la possiblité de créer des cartes perso.
Et tu peux fournir des cartes privés payantes comme github avec ses repositories privés.
J'imagine que la mise en commun de truc iot peut être intéressant (météo, pollution ) mais la 3D sert moins.
"La première sécurité est la liberté"
[^] # Re: Banque Cooperative
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Possible coupure de service sur Liberapay. Évalué à 3.
ok, faudrait que je reregarde un peu.
"La première sécurité est la liberté"