Linux? - Page 201

https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options
C'est génial cette page, et c'est fou de voir que parfois, la sécurité tient à vraiment pas grand chose...

Quelques options supplémentaires ont été ajoutées depuis cette liste vieille de deux ans, dont récemment HARDEN_TTY. Mais c'est un très bon début, en effet.

Il fout des claques le compte tweeter. Ils relèvent toutes les failles du kernel qui n'existeraient pas avec GrSec. Et en effet, on en voit une tripotée.

RANDSTRUCT est une très mauvaise idée:

• Ça nuit à la performance, parce que les structures du noyau sont soigneusement optimisées pour l'ordre optimal, prenant aussi en compte les effets de cache.
• Ça rend les compilations non-reproduisibles. (En particulier, ça va directement à l'encontre de l'effort "reproducible builds" si cher à Debian qui t'est si chère.)
• Ça randomise en temps de compilation, donc ça ne sert pas à grand chose pour une grosse distribution comme Fedora ou Debian où des milliers d'utilisateurs utilisent le même binaire de noyau, publiquement téléchargeable. Il faut compiler son propre noyau pour que ça serve vraiment.

CONSTIFY est aussi foireux car non conforme au standard C. (C'est un plugin GCC qui lui fait violer le standard C.) La bonne solution est d'explicitement marquer const les structures qui devraient l'être, pas d'essayer de le deviner magiquement et d'exiger __no_const partout où l'heuristique se trompe. Aussi parce que faire ça magiquement fait que les développeurs prennent la mauvaise habitude de s'attendre à ça, de ne plus rien marquer const, et du coup, s'il y a un faux négatif, la sécurité diminue au lieu d'augmenter.

- peut-on avoir une sécurité correct sans le moindre sacrifice ? J'en doute, auquel cas la question de la dégradation des perfs ne se pose pas, il faut juste savoir comment ça va dégrader.
- effectivement, mais n'est-ce pas une infime minorité des paquets qui auraient besoin de ça ?
- c'est déjà mieux que rien, non ?

Et il y a des avantages ne serait-ce qu'en terme de débogage, ce qui a aussi pour effet d'améliorer la sécurité en corrigeant des failles potentielles.

Un truc randomisé est l'horreur à déboguer!

J'imagine qu'en étant fin, tu n'utilise RANDSTRUCT qu'après avoir débogué. Ce n'est qu'après que RANDSTRUCT pourra servir à révéler des bugs jusque là invisibles. C'est tellement évident que j'avais déjà immaginé une sorte de RANDSTRUCT (et j'en avais parlé sur yN) dans le seul but de déboguer.

Tiens, sur le même sujet : http://arstechnica.com/security/2016/02/most-software-already-has-a-golden-key-backdoor-its-called-auto-update/
Très intéressant je pense.

(RANDSTRUCT) nuit à la performance, parce que les structures du noyau sont soigneusement optimisées pour l'ordre optimal, prenant aussi en compte les effets de cache.

Ca tombe bien, il y a depuis longtemps (toujours ?) RANDSTRUCT_PERFORMANCE, qui tient compte des lignes de cache, au prix d'une randomisation moindre.

Ça rend les compilations non-reproduisibles. (En particulier, ça va directement à l'encontre de l'effort "reproducible builds" si cher à Debian qui t'est si chère.)

D'après ce que je vois dans la config du kernel grsec Debian, RANDSTRUCT + RANDSTRUCT_PERFORMANCE sont activés, donc le package kernel grsec Debian n'a pas l'air concerné.
Corsac, qui s'occupe de ces packages, est un chercheur en sécurité, et il a raison de mettre RANDSTRUCT.

Ça randomise en temps de compilation, donc ça ne sert pas à grand chose pour une grosse distribution comme Fedora ou Debian où des milliers d'utilisateurs utilisent le même binaire de noyau, publiquement téléchargeable. Il faut compiler son propre noyau pour que ça serve vraiment.

C'est exact, et c'est du reste ce que je fais sur celles des diverses machines que j'administre sur lesquelles j'ai installé des kernels grsec.
Cependant, comme RANDSTRUCT change à chaque build du kernel, et qu'il y en a tous les quelques jours... même avec des kernels distro, il est évident que c'est vite chiant pour les attaquants de faire des exploits binaires contre des kernels grsec (surtout qu'ils ont énormément moins d'infoleaks sur le kernel mainline, que l'ASLR est plus fort, etc.). Bref, le compromis n'est pas idiot, et c'est clairement mieux qu'un kernel mainline plus largement utilisé, faible en auto-protection, et qui ne randomise rien !

La bonne solution est d'explicitement marquer const les structures qui devraient l'être, pas d'essayer de le deviner magiquement et d'exiger __no_const partout où l'heuristique se trompe. Aussi parce que faire ça magiquement fait que les développeurs prennent la mauvaise habitude de s'attendre à ça, de ne plus rien marquer const, et du coup, s'il y a un faux négatif, la sécurité diminue au lieu d'augmenter.

Mais l'histoire a montré que 1) les devs kernel ne mettent pas const là où il faut, 2) même quand on leur mâche le boulot (soumission de patches individuels de constification - Emese Revfy l'a fait il y a des années), le taux d'acceptation de tels patches par les mainteneurs est dégueulasse, et 3) comme checkpatch.pl ne flagge pas la plupart des structures qui devraient être constifiées, de la merde continue à être injectée dans le tuyau à chaque release, sans que les contributeurs sachent qu'ils sont en train de mal faire...
CONSTIFY n'a pas toujours été écrit comme plugin GCC. En 2011, c'était encore une liste d'ajouts de "const", représentant environ le tiers de PaX, qui ne faisait qu'environ 2 MB à l'époque (il a triplé depuis, et grsec est encore plus long !). C'était chiant à maintenir. Non seulement le fait de passer à un plugin GCC a gagné du temps à Emese Revfy, lui permettant de se concentrer sur d'autres tâches utiles, mais si je me souviens bien, le plugin a constifié des structures qui ne l'étaient pas dans la version manuelle de la constification.
CONSTIFY n'est pas parfait, mais encore une fois, c'est une bien meilleure solution que le kernel mainline, parce que s'appliquant à beaucoup plus d'instances de structs ops... Sur un kernel mainline, la constification éparse est parfois la dernière ligne de défense, vu que le kernel mainline déférence sans problème une struct ops créée par l'attaquant en user-space (sauf processeurs rares, et encore faudrat-il que l'implémentation de mainline soit correcte, le contraire a été brillamment démontré ces jours-ci), et exécute sans broncher le payload user-space pointé par la struct ops du user-space (sauf processeurs un peu moins rares). Mais si la constification empêche l'attaquant d'écrire là où il voudrait, c'est déjà ça de gagné.

Lionel Debroux (./6008) :

(RANDSTRUCT) nuit à la performance, parce que les structures du noyau sont soigneusement optimisées pour l'ordre optimal, prenant aussi en compte les effets de cache.

Ca tombe bien, il y a depuis longtemps (toujours ?) RANDSTRUCT_PERFORMANCE, qui tient compte des lignes de cache, au prix d'une randomisation moindre.

Bref, de la securité à moitié avec de la performance à moitié, poubelle!

D'après ce que je vois dans la config du kernel grsec Debian, RANDSTRUCT + RANDSTRUCT_PERFORMANCE sont activés, donc le package kernel grsec Debian n'a pas l'air concerné.

Si. RANDSTRUCT est fondamentalement incompatible avec le concept de "reproducible builds":
https://reproducible-builds.org/
https://wiki.debian.org/ReproducibleBuilds
et évidemment le build de linux-grsec n'est pas reproduisible (pas de détails parce que les différences sont trop grandes, pas étonnant étant donné que toutes les structures sont totalement différentes, et donc aussi tout le code qui les utilise).

Bref, de la securité à moitié avec de la performance à moitié, poubelle!

Oh oui, c'est sûr qu'il vaut mieux de la sécurité zéro avec zéro changement de performance ou de taille sur la plupart des RISC, et aussi d'ailleurs certains CISC pour lesquels réclamer quelque chose à un déplacement zéro prend autant de place que réclamer quelque chose à un déplacement faible - ce qui est précisément le cas du x86/x86_64, au moins pour certaines instructions.
RANDSTRUCT + RANDSTRUCT_PERFORMANCE est un compromis, et un compromis pas si idiot que ça, je le répète.
Et puis zut, un extrémiste libriste comme toi devrait aimer RANDSTRUCT: les modules kernel propriétaires dont le code n'a pas été adapté ne compilent pas.

Concernant la reproductibilité: je connais les liens que tu postes, merci. Ce que je voulais écrire par "donc le package kernel grsec Debian n'a pas l'air concerné", était que Corsac se fout de la reproductibilité pour ce package-là, et il a bien raison.

Lionel Debroux (./6010) :
Et puis zut, un extrémiste libriste comme toi devrait aimer RANDSTRUCT: les modules kernel propriétaires dont le code n'a pas été adapté ne compilent pas.

C'est sûr que RANDSTRUCT doit foutre le boxon avec les blobs. S'il y a des .o précompilés qui touchent aux structures du noyau, le module ne marche plus du tout.

Concernant la reproductibilité: je connais les liens que tu postes, merci. Ce que je voulais écrire par "donc le package kernel grsec Debian n'a pas l'air concerné", était que Corsac se fout de la reproductibilité pour ce package-là, et il a bien raison.

Donc il sera probablement viré de Debian (ou RANDSTRUCT sera désactivé par un NMU) quand la reproduisibilité deviendra obligatoire.

bon c'est fini le combat de coqs oui? Le sujet technique est intéressant mais vous monopolisez le micro la, on peut plus en placer une

Sérieux j'ai pas envie de participer a ce genre de sujet quand la mayonnaise part comme ca.

Je partage cet avis et autant comme quoi au début on était sur des informations et des explications, là on sent revenir de vieilles rancunes... Vous ne partagez pas le même avis, soites, vous avez chacun vos arguments, ok... maintenant un topic "général" Linux n'est ptet pas le meilleur endroit pour en parler... Je sais que la fonction est récente mais "digresser" est là pour ça...

(à titre de rappel le sujet a d'abord été abordé dans le topic iPad puis rappatrié ici, mais vu qu'il y a de la matière a exposer d'une part et un débat sur la "bonne" approche d'autre part, ça vaut un topic dédié amha)

C'est vrai que ça devient technique et très spécifique, là
A quand une feature avec des vrais forks, présentés graphiquement, puis la fonction "merge" ? #yNFeature

puis après on ajoute une fonctionnalité pour accéder aux topics de yaronet depuis git?

Et pourquoi pas. Synchro off-line, pull/push/commit... tout ça.

le pbm c'est qu'apres on pourra plus critiquer RMS qui recoit ses pages web par email.

je sais pas si la nouvelle est bonne ou mauvaise

Bah, c'est pas spécialement mauvais SQL Server, si ?

À ma connaissance, il a plutôt bonne réputation

Oui, voilà, c'est pour ça que ça m'étonne que ça fasse rire squalyl

Disons que je ne pense pas que Linux à attendu SQL Server pour supporter le SQL et faire des serveurs Web de qualité.

le SQL ne se limite pas au web d'une part, et d'autre part MS SQL peut avoir un certain nombre d'avantages sans que les autres soient pourris pour autant.

Et en plus ça permet de faire tourner le même moteur partout, c'est un critère intéressant.

J'ai du mal à voir les avantages : 8 Go sur le disque dur, syntaxe SQL propre, etc... Et s'il s'agit de faire tourner la même chose partout, y'a PostegreSQL.

Perf, support, pérennité, prix ? (J'en sais rien, je connais pas spécialement )

Se placer en concurrence directe d'Oracle DB Server.

ca permet ptet de rendre lunix plus vendable a des CEO non techniques?

Je dirais plutôt qu'à l'inverse, Linux est un marché chez les serveurs, et que jusqu'à présent SQL Server n'en faisait pas parti. C'est plutôt pertinent.