Debian et les options de compilation pour la sécurité

Pause Café
#1

Bonjour/Bonsoir,

Un petit sujet à titre de renseignement et de précision.
La sécurité est un domaine non-négligeable en informatique, et en surfant sur le Oueb, je suis tombé là dessus :
linuxfr.org/2010/03/02/26532.html

L’article présente un script qui permet de “checker” les protections des processus et du kernel face aux attaques de type dépassement de pile ou un truc dans le genre… Enfin bref, j’ai executé ce script et les résultats pour Debian m’ont étonnés !
Voilà successivement ce que j’obtiens pour Ubuntu 10.10 Maverick Meerkat puis Debian Squeeze Freezée, toutes 2 64 bits :

[code] gnome-keyring-d 1509 Partial RELRO Canary found NX enabled No PIE
gnome-session 1527 Partial RELRO Canary found NX enabled No PIE
dbus-launch 1564 Partial RELRO Canary found NX enabled No PIE
dbus-daemon 1565 Partial RELRO Canary found NX enabled PIE enabled
gconfd-2 1568 Partial RELRO Canary found NX enabled No PIE
gnome-settings- 1575 Partial RELRO No canary found NX enabled No PIE
gvfsd 1577 Partial RELRO Canary found NX enabled No PIE
compiz 1580 Partial RELRO Canary found NX enabled No PIE
gnome-volume-co 1590 Partial RELRO Canary found NX enabled No PIE
gnome-power-man 1592 Partial RELRO Canary found NX enabled No PIE
gnome-panel 1593 Partial RELRO Canary found NX enabled No PIE
nm-applet 1594 Partial RELRO Canary found NX enabled No PIE
nautilus 1595 Partial RELRO Canary found NX enabled No PIE
polkit-gnome-au 1597 Partial RELRO No canary found NX enabled No PIE
pulseaudio 1602 Full RELRO Canary found NX enabled No PIE
gvfsd-trash 1612 Partial RELRO Canary found NX enabled No PIE
bonobo-activati 1614 Partial RELRO Canary found NX enabled No PIE
wnck-applet 1626 Partial RELRO No canary found NX enabled No PIE
trashapplet 1627 Partial RELRO No canary found NX enabled No PIE
gvfs-gdu-volume 1628 Partial RELRO Canary found NX enabled No PIE
sh 1632 Partial RELRO Canary found NX enabled No PIE
gtk-window-deco 1633 Partial RELRO Canary found NX enabled No PIE
gvfs-afc-volume 1636 Partial RELRO No canary found NX enabled No PIE
gvfs-gphoto2-vo 1639 Partial RELRO Canary found NX enabled No PIE
notification-ar 1644 Partial RELRO Canary found NX enabled No PIE
clock-applet 1645 Partial RELRO Canary found NX enabled No PIE
indicator-apple 1646 Partial RELRO No canary found NX enabled No PIE
indicator-apple 1647 Partial RELRO No canary found NX enabled No PIE
gvfsd-metadata 1652 Partial RELRO Canary found NX enabled No PIE
gconf-helper 1653 Partial RELRO Canary found NX enabled No PIE
indicator-me-se 1656 Partial RELRO No canary found NX enabled No PIE
indicator-appli 1659 Partial RELRO No canary found NX enabled No PIE
indicator-sound 1661 Partial RELRO No canary found NX enabled No PIE
indicator-sessi 1675 Partial RELRO No canary found NX enabled No PIE
gvfsd-burn 1678 Partial RELRO Canary found NX enabled No PIE
gnome-screensav 1682 Partial RELRO Canary found NX enabled No PIE
gdu-notificatio 1688 Partial RELRO No canary found NX enabled No PIE
python 1726 Partial RELRO Canary found NX enabled No PIE
update-notifier 1828 Partial RELRO Canary found NX enabled No PIE
firefox 1919 Partial RELRO Canary found NX enabled No PIE
run-mozilla.sh 1924 Partial RELRO Canary found NX enabled No PIE
firefox-bin 1928 Full RELRO Canary found NX enabled PIE enabled
gnome-terminal 1958 Partial RELRO Canary found NX enabled No PIE
bash 1960 Partial RELRO Canary found NX enabled No PIE

  • Kernel protection information:

    Description - List the status of kernel protection mechanisms. Rather than
    inspect kernel mechanisms that may aid in the prevention of exploitation of
    userspace processes, this option lists the status of kernel configuration
    options that harden the kernel itself against attack.

    Kernel config: /boot/config-2.6.32-25-generic

    Warning: The config on disk may not represent running kernel config!

    GCC stack protector support: Enabled
    Strict user copy checks: Disabled
    Enforce read-only kernel data: Enabled
    Restrict /dev/mem access: Enabled
    Restrict /dev/kmem access: Enabled

  • grsecurity / PaX: No GRKERNSEC[/code]

[code] Does the CPU support NX: Yes

     COMMAND    PID RELRO             STACK CANARY           NX/PaX        PIE

gnome-keyring-d 25951 No RELRO No canary found NX enabled No PIE
gnome-session 25975 No RELRO No canary found NX enabled No PIE
dbus-launch 26012 No RELRO No canary found NX enabled No PIE
dbus-daemon 26013 Partial RELRO No canary found NX enabled PIE enabled
seahorse-agent 26023 No RELRO No canary found NX enabled No PIE
gvfsd 26025 No RELRO No canary found NX enabled No PIE
gconfd-2 26030 No RELRO No canary found NX enabled No PIE
gnome-power-man 26034 No RELRO No canary found NX enabled No PIE
gnome-settings- 26039 No RELRO No canary found NX enabled No PIE
gnome-panel 26043 No RELRO No canary found NX enabled No PIE
gvfs-gdu-volume 26045 No RELRO No canary found NX enabled No PIE
gvfs-afc-volume 26050 No RELRO No canary found NX enabled No PIE
gvfs-gphoto2-vo 26053 No RELRO No canary found NX enabled No PIE
nautilus 26054 No RELRO No canary found NX enabled No PIE
bonobo-activati 26056 No RELRO No canary found NX enabled No PIE
compiz 26058 No RELRO No canary found NX enabled No PIE
python 26059 No RELRO No canary found NX enabled No PIE
nm-applet 26063 No RELRO No canary found NX enabled No PIE
update-notifier 26064 No RELRO No canary found NX enabled No PIE
kerneloops-appl 26065 No RELRO Canary found NX enabled No PIE
polkit-gnome-au 26066 No RELRO No canary found NX enabled No PIE
gdu-notificatio 26068 No RELRO No canary found NX enabled No PIE
trashapplet 26079 No RELRO No canary found NX enabled No PIE
gvfsd-trash 26082 No RELRO No canary found NX enabled No PIE
gnome-screensav 26085 No RELRO No canary found NX enabled No PIE
redshift 26086 No RELRO No canary found NX enabled No PIE
mixer_applet2 26097 No RELRO No canary found NX enabled No PIE
gvfsd-metadata 26107 No RELRO No canary found NX enabled No PIE
sh 26108 No RELRO No canary found NX enabled No PIE
compiz-decorato 26109 No RELRO No canary found NX enabled No PIE
gvfsd-burn 26111 No RELRO No canary found NX enabled No PIE
icedove 26121 No RELRO No canary found NX enabled No PIE
run-mozilla.sh 26137 No RELRO No canary found NX enabled No PIE
icedove-bin 26141 No RELRO No canary found NX enabled No PIE
rhythmbox 26206 No RELRO No canary found NX enabled No PIE
firefox-bin 26288 No RELRO No canary found NX enabled No PIE
gvfsd-http 26312 No RELRO No canary found NX enabled No PIE
gnome-terminal 26597 No RELRO No canary found NX enabled No PIE
bash 26599 No RELRO No canary found NX enabled No PIE
bash 26712 No RELRO No canary found NX enabled No PIE
gnome-system-mo 28708 No RELRO No canary found NX enabled No PIE
notification-da 29700 No RELRO No canary found NX enabled No PIE

  • Kernel protection information:

    Description - List the status of kernel protection mechanisms. Rather than
    inspect kernel mechanisms that may aid in the prevention of exploitation of
    userspace processes, this option lists the status of kernel configuration
    options that harden the kernel itself against attack.

    Kernel config: /boot/config-2.6.32-5-amd64

    Warning: The config on disk may not represent running kernel config!

    GCC stack protector support: Enabled
    Strict user copy checks: Disabled
    Enforce read-only kernel data: Enabled
    Restrict /dev/mem access: Enabled
    Restrict /dev/kmem access: Enabled
    [/code]

Les différences se situent aux niveaux de RELRO, des Canaries.

J’ai toujours entendu dire que Debian était Top niveau sécurité, alors là je suis étonné
D’où ma question assez pointue : pourquoi Debian n’active-t-elle pas ces protections lors de la compilation de ces paquets ?

Peut-être les paquets sont-ils tous recompilés avec ces options lors du passage en Stable ?

PS : Bien évidemment on ne répétera jamais assez qu’une bonne sécurité ne repose pas que sur des mécanismes internes supplémentaires, bien que ceux-ci ajoutent un petit plus, ils sont inefficaces dans un système n’ayant pas le minimum de sécurité, à savoir un bon mot de passe, un pare-feu bien configuré. Mais c’est pas une raison…

#2

Et bien je rajoute un lien qui propose des tests plus poussé, Debian arrive en dernière position, comment cela se fait-il ?

(lien en anglais) :
labs.mwrinfosecurity.com/project … &view=news

Et je reprends une phrase de la conclusion :
Maybe it is time to start asking your favourite distribution about their policy for security mechanisms described above?

#3

Salut,

WOT estime que ton site a mauvaise réputation en crédibilité :slightly_smiling:

#4

wwwaaaa plein de termes techniques ! (en plus ça parle de debordement de tampon,les Anglais débarquent !!!)

décidément, les DD sont vraiment des irresponsables… laisser passer des boulettes pareilles.

ils on rien appris depuis la faille d’openSSH, pas croyable, je change de distro ce soir même! j’ai un vieux CD obtenu avec planète linux d’une mandrake 7.2 qui traine, on va voir si ça tourne sur mon amd64 un kernel 2.4.0 !

non honnêtement, à moins qu’on me démontre comment faire un buffer stack overflow sur compiz en arrivant à exécuter du code malveillant permettant de faire un remote root exploit, perso je dors sur mes deux oreilles. (même si compiz n’est pas un exemple de stabilité sous sid)

ouais moi aussi je sais claquer du vocabulaire technique (et avec de morceaux de compiz dedans)!

bon j’arretes de troller je suis attendu à l’apéro

#5

+1
J’aime ton commentaire utile qui témoigne d’une très belle mentalité.
Franchement bravo :023

:unamused:

#6

C’est interessant comme info.
As-tu essayé d’activer SELinux?

#7

@Heliox : Il est précisé dans ton lien que le faible niveau de Testing est dû à un bug qui a été rapporté.
Pas d’inquiétudes fondées pour les débianneux donc.

Par contre une traduction ( pour les humains normaux j’entends ) serait pas mal. Tout ces noms barbares me font patauger.
Si j’ai bien compris il s’agit d’options de compilation qui ne sont pas restreinte au simple kernel mais aussi aux applications utilisateurs :question:

Après il y a des options spécifiques aux serveurs mais qui pourraient être dommageable pour une utilisation desktop: grsecurity, PIE ??? Non ??

#8

Ça n’a pas le moindre rapport. Le script ne regarde que de manière statique comment les binaires ont étaitent compilé, il ne cherche pas à lancer d’attaque.

#9

Ça n’a pas le moindre rapport. Le script ne regarde que de manière statique comment les binaires ont étaitent compilé, il ne cherche pas à lancer d’attaque.[/quote]
ah… u_u autant pour moi.

#10

Salut,

Pourquoi ne pas comparer à kernel égal les distributions ? Pour arriver à nous démontrer que la Debian de l’ année dernière est moins fiable que la toute dernière d’une autre distribution ?

#11

J’ai lancé le test par curiosité sur une de mes sid (32 bits) à jour, c’est pareil.

Mais ca n’est pas la faute du kernel, à la limite, s’il devait y avoir une différence au niveau des resultats de ce test, ca serait plutôt par rapport à la branche et/.ou l’architecture, puisque ca concerne la facon dont est compilé le paquet (et aussi loin que je sache, un paquet est compilé x fois par branche, avec x = nombre d’architectures supportées x86, amd64, arm, mips, powerpc…etc).

Ce test me laisse un peu perplexe quand même : je me dis que les concepteurs de debian ne tombent pas des nues et ne sont pas des débutants, donc, soit il y a des gardes fous qui rendent inutiles ces sécurités, soit la mise en place de ces options à la compilations posent d’autres problèmes (de sécurité ou de performance ou de retro-compatibilité ou que sais-je… en aval) soit les 2. Ca serait interessant d’avoir l’avis des concepteurs sur ce sujet…

#12

Mêmes résultats sur une archlinux et une slackware. En gros, seuls sshd et cupsd sont « protégés ».

Soit il prennent leur temps avant de se décider (on n’installe pas forcément la dernière killer-feature à la mode), soit ils préfèrent laisser le choix aux développeurs des applis, plutôt que de patcher à tout va ?
N’est pas « système d’exploitation universel » qui veut…

#13

[quote=“dric64”]J’ai lancé le test par curiosité sur une de mes sid (32 bits) à jour, c’est pareil.

Mais ca n’est pas la faute du kernel, à la limite, s’il devait y avoir une différence au niveau des resultats de ce test, ca serait plutôt par rapport à la branche et/.ou l’architecture, puisque ca concerne la facon dont est compilé le paquet (et aussi loin que je sache, un paquet est compilé x fois par branche, avec x = nombre d’architectures supportées x86, amd64, arm, mips, powerpc…etc).

Ce test me laisse un peu perplexe quand même : je me dis que les concepteurs de debian ne tombent pas des nues et ne sont pas des débutants, donc, soit il y a des gardes fous qui rendent inutiles ces sécurités, soit la mise en place de ces options à la compilations posent d’autres problèmes (de sécurité ou de performance ou de retro-compatibilité ou que sais-je… en aval) soit les 2. Ca serait interessant d’avoir l’avis des concepteurs sur ce sujet…[/quote]
C’est vrai que ça serait intéressant d’avoir l’avis d’un dev, mais je pense qu’ils ne sont pas accessibles comme ça ?
Y’a un moyen de leur poser la question si on n’est qu’un “petit” utilisateur “quelconque” ?

#14

debian.org/security/faq#contact

Debian est un projet libre faut pas voir les développeurs comme des monstres intouchables. Venez aux évènements Debian (comme la MiniDebConf à Paris) vous en rencontrerais, vous comprendrais que Debian ce n’est pas un cercle fermé de développeurs mais au contraire que c’est ouvert aux discutions que chacun a son mot à dire et qu’il n’y a pas à avoir peur de qui que ce soit. C’est ça un projet libre communautaire :slightly_smiling:

#15

Et puis quand on regarde ce que font les autres distributions :
Ubuntu : wiki.ubuntu.com/Security/Features
Fedora : fedoraproject.org/wiki/Security/Features
OpenSUSE : en.opensuse.org/openSUSE:Security_Features

Il y aurait peut-être quelque chose à faire, car ces précautions, même si elles ne protègent pas directement, elles permettent de limiter l’exploitation d’une faille par une personne ou un programme mal intentionné.

Et pour la plupart des mécanismes, il s’agit d’options de compilation. Et la security-team ne s’occupe pas de gérer les paquets, on a peu de chance de voir de pareilles avancées niveau sécurité sans une impulsion générale et bien soutenue par le grand nombre (vu qu’il n’y a pas de chef à proprement parler dans Debian).
Et puis, je me vois mal arriver en disant: « hé ! vous avez vu, les cousins d’Ubuntu ils sont meilleurs que vous dans ce domaine là », je vais me faire remballer vite-fait :smiley:

Il n’y a pas un système de vote, ou d’OpenFATE dans Debian pour proposer l’idée ?
L’idée en question n’est pas bien compliquée à mettre en œuvre, juste des options à rajouter lors de la compilation d’un paquet, donc bon, il n’y a pas de véritable obstacle pour la mise en œuvre :smiley:

Bien à vous.

#16

De ce que je comprends, tu n’as rien compris aux résultats du test en fait.
As tu été voir ce qu’est un canari, ce que veut dire RELRO
et donc comment interpréter les résultats de ton premier post.

De ce que j’en lis, Debian est bien plus sécurisée qu’Ubuntu.

Avant de faire dans le sensationnalisme, vaut mieux être sur de ce qu’on raconte.

#17

[quote=“eol”]De ce que je comprends, tu n’as rien compris aux résultats du test en fait.
As tu été voir ce qu’est un canari, ce que veut dire RELRO
et donc comment interpréter les résultats de ton premier post.

De ce que j’en lis, Debian est bien plus sécurisée qu’Ubuntu.

Avant de faire dans le sensationnalisme, vaut mieux être sur de ce qu’on raconte.[/quote]
Très bien ! j’aime me tromper, c’est d’ailleurs pour ça que je poste dans ce topic et que je demande des infos sur ce sujet.
Montre moi où j’ai tort dans ce cas, avant d’accuser de “sensationnalisme”, argumente un peu tes messages (là ce que je vois, c’est un message sans contenu et qui ne fait pas avancer le train).
Après je ne suis pas un spécialiste sur la question, je le reconnais, mais oui je pense avoir compris ce qu’était les “stack-canary” et ce que veut dire RELRO. À vrai dire j’en viens à me demander si toi tu sais ce que ça veut dire et si tu comprends ce qui est montré.
Regarde le lien de mon premier message, tu comprendras que dans le test, Debian Lenny est à la masse. Et d’après le petit script que j’ai effectué sans tout comprendre (je le reconnais aussi), il s’avère que les résultats sont toujours aussi négatifs (d’où ce topic).

Allez, argumente tout-ça et reposte, je lirai les réponses avec plaisir.

C’est dingue les réactions aigries que l’on peut voir des fois…
Le genre de message qui n’apporte rien et qui ne fait pas progresser la discussion.

À bon entendeur.

#18

En effet tu risques de la lire avec plaisir … :laughing:

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 … :whistle:
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. :mrgreen:

#19

Concernant les histoire de version de kernel, il y a 2 façons de voir:

  • soit on compare 2 kernel de version identique (2.6.32 par ex)
  • soit on compare 2 distro de génération identiques (décembre 2010 par ex, soit squeeze en anticipant un peu, et la derniére ubuntu)

La 2eme option me semble plus réaliste vue de l’utilisateur.
Ce qui est certains, c’est que les devs kernel ubuntu et debian se rencontrent régulièrement (des compte rendu de réunion sont dispos).
Il serait en effet intéressant de bien comprendre ce que veulent dire ces tests avant de poser la question aux devs.

#20

Elle peut très bien éditer des règles ou des recommendations en ce sens.

Ou alors tu le fais remonter comme un bug à chaque paquet incriminé. Sans forcément dire que les autres le font.