gdelugre a écrit 9 commentaires

Il faut vraiment expliquer le besoin de sécuriser un serveur sur lequel on donne un shell à tout un tas de gens ?

La seule chose que je peux dire : « Pose toi, prend du recul sinon tu finiras en burnout du sexisme et en dépression. »

Sans vouloir être méchante (sincèrement), cette phrase me semble un peu paternaliste.

Je vois… Donc tu catégorises ton interlocuteur en fonction de son sexe.

Si une femme t'avait donné un simple conseil, ça ne t'aurait pas choquée, mais puisque c'est un homme, alors c'est automatiquement un salaud de paternaliste.

Au fond, ça ne serait pas plutôt toi qui serait sexiste ?

Hum, regarde la définition d’oppression s’il te plait.

Du coup j'ai vraiment été voir la définition d'oppression :

Oppression : Action d'opprimer, d'accabler sous une autorité tyrannique : Lutter contre l'oppression.

Opprimer :
- Soumettre quelqu'un, un groupe à un pouvoir tyrannique et violent, l'écraser sous une autorité excessive, répressive : Opprimer les faibles.
- Empêcher un groupe de s'exprimer librement : Opprimer la presse.

Ton exemple est à des années-lumière de l'oppression, donc ça serait pas mal que tu modères ton langage, juste par décence envers les peuples qui sont réellement opprimés.

Donc si je comprends bien ton point de vue, la pornographie n'est pas éthique.
Est-ce que tu pourrais développer ?

Je suis pas expert en éthique, mais pour moi il s'agit d'une relation sexuelle entre adultes consentants, et il est libre à chacun de ne pas en regarder si ça ne lui plait pas.

Enfin, est-ce que tu pourrais expliquer en quoi ce que tu as vu sur ce site "décadent" est fondamentalement différent de ce que tu fais avec ta compagne dans un cadre privé ?

Oh non, une fesse s'est affichée pendant 3 secondes sur mon écran…
Vite aidez-moi à lutter contre cette technologie décadente, il faut passer Internet au kärsher !

Le prompt par défaut est correcte mais sans plus, par exemple il n'y a pas la branche ni l'état du dépôt quand on est dans un répertoire git, ça me sert souvent.

fish embarque plusieurs prompt déjà tout configurés qui te donnent des infos sur git. Tu peux en choisir un avec fish_config.

Les autosuggestions, j'ai testé rapidement… si je fais 'ls' il me propose 'ls Images' si je fais tab, il complète avec 'ls ico', du coup faut faire flèche droite pour avoir la suggestion mais c'est moins pratique que ctrl-r qui permet de pas bouger les mains si on n'a pas besoin d'éditer la commande.

Sans utiliser les flèches, ça complète aussi avec Ctrl-e, et sinon tu peux définir un autre binding.

Si on fait 'cp rep long/chemin/rep' et donc qu'on a oublié le -r, quand on fait flèche droite on se retrouve en fin de ligne et il faut revenir en arrière alors qu'avec ctrl-r on est au début.

Tu fais Ctrl-a et tu reviens au début.

Quand on fait 'gimp img' dans zsh je peux me déplacer avec les flèches pour prendre celui dans la 3ème colonne, 5ème ligne. Des fois c'est pratique. Là faut faire tab et tous les faire un par un ou compléter le nom.

Ouais bon ça, c'est un peu une killer feature de zsh, on peut pas tout avoir non plus.

Sinon l'un des inconvénients, c'est que la syntaxe de scripting n'est pas du tout compatible POSIX. Ça demande de faire un petit travail de réécriture quand on utilise des fonctions custom dans son shell.

Note à part, cd00r est intéressant car par exemple il n'y a pas de chaînes de caractères de plus de trois lettres dans le code source pour qu'aucune chaîne suspicieuse apparaisse avec la commande string.

C'est stupéfiant. J'aurais jamais cru qu'on puisse voir un truc aussi évolué un jour.

On est d'accord, ce n'est pas la protection absolue. Et en soit se dire qu'on va bétonner au cas où un attaquant obtient l'exécution de code, c'est même plutôt mauvais signe.

Mais ça part d'un constat : les navigateurs sont régulièrement soumis à des vulnérabilités de ce type, et suivant les cas ces vulnérabilités seront exploitables par un attaquant. Et il y en aura encore à l'avenir, c'est la que la sandbox entre en jeu, pour tenter de limiter l'impact d'un futur attaquant sur le système. Il y a une vraie idée de la sécurité derrière, c'est pas juste une opération de comm...

Je ne reproche pas non plus à Firefox de ne pas avoir de sandbox. Si on me disait que c'était pas la priorité du moment, ou qu'il faudrait plus de développeurs ou autre, je comprendrais. Mais de là à dire que les vulnérabilités ne sont pas exploitables, non, là c'est ridicule.

Dans mon expérience limitée, dans le cadre de WebGL, ces aspects se sont effectivement manifestés dans certains bugs qu'on a corrigés, comme certains plantages avec corruption du tas. Nous les avons pris très au sérieux et les avons déclarés « critiques » parce que, en théorie, c'est bien ce genre de bugs qui conduit à de l'exécution arbitraire de code. Cependant, en pratique, pour autant que je sache, nous n'avons jamais vu d'exploitation de ces bugs, et pour de bonnes raisons : d'abord, une majorité de ces bugs n'est probablement pas réellement exploitable, à plus forte raison avec l'ASLR et la DEP. Mais surtout, ces bugs ont toujours été faciles à corriger, donc ils ont simplement été corrigés avant d'avoir pu être largement exploités.

En théorie ?...
Pas réellement exploitable ?...
Mozilla n'a jamais vu d'exploit réel pour son navigateur ? Sérieusement ?

Plusieurs points importants :
1. Certains bugs restent exploitables malgré l'ASLR et le DEP. Et oui ca s'exploite réellement (au cas où l'auteur en douterait).
2. Les vulns ont beau être corrigées rapidement, dans la vraie vie tous les navigateurs ne sont pas à jour pour autant.
3. Toujours dans la vraie vie, les attaquants ont en mains des vulnérabilités que vous ne possédez pas chez Mozilla. D'où l'intérêt de porter la sécurité en amont et de sandboxer le navigateur dans un processus non-privilégié, au cas où l'attaquant parviendrait à ses fins.

"Pas exploitable", franchement faudrait atterrir...