Je suis désolé de ce que je vais poster, mais je pense que la compilation sécurisé tel que Mandriva l'a historiquement fait reste relativement faible. Je m'explique.
Historiquement, c'est via la macro %serverbuild qui déclenche la fameuse compilation sécurisé. C'est juste des options de gcc qu'on peut voir ici :
De base, tout les paquets sont compilés avec FORTIFY_SOURCE, qui va activer divers vérifications à la compilation pour interdire le code jugé non sécurisé. Ce qui fait parfois bien chier quand il faut patcher 45 fois la même erreur, mais depuis le temps, les correctifs ont été poussés upstream par toutes les distributions qui activent ça.
Oden a aussi rajouté des patchs sur php pour rendre le truc plus secure, mais ça reste une gageure selon moi. Certains paquets sont compilés avec des options spécifiques du linker, comme apache.
Mais au delà de ça, des distributions comme Ubuntu ou RHEL sont allés beaucoup plus loin, comme le détail la page d'Ubuntu
Des choses simples comme activer l'ALSR pour apache ( vu que apache lance des processus pour chaque requête, ça rends la chose plus efficace ), bloquer les protocoles réseaux rares ( comme Debian va le faire dans Wheezy ) pourraient être explorés et ajoutés. Et je parle pas de choses bien plus couteuses en temps comme l'usage d'un security module comme selinux ou apparmor
J'ai pas le sentiment que grand monde se soit penchés sur les choses depuis 2007, mais peut être que je me trompe. Perso, je mets pas mal d'espoir dans systemd pour que des options comme NoNewPrivileges ou PrivateTmp soient activés ( http://0pointer.de/blog/projects/security.html ) explicitement par les unités envoyés upstreams. Mais pour ça, faudrait que des gens se penchent sur le sujet, en essayant par exemple de les utiliser en production pour remonter des bugs ( https://bugzilla.redhat.com/show_bug.cgi?id=917404 )…
Mais bon, d'ici 2/3 ans, le logiciel libre sera encore un peu plus blindés qu'aujourd'hui, et encore plus qu'hier.
[^] # Re: Je suis de mauvaise foi
Posté par Misc (site web personnel) . En réponse à la dépêche Mandriva, MBS et les PME. Évalué à 10.
Je suis désolé de ce que je vais poster, mais je pense que la compilation sécurisé tel que Mandriva l'a historiquement fait reste relativement faible. Je m'explique.
Historiquement, c'est via la macro %serverbuild qui déclenche la fameuse compilation sécurisé. C'est juste des options de gcc qu'on peut voir ici :
En pratique, sur une mageia 2, ça se contente juste de rajouter -fstack-protector-all, vu que %configure a déjà tout le reste. L'option protége contre les buffers overflow : http://www.linuxfromscratch.org/hints/downloads/files/ssp.txt ).
De base, tout les paquets sont compilés avec FORTIFY_SOURCE, qui va activer divers vérifications à la compilation pour interdire le code jugé non sécurisé. Ce qui fait parfois bien chier quand il faut patcher 45 fois la même erreur, mais depuis le temps, les correctifs ont été poussés upstream par toutes les distributions qui activent ça.
Oden a aussi rajouté des patchs sur php pour rendre le truc plus secure, mais ça reste une gageure selon moi. Certains paquets sont compilés avec des options spécifiques du linker, comme apache.
Mais au delà de ça, des distributions comme Ubuntu ou RHEL sont allés beaucoup plus loin, comme le détail la page d'Ubuntu
https://wiki.ubuntu.com/Security/Features
Des choses simples comme activer l'ALSR pour apache ( vu que apache lance des processus pour chaque requête, ça rends la chose plus efficace ), bloquer les protocoles réseaux rares ( comme Debian va le faire dans Wheezy ) pourraient être explorés et ajoutés. Et je parle pas de choses bien plus couteuses en temps comme l'usage d'un security module comme selinux ou apparmor
J'ai pas le sentiment que grand monde se soit penchés sur les choses depuis 2007, mais peut être que je me trompe. Perso, je mets pas mal d'espoir dans systemd pour que des options comme NoNewPrivileges ou PrivateTmp soient activés ( http://0pointer.de/blog/projects/security.html ) explicitement par les unités envoyés upstreams. Mais pour ça, faudrait que des gens se penchent sur le sujet, en essayant par exemple de les utiliser en production pour remonter des bugs ( https://bugzilla.redhat.com/show_bug.cgi?id=917404 )…
Mais bon, d'ici 2/3 ans, le logiciel libre sera encore un peu plus blindés qu'aujourd'hui, et encore plus qu'hier.