Les chiffres le montrent, il vaut mieux utiliser les dérivées ça réduit les failles (ou pas).
La différence entre Red Hat et CentOS montre bien qu’on ne peut pas se fier aux chiffres. Qui plus est, ceux-ci ne permettent pas de comparer l’importance des failles qu’ils concernent.
Les distributions ont pas mal de failles qui viennent de l’amont (et même du matériel !). Après, elles ont un certain nombre de failles propres, généralement petites.
Cela dit, te souviens-tu sur les autres distributions (que Debian et dérivées), dans les quelques années passées, d’aussi grosses failles spécifiques que celles que j’ai citées ?
Ensuite chaque admin sys a toujours ses préférences sur la distribution de son cœur (souvent celle qu'il connaît depuis longtemps)
Je n’aime pas trop Debian, mais pas plus ce qu’est devenu Fedora. Et mon choix actuel ne se porte sur aucune des deux. Mais il ne fait pas passer la sécurité devant les autres critères, alors que là, je n’envisage que cette question.
Il a aussi tendance à dire « X est nul parce que » plutôt que « Y est bien parce que », ou « y a des trous dans X » (alors qu'il y en a aussi dans Y).
SELinux déjà configuré ne te semble pas un argument ? Après, peut-être que d’autres distributions en fournissent déjà une configuration fonctionnelle, je ne sais pas. Si tu en sais plus que moi sur SELinux sous Debian, n’hésite pas à nous éclairer.
Avec Fedora, Red Hat et CentOS, on en est sûr que SELinux est fonctionnel, parce qu’il est activé par défaut.
Après, mon avis personnel, c’est qu’il aurait dû être possible de faire SELinux sans une syntaxe aussi absconse et une manipulation aussi lourde. De ce fait, je ne l’utilise pas. Si je voulais l’utiliser, je me poserais la question d’essayer de le faire fonctionner sur ma distribution, ou de repasser sur Fedora ou CentOS pour au moins partir d’une configuration de base parfaitement fonctionnelle, afin de m’ennuyer le moins possible à régler ce truc.
Pour le reste, concernant Fedora et Red Hat, si elles s’accrochent encore à Sendmail 8, la première chose à faire est bien sûr de le remplacer par Postfix (curieusement, la dernière CentOS que j’ai essayée le choisissait par défaut, contrairement à la Fedora de l’époque).
Une autre considération intéressante concernant la sécurité, c’est la rapidité de prise en charge des failles amont.
La prise en charge de Spectre/Meltdown a été assez révélatrice à ce niveau. openSUSE (que je n’utilise pas non plus) s’est montrée particulièrement réactive à ce niveau, alors qu’Ubuntu a été plutôt à la traîne, étant quasiment la seule distribution majeure à ma connaissance à ne sortir un correctif qu’à la date de divulgation initialement prévue de ces failles. Red Hat a un peu fait bande à part, en étant prévenue plus vite, et en fournissant des correctifs d’Intel que ni les autres distributions ni le noyau officiel n’ont finalement retenus, semble-t-il pour des questions de performance.
Ubuntu a aussi privilégié la stabilité sur la sécurité en revenant sur les correctifs de firmware au moment où l’on s’est aperçu que ceux d’Intel posaient des problèmes de stabilité sur certains de leurs processeurs, et en attendant d’avoir du recul avant de remettre leur version ultérieure. D’autres distributions ne sont pas revenues en arrière (Arch Linux), ou ont remis la version ultérieure des correctifs quasiment immédiatement sans attendre d’avoir du recul dessus. C’est un choix.
Je n’ai pas fait le choix de la sécurité comme priorité absolue (d’ailleurs, j’utilise Xubuntu sur une de mes machines...), mais si je le faisais, je n’utiliserais ni Debian, ni une de ses dérivées.
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone
[^] # Re: Sécurité
Posté par Arthur Accroc . En réponse au journal Lancer un programme sans accès au réseau, merci les espaces de noms réseaux. Évalué à 2. Dernière modification le 09 mars 2019 à 18:40.
La différence entre Red Hat et CentOS montre bien qu’on ne peut pas se fier aux chiffres. Qui plus est, ceux-ci ne permettent pas de comparer l’importance des failles qu’ils concernent.
Les distributions ont pas mal de failles qui viennent de l’amont (et même du matériel !). Après, elles ont un certain nombre de failles propres, généralement petites.
Cela dit, te souviens-tu sur les autres distributions (que Debian et dérivées), dans les quelques années passées, d’aussi grosses failles spécifiques que celles que j’ai citées ?
Je n’aime pas trop Debian, mais pas plus ce qu’est devenu Fedora. Et mon choix actuel ne se porte sur aucune des deux. Mais il ne fait pas passer la sécurité devant les autres critères, alors que là, je n’envisage que cette question.
SELinux déjà configuré ne te semble pas un argument ? Après, peut-être que d’autres distributions en fournissent déjà une configuration fonctionnelle, je ne sais pas. Si tu en sais plus que moi sur SELinux sous Debian, n’hésite pas à nous éclairer.
Avec Fedora, Red Hat et CentOS, on en est sûr que SELinux est fonctionnel, parce qu’il est activé par défaut.
Après, mon avis personnel, c’est qu’il aurait dû être possible de faire SELinux sans une syntaxe aussi absconse et une manipulation aussi lourde. De ce fait, je ne l’utilise pas. Si je voulais l’utiliser, je me poserais la question d’essayer de le faire fonctionner sur ma distribution, ou de repasser sur Fedora ou CentOS pour au moins partir d’une configuration de base parfaitement fonctionnelle, afin de m’ennuyer le moins possible à régler ce truc.
Pour le reste, concernant Fedora et Red Hat, si elles s’accrochent encore à Sendmail 8, la première chose à faire est bien sûr de le remplacer par Postfix (curieusement, la dernière CentOS que j’ai essayée le choisissait par défaut, contrairement à la Fedora de l’époque).
Une autre considération intéressante concernant la sécurité, c’est la rapidité de prise en charge des failles amont.
La prise en charge de Spectre/Meltdown a été assez révélatrice à ce niveau. openSUSE (que je n’utilise pas non plus) s’est montrée particulièrement réactive à ce niveau, alors qu’Ubuntu a été plutôt à la traîne, étant quasiment la seule distribution majeure à ma connaissance à ne sortir un correctif qu’à la date de divulgation initialement prévue de ces failles. Red Hat a un peu fait bande à part, en étant prévenue plus vite, et en fournissant des correctifs d’Intel que ni les autres distributions ni le noyau officiel n’ont finalement retenus, semble-t-il pour des questions de performance.
Ubuntu a aussi privilégié la stabilité sur la sécurité en revenant sur les correctifs de firmware au moment où l’on s’est aperçu que ceux d’Intel posaient des problèmes de stabilité sur certains de leurs processeurs, et en attendant d’avoir du recul avant de remettre leur version ultérieure. D’autres distributions ne sont pas revenues en arrière (Arch Linux), ou ont remis la version ultérieure des correctifs quasiment immédiatement sans attendre d’avoir du recul dessus. C’est un choix.
Je n’ai pas fait le choix de la sécurité comme priorité absolue (d’ailleurs, j’utilise Xubuntu sur une de mes machines...), mais si je le faisais, je n’utiliserais ni Debian, ni une de ses dérivées.
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone