C’est une erreur de croire que plus un noyau est récent plus il est sécurisé. J’ai encore une machine sous un noyau 2.0 et je vous fiche mon billet que ce noyau est aussi sur voire plus le dernier de Debian. Le noyau 2.6.26 de lenny dispose de toutes les modifications de sécurité des derniers noyaux.
Ou alors tu le fais remonter comme un bug à chaque paquet incriminé. Sans forcément dire que les autres le font.[/quote]
D’après les pages « Security features » cités plus haut, les protections sont appliquées en patchant gcc… Donc il n’y aurait que le paquet gcc à modifier, puis il suffira d’attendre les mises à jour pour le reste…
En effet tu risques de la lire avec plaisir … 
Dans le tableau de ton premier post, j’étais persuadé que c’était Debian dans la première partie et Ubuntu dans la seconde,
donc je voyais Debian avec plein de canari et Ubuntu sans,
pareil pour les RELRO.
Alors effectivement, si c’est l’inverse et que tes tests sont fiables je me suis trompé dans mes conclusions.
Par compte, ton lien vers un test où Debian a le noyau 2.6.26 et les autres distribs ont au moins le 2.6.32 … 
C’est comme si t’organises une course entre 5 gamins dont 4 ont 10 ans et un autre n’a que 6 ans.
Forcement, celui qui a 6 ans rique d’avoir un peu de mal à suivre …
J’avoue j’ai réagi vite et en étant très sûr de mes conclusions, … à tort.
Par contre ma réaction n’avait rien d’aigri,
je voulais juste exprimer ce que je tenais sur le moment pour une vérité.
Ben tu vois si je n’avais pas lu le tableau à l’envers, mon message aurait complètement renversé la discussion.
Mais bon, ce ne sera pas pour cette fois-ci. 
[/quote]
Bah c’est pas grave, errare humanum est.
Ou alors tu le fais remonter comme un bug à chaque paquet incriminé. Sans forcément dire que les autres le font.[/quote]
D’après les pages « Security features » cités plus haut, les protections sont appliquées en patchant gcc… Donc il n’y aurait que le paquet gcc à modifier, puis il suffira d’attendre les mises à jour pour le reste…[/quote]
Donc on a :
- gcc-patch : options à activer par le biais du compilateur gcc, donc patcher ce paquet apporterait lesdites protections aux paquets compilés avec ce gcc patché, j’ai bon ? J’ai vu aussi que de nouvelles options étaient apparues avec gcc 4.5.
- glibc : ce doit être un patch à appliquer sur le paquet du même nom, non ?
- package list : ce doit être une option qui doit être ajoutée spécifiquement lors de la compilation d’une application, j’ai lu que les PIEs, sur des architectures ayant un petit registre (32 bits x86), ça peut causer des problèmes de performances (mais pas sur le 64 bits AMD64 et aucune idée pour les autres architectures).
Pour le reste, le kernel est apparemment assez bien protégé, comme le dit fran.b
Enfin quoi que dans le script du message initial, on voit :
Strict user copy checks: Disabled
Et maintenant quoi faire ?
[quote=“piratebab”]Je n"ai pas vu citer le wiki debian dans ce fil wiki.debian.org/Hardening
concernant le RELRO:
Ah ton lien est intéressant ! Donc Debian a même un joli wiki pour expliquer tout ça.
Cependant, ça reste un wiki, ça ne donne pas ce qui est intégré/inclus ou pas dans la distribution.
Vous n’avez pas un point de vue officiel d’un membre reconnu de Debian sur ce sujet ? 
Salut,
[quote=“Heliox”]
Et maintenant quoi faire ? [/quote]
Un rapport de bogue de priorité wishlist 
[quote=“Clem_ufo”]Salut,
[quote=“Heliox”]
Et maintenant quoi faire ? [/quote]
Un rapport de bogue de priorité wishlist
cf debian.org/Bugs/Developer#severities[/quote]
Thanks ! Je ne connais pas encore toutes les institutions de Debian, merci pour le lien !
Assure toi que ton rapport de bug ne fait pas doublon avec celui qui est dans le lien que j’ai indiqué.
Je le remet pour ceux qui n’ont pas cliqué dessus:
bugs.debian.org/cgi-bin/bugreport.cgi?bug=511811
Salut piratebab,
En même temps le rapport de bogue date de janvier 2009 