Bonjour,
Après avoir expérimenté grsecurity sur une machine virtuelle, je me pose la question de sa mise en place sur une machine en production.
Lorsqu'on regarde le changelog de la version stable, on note des modifications plusieurs fois par semaine.
En attendant de mettre en place Ksplice, comment cela peut-il être compatible avec un serveur en production qui doit rester accessible en continue pour ses utilisateurs ?
Pour ceux qui ont choisi d'appliquer ce patch, comment gérez-vous ces multiples changements ?
La solution la plus évidente que j'imagine serait d'installer la dernière version de grsecurity au moment de la mise en place du serveur, pour, ensuite, effectuer des mises à jour en fonction des améliorations apportées.
Cela vous parait-il correct ou bien avez-vous mis en place d'autres politiques ?
Merci
# Politique : encore faut-il en avoir une
Posté par Kerro . Évalué à 3.
Tu parles de politique, mais beaucoup d'admin n'en ont pas :-)
En ce qui me concerne, je fais le tour des machines Linux et BSD que j'administre une fois tous les 2 à 4 mois pour appliquer les mises à jours. Sauf de rares machines 'on ne touche pas'.
Si un truc urgent arrive (c'est rare) je le fais tout de suite.
Si c'est un changement venant de moi (une réorganisation de fichiers de configuration par exemple, ou une modification de paramétrage) c'est fait avec mon système de gestion de configurations, donc immédiat.
[^] # Re: Politique : encore faut-il en avoir une
Posté par Anonyme . Évalué à 1.
mais dans le cas particulier de grsecurity, il ne s'agit pas uniquement d'ajouts de features mais de corrections de régressions, de correction de bugs etc… Contrairement au nom qui lui est donnée, ce n'est pas une version stable, c'est une rolling release.
Je trouve ça très perturbant pour l'élément pivot d'un serveur: sans grsecurity, si on suit les version maintenues à long terme, les mises à jours sont relativement espacées, mais si on ajoute le patch grsecurity, il faudrait faire une mise à jour, donc un reboot, par semaine !
grsecurity est censé apporté plus de sécurité à mon serveur, mais j'ai l'impression que cela se fait au détriment de son uptime. Ca peut tout à fait se gérer en définissant des phases de maintenance pendant les zones creuses d'activité et en avertissant les utilisateurs, ou en doublant les serveurs et en profiter pour faire du load balancing, mais ça reste des solutions de contournement d'un problème causé en amont par le mode de fonctionnement de grsecurity.
Ma question avait pour but de rechercher des solutions plus directes qui auraient pu avoir été mises en place par les équipes de grsecurity ou bien par certains de leurs gros utilisateurs.
Mais ca n'a pas l'air de passionner les foules, donc je devrais plutôt chercher mes réponses sur le chan de grsecurity.
[^] # Re: Politique : encore faut-il en avoir une
Posté par NeoX . Évalué à 4.
je crois qu'il faut surtout se poser la question de ce qui est important pour toi.
si c'est l'uptime pour eviter le derangement des utilisateurs et des process, sur des machines dans ton reseau à toi, non exposées directement à internet, tu peux tres bien faire une mise à jour de temps en temps.
si c'est la sécurité à tout prix car tu ne peux pas te permettre d'avoir un risque sur un vecteur d'attaque car tes données sont hautement critiques, etc.
Alors il vaut mieux avoir un plan de mise à jour regulier, quitte à avoir un uptime de 6 jours car tu fais tes updates tous les dimanches.
[^] # Re: Politique : encore faut-il en avoir une
Posté par Anonyme . Évalué à 1. Dernière modification le 11 décembre 2012 à 16:08.
En direct de grsecurity@OFTC, je viens d'avoir la confirmation qu'il n'y a pas de réelle politique de mise à jour pour la version stable.
Les évolutions de cette version consistent en des corrections de bugs et des backports de diverses fonctionnalités, mais le choix de répercuter telle ou telle commit sur le noyau d'une machine en production reste une décision spécifique du sysadmin.
Donc les méthodes de contournement que je proposais plus haut semble à ce jour les seules solutions pour éviter les interruptions du service qui pourrait sensiblement augmenter si on choisissait d'appliquer et de maintenir ce patch sur son noyau
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.