Chaque système a besoin de processus en cours d’exécution pour atteindre son objectif principal. Mais parfois, les choses tournent mal et un processus peut se bloquer. En fonction de la configuration du système, un vidage de noyau est créé. En d’autres termes, un instantané de la mémoire du processus bloqué est stocké. Le terme noyau se réfère en fait à l’ancienne mémoire à noyau magnétique des anciens systèmes. Bien que ce type de mémoire ne soit plus utilisé, nous utilisons toujours ce terme sur les systèmes Linux. Assez pour l’histoire, configurons notre système Linux pour gérer correctement les décharges de base.
Table des Matières
Linux et core dumps
La plupart des systèmes Linux ont des core dumps activés par défaut. Comme toujours, il y a un compromis à faire ici. D’une part, nous voulons collecter des données pour améliorer la stabilité et le dépannage. D’autre part, nous voulons limiter les données de débogage et éviter les fuites de données sensibles.
La première option est bonne pour les machines où des programmes instables doivent être étudiés, comme le poste de travail d’un développeur. La deuxième option est mieux adaptée aux systèmes de production stockant ou traitant des données sensibles.
Désactiver les vidages de cœur
Il est logique de désactiver tous les vidages de cœur sous Linux par défaut pour tous vos systèmes. En effet, les fichiers occupent de l’espace disque et peuvent contenir des données sensibles. Donc, si vous n’avez pas besoin des vidages de base à des fins de dépannage, leur désactivation est une option sûre.
Option 1: ulimit via le fichier de configuration
Pour désactiver les vidages de base, nous devons définir une valeur ulimit. Cela se fait via le fichier /etc/security/limits.fichier conf et définit certaines restrictions spécifiques au shell.
Bon à savoir, il y a des limites douces et dures. Une limite stricte est quelque chose qui ne peut jamais être annulée, tandis qu’une limite souple peut ne s’appliquer qu’à des utilisateurs spécifiques. Si nous voulons nous assurer qu’aucun processus ne peut créer un vidage de noyau, nous pouvons les mettre tous les deux à zéro. Bien qu’il puisse ressembler à un booléen (0 = False, 1 = True), il indique en fait la taille autorisée.
* noyau souple 0
* noyau dur 0
Le signe astérisque signifie qu’il s’applique à tous les utilisateurs. La deuxième colonne indique si nous voulons utiliser une limite dure ou douce, suivie des colonnes indiquant le paramètre et la valeur.
Option 2: configurer ulimit via profile
Les valeurs pour ulimit peuvent également être définies via /etc/profile ou un fichier personnalisé dans le /etc/profile.d répertoire. Ce dernier est préféré lorsqu’il est disponible. Par exemple en créant un fichier nommé /etc/profile.d/disable-coredumps.sh.
echo « ulimit-c 0 > /dev/null 2>&1 » > / etc / profil.d / désactiver les pompes à noyau.sh
Cette commande ajoute le paramètre à un nouveau fichier et définit à la fois la limite logicielle et la limite matérielle à zéro. Chaque utilisateur obtient cette valeur lors de la connexion.
Outre les paramètres ulimit, il existe également des paramètres du noyau à prendre en compte. Donc, choisir l’une des options est la première étape.
Option 3: désactiver via systemd
Lorsque vous utilisez systemd et le service systemd-coredump, modifiez le coredump.fichier conf. Ce fichier se trouve très probablement dans /usr/lib/sysctl.d/50 – culot.conf. Comme systemd a un ensemble de fichiers, assurez-vous de vérifier les autres comme:
Définissez le paramètre de stockage sur « aucun ». Configurez ensuite ProcessSizeMax pour limiter la taille maximale à zéro.
Stockage = aucun
ProcessSizeMax=0
En règle générale, il suffit de recharger simplement la configuration systemd.
systemctl daemon-reload
Si cela crée toujours un vidage de cœur, redémarrez le système.
Désactivez les processus setuid vidant leur mémoire
Les processus avec des autorisations élevées (ou le bit setuid) peuvent toujours effectuer un vidage de base, selon vos autres paramètres. Comme ces processus ont généralement plus d’accès, ils peuvent contenir des segments de données plus sensibles en mémoire. Il est donc temps de changer cela aussi. Le comportement peut être modifié avec une clé sysctl, ou directement via le système de fichiers /proc. Pour les paramètres permanents, la commande et la configuration sysctl sont généralement utilisées. Un paramètre est appelé » clé « , auquel une valeur associée lui est attachée (également appelée paire clé-valeur).
Pour désactiver le programme avec le bit setuid à vider, définissez le fs.suid_dumpable à zéro.
echo "fs.suid_dumpable=0" >> /etc/sysctl.conf
Rechargez la configuration sysctl avec l’indicateur -p pour activer les modifications que vous avez apportées.
sysctl -p
Vous voulez juste tester sans faire de changements permanents? Utilisez sysctl -w suivi de la clé =valeur.
Astuce: En utilisant sysctl, vous pouvez régler votre système et c’est un bon moyen de durcir le noyau Linux.
Activer les vidages de cœur
La principale raison d’autoriser les vidages de cœur est à des fins de dépannage. La mémoire vidée du processus peut être utilisée pour les problèmes de débogage, généralement par des développeurs plus expérimentés. Un fournisseur de logiciels peut demander d’activer les vidages de base. Habituellement, pour découvrir pourquoi un processus s’est écrasé en premier lieu et trouver la routine connexe qui l’a causé.
L’activation des vidages de base sous Linux est similaire à leur désactivation, sauf que quelques détails spécifiques doivent être configurés. Par exemple, si vous n’avez besoin que de détails d’un programme particulier, vous pouvez utiliser des limites souples. Ceci est fait en utilisant -S qui indique qu’il s’agit d’une limite douce. Le -c indique la taille d’une décharge de noyau.
ulimit -S -c 0
L’étape suivante consiste à autoriser uniquement « mon programme à dépanner » à créer un vidage de base.
ulimit -S -c unlimited my-program-to-troubleshoot
Si vous souhaitez autoriser tous les processus à utiliser des vidages de base, utilisez la ligne ci-dessus sans le programme ou définissez une limite système dans /etc/security/limits.conf
* soft core unlimited
Dépannez les binaires setuid
Les binaires qui ont un jeu de bits setuid peuvent s’exécuter avec les autorisations root. Ce type particulier d’accès doit être restreint autant que possible. Aussi pour la création de décharges de base, il doit être configuré correctement. Ceci est fait avec le sysctl fs.clé suid_dumpable.
- 0 – désactivé
- 1 – activé
- 2 – activé avec des restrictions
Donc, si vous souhaitez dépanner des programmes avec un jeu de bits setuid, vous pouvez modifier temporairement le fs.suid_dumpable à 1 ou 2. Il est préférable de le définir sur 2 car cela rend les vidages de base lisibles uniquement pour l’utilisateur root. C’est une bonne alternative pour les systèmes avec des données sensibles. Définir l’option sur 1 est mieux adapté aux systèmes de développement personnel.
Créer des fichiers de vidage normaux
L’un des grands mystères des systèmes Linux est l’emplacement des vidages de base. Linux a une astuce en place pour capturer les décharges de base. Ce réglage particulier se fait via le noyau sysctl.paramètre core_pattern ou /proc/sys/kernel/core_pattern. La plupart des systèmes auront un canal (|) dans ce paramètre pour indiquer qu’un programme doit prendre en charge les données générées. Donc, si vous vous demandez où va votre décharge principale, suivez le tuyau!
Les décharges de base sur les systèmes Ubuntu vont généralement être ajoutées. Pour les systèmes basés sur Red Hat, il peut être redirigé vers l’outil de rapport automatique des bogues (ABRT).
Vous pouvez modifier temporairement ce paramètre, en faisant écho à « core » dans ce fichier, ou utiliser l’utilitaire sysctl.
sysctl -w kernel.core_pattern=core
Une note importante est que ce changement pourrait ne pas suffire. Cela dépend aussi de votre fs.paramètre suid_dumpable. Un avertissement sera enregistré dans votre enregistreur de noyau si tel est le cas.
Sep 06 15:51:18 noyau durcissant: core_pattern dangereux utilisé avec suid_dumpable=2. Un gestionnaire de tuyaux ou un chemin de décharge de carottes entièrement qualifié est requis.
Si nécessaire, définissez votre core_pattern sur un chemin complet, éventuellement avec des variables définissant qui l’exécutait, le PID, etc.
noyau sysctl-w.core_pattern = /var/crash/noyau.%u.%e.%p
Dans cet exemple, nos vidages contiendront l’ID utilisateur, le nom du programme et l’id du processus.
Vidages de base Systemd
Lorsque vous utilisez une distribution Linux moderne, systemd est très probablement activé. Vous devrez peut-être remplacer les paramètres via /etc/sysctl.d/50 – culot.conf et définissez comment et où vous souhaitez stocker vos décharges de base.
En utilisant systemd-coredump
Votre noyau.core_pattern peut être défini pour utiliser l’utilitaire systemd-coredump. Le chemin par défaut où les vidages de base sont stockés est alors dans /var/lib/systemd/coredump.
Tester votre configuration
La plupart des autres tutoriels vous donnent simplement les paramètres à configurer. Mais comment sauriez-vous que les choses fonctionnent comme prévu? Vous devrez le tester!
Créer un vidage de base
Option 1: Créer un programme instable
Créons un programme simple. Son objectif principal est de planter lors de l’exécution, puis de créer éventuellement un vidage de noyau. Installez gcc sur votre système et créez un plantage de fichier.c dans votre répertoire personnel.
int main(){ return 1/0;}
Ce programme démarrera la fonction principale et renverra une valeur entière (nombre). Cependant, il divise 1 par zéro, ce qui n’est pas autorisé et va planter. L’étape suivante consiste à compiler notre programme little buggy.
Notre petit programme instable
Même le compilateur montre que notre programme contient un problème sérieux et affiche un avertissement à ce sujet. Maintenant, nous allons l’exécuter et voir si c’est le cas.
Un joli crash !
À partir de cette seule ligne, nous pouvons réellement apprendre quelques choses. Tout d’abord qu’il a quitté avec une exception, se référant spécifiquement aux points flottants. Il s’agit d’un format de nombre décimal pour les programmes, il peut donc indiquer que quelque chose s’est passé en faisant des calculs. Une autre conclusion est que le noyau est sous-évalué en raison de l’ajout (de noyau sous-évalué) à la fin. Si les vidages de base étaient désactivés, cela n’apparaîtrait pas.
Génial, donc avec ce crash ci-dessus, nous avons maintenant un fichier vidé, non? Pas exactement. Selon votre distribution Linux, les choses pourraient ne pas être aussi simples qu’il y paraît. Chaque distribution traite différemment des vidages de base et des paramètres par défaut. La plupart des distributions Linux les plus récentes utilisent également systemd maintenant et les règles ont également été légèrement modifiées avec cela. Selon votre configuration, vous devrez peut-être rechercher vos décharges principales. Voici donc quelques conseils pour vous assurer que tout est configuré correctement.
Option 2: tuer un processus en cours
Au lieu d’utiliser un programme de test, vous pouvez également mettre fin à un processus existant. Ceci est fait en utilisant le SIGSEGV, qui est l’abréviation de violation de segmentation et également connu sous le nom de défaut de segmentation.
kill -s SIGSEGV PID
Si vous remplacez PID par « $$ », le programme actuel (très probablement votre shell) se bloquera. Tout pour la science, non?
Option 3 : utilisation de gdb
Si l’outil de débogage du développeur gdb est installé, attachez-le à un processus de votre choix à l’aide de son ID de processus (PID).
gdb -p 1234
Ensuite, à l’invite gdb, générez le vidage du noyau en appelant l’instruction generate-core-file. Après avoir utilisé cette commande, elle devrait vous renvoyer la sortie.
Noyau du fichier corefile enregistré.1234
Vérifiez les paramètres ulimit
Les paramètres ulimit définissent ce qui peut arriver lorsqu’un programme se bloque. Il est donc prudent de vérifier d’abord cela, à la fois pour root et pour un utilisateur normal non privilégié.
Vérifier la limite dure pour les décharges de noyau:
ulimit -H -c
Vérifiez également la limite douce:
ulimit -S -c
Vérifiez le modèle de base
Utilisez le système de fichiers /proc pour collecter la valeur et la modifier temporairement pendant le test. Si vous préférez utiliser sysctl, interrogez le noyau.clé core_pattern.
cat /proc/sys/kernel/core_pattern
Cela pourrait montrer quelque chose comme ça:
|/usr/share/apport/apport %p %s %c %P
Dans ce cas, un plantage sera acheminé vers l’utilitaire apport. Cela signifie donc que les plantages vont être analysés par Apport. Normalement, les plantages se trouvent dans /var/crash, mais peuvent également se trouver dans /var/spool ou /var/lib/systemd/coredump sur d’autres distributions Linux.
Vérifiez le journal (systemd)
Dans notre cas journalctl montre notre crash, donc c’est un début.
Après avoir vérifié tous ces paramètres, vous devriez pouvoir créer un bon vidage de noyau.
Conclusion
Les décharges de base peuvent être utiles pour le dépannage, mais constituent un désastre en cas de fuite de données sensibles. Désactivez les vidages de base lorsque cela est possible et n’activez-les qu’en cas de besoin. Dans ce cas, vérifiez si les fichiers sont stockés en toute sécurité, afin que les utilisateurs normaux ne puissent pas voir les données. Et indépendamment du choix que vous avez fait, testez toujours si votre configuration fonctionne exactement comme vous l’attendez.