FAQ sur les vidages

Cet article répond aux questions fréquemment posées sur la collecte de vidages dans .NET.

Pourquoi la collecte de vidage échoue-t-elle sur Linux ?

Pour implémenter la collecte de vidage, les processus .NET génèrent un processus enfant appelé createdump. Ce processus enfant utilise l’API Linux ptrace() et lit également à partir du système de fichiers /proc pour accéder aux données de thread et de mémoire écrites dans le fichier de vidage. Bien que l’utilisation de l’API soit autorisée par les paramètres de sécurité par défaut sur de nombreuses distributions Linux, une configuration de sécurité moins courante refuse parfois l’accès. Vous pouvez voir la sortie du processus créé écrit sur la console de l’application en cours de vidage, par exemple :

[createdump] The process or container does not have permissions or access: open(/proc/1234/mem) FAILED Permission denied (13)

Une raison pour laquelle l’accès peut être refusé est si un bac à sable de sécurité intercepte l’appel à l’aide d’un filtre BPF seccomp. Pour les applications s’exécutant dans un conteneur à l’aide de la technologie Open Container Initiative, le seccomp profil doit autoriser les appels à ptrace. Par exemple, Docker utilise le conteneur sous le capot comme runtime de conteneur. Lors de l’initialisation, il spécifie un profil seccomp par défaut qui autorise ptrace uniquement si l’hôte de conteneur a une version du noyau supérieure à 4.8 ou si la CAP_SYS_PTRACE fonctionnalité a été spécifiée sur le conteneur.

Si les appels ne sont pas interceptés, le noyau effectue diverses vérifications d’accès intégrées. Les documents pour ptrace() incluent une description détaillée près de la fin, intitulée « Vérification du mode d’accès Ptrace », qui décrit la façon dont ces opérations sont effectuées. L’accès au système de fichiers /proc utilise également une variante de la même vérification du mode d’accès ptrace. Voici un résumé abrégé des vérifications de sécurité effectuées et des emplacements où l’accès peut être refusé :

• Soit le processus appelant doit avoir le même ID utilisateur que le processus cible, ou le processus appelant doit avoir CAP_SYS_PTRACE. Si aucun de ces éléments n’est vrai, l’accès est refusé. Étant donné que le runtime .NET ne fait rien pour modifier le compte d’utilisateur lors du lancement de createdump, les ID utilisateur doivent correspondre et cette étape doit réussir.
• Si createdump n’a pas de CAP_SYS_PTRACE (ce n’est pas le cas par défaut), le processus cible en cours de vidage doit être marqué comme « vidable ». Par défaut, la plupart des processus sur Linux sont vidables, mais vous pouvez modifier ce paramètre en appelant prctl() avec l’option PR_SET_DUMPABLE. Si vous ajoutez des fonctionnalités à un processus à l’aide de l’outil setcap, cela peut également entraîner l’arrêt du vidage d’un processus. Pour obtenir une description plus détaillée du paramètre vidable et de ce qui l’entraîne sa désactivation, consultez la documentation Linux.
• Tous les modules de sécurité Linux activés sont énumérés et chacun d’eux doit approuver l’accès. Malheureusement, si un LSM refuse l’accès, il n’existe aucun mécanisme de création de rapports Linux uniforme pour savoir qui est responsable. Au lieu de cela, vous devez déterminer ceux qui sont activés sur votre système, puis examiner chaque élément individuellement. Vous pouvez déterminer les machines virtuelles LSM actives en exécutant : cat /sys/kernel/security/lsm. Bien que n’importe quel LSM puisse être responsable, Yama, SELinux et AppArmor sont fréquemment les éléments pertinents.

AppArmor et SELinux disposent à la fois de mécanismes de configuration et de création de rapports riches. Par conséquent, si vous avez besoin d’apprendre à les utiliser, il est préférable d’afficher la documentation de chaque projet. Yama n’a qu’un seul paramètre de configuration, qui peut être affiché en exécutant :

cat /proc/sys/kernel/yama/ptrace_scope

Cette commande génère un nombre indiquant la stratégie de sécurité Yama ptrace actuelle :

• 0 : Autorisations ptrace classiques.
• 1 : ptrace restreint.
• 2 : Attachement administrateur uniquement.
• 3 : Aucune attachement.

Yama doit accorder l’accès pour createdump sous les stratégies 0 et 1, mais s’attendre à ce que l’accès soit refusé dans les stratégies 2 et 3. La stratégie 3 refuse toujours l’accès et la stratégie 2 ne fonctionne pas par défaut, car l’énumération créée n’a normalement pas la fonctionnalité CAP_SYS_PTRACE.

Pourquoi puis-je uniquement obtenir des vidages sur Linux si dotnet-dump ou mon processus de blocage est en cours d’exécution avec élévation de privilèges ?

Certains systèmes Linux sont configurés avec des stratégies de sécurité qui nécessitent tout processus de collecte d’un vidage pour avoir la fonctionnalité CAP_SYS_PTRACE. Normalement, les processus n’ont pas cette fonctionnalité, mais l’exécution avec élévation de privilèges est un moyen de l’activer. Pour obtenir une description plus complète de la façon dont les stratégies de sécurité Linux ont un impact sur la collecte de vidages, consultez « Pourquoi la collecte de vidage échoue-t-elle sur Linux ? ».

Pourquoi ne puis-je pas collecter des vidages lors de l’exécution à l’intérieur d’un conteneur ?

Pour les applications s’exécutant sous n’importe quelle technologie Open Container Initiative, le seccomp profil doit autoriser les appels à ptrace(). Par exemple, Docker utilise le conteneur sous le capot comme runtime de conteneur. Lors de l’initialisation du runtime, il spécifie un profil seccomp par défaut qui autorise ptrace uniquement si l’hôte de conteneur a une version du noyau supérieure à 4.8 ou si la CAP_SYS_PTRACE fonctionnalité a été spécifiée.

Pour obtenir une description plus complète de la façon dont les stratégies de sécurité Linux affectent la collecte de vidages, consultez la question « Pourquoi la collecte de vidage échoue-t-elle sur Linux ? ».

Pourquoi ne puis-je pas collecter des vidages sur macOS ?

Sur macOS, l’utilisation de ptrace l’hôte du processus cible doit être correctement autorisée. Pour plus d’informations sur les droits minimum requis, consultez Les droits par défaut.

Où puis-je en savoir plus sur la façon dont je peux tirer parti des vidages pour diagnostiquer les problèmes dans mon application .NET ?

Voici quelques ressources supplémentaires :

• Déboguer des vidages Linux
• Déboguer un interblocage dans une application .NET

Comment puis-je résoudre « Il n’était pas possible de trouver une version de framework compatible »

Sur Linux, la DOTNET_ROOT variable d’environnement doit pointer vers le dossier approprié lors de la définition. Lorsqu’elle pointe vers une autre version de .NET, dotnet-dump génère toujours cette erreur. Lorsque la DOTNET_ROOT variable d’environnement n’est pas définie, une autre erreur est générée (« Vous devez installer .NET pour exécuter cette application »).

Cet article répond aux questions fréquemment posées sur la collecte de vidages dans .NET.

Pour implémenter la collecte de vidage, les processus .NET génèrent un processus enfant appelé createdump. Ce processus enfant utilise l’API Linux ptrace() et lit également à partir du système de fichiers /proc pour accéder aux données de thread et de mémoire écrites dans le fichier de vidage. Bien que l’utilisation de l’API soit autorisée par les paramètres de sécurité par défaut sur de nombreuses distributions Linux, une configuration de sécurité moins courante refuse parfois l’accès. Vous pouvez voir la sortie du processus créé écrit sur la console de l’application en cours de vidage, par exemple :

[createdump] The process or container does not have permissions or access: open(/proc/1234/mem) FAILED Permission denied (13)

Une raison pour laquelle l’accès peut être refusé est si un bac à sable de sécurité intercepte l’appel à l’aide d’un filtre BPF seccomp. Pour les applications s’exécutant dans un conteneur à l’aide de la technologie Open Container Initiative, le seccomp profil doit autoriser les appels à ptrace. Par exemple, Docker utilise le conteneur sous le capot comme runtime de conteneur. Lors de l’initialisation, il spécifie un profil seccomp par défaut qui autorise ptrace uniquement si l’hôte de conteneur a une version du noyau supérieure à 4.8 ou si la CAP_SYS_PTRACE fonctionnalité a été spécifiée sur le conteneur.

Si les appels ne sont pas interceptés, le noyau effectue diverses vérifications d’accès intégrées. Les documents pour ptrace() incluent une description détaillée près de la fin, intitulée « Vérification du mode d’accès Ptrace », qui décrit la façon dont ces opérations sont effectuées. L’accès au système de fichiers /proc utilise également une variante de la même vérification du mode d’accès ptrace. Voici un résumé abrégé des vérifications de sécurité effectuées et des emplacements où l’accès peut être refusé :

• Soit le processus appelant doit avoir le même ID utilisateur que le processus cible, ou le processus appelant doit avoir CAP_SYS_PTRACE. Si aucun de ces éléments n’est vrai, l’accès est refusé. Étant donné que le runtime .NET ne fait rien pour modifier le compte d’utilisateur lors du lancement de createdump, les ID utilisateur doivent correspondre et cette étape doit réussir.
• Si createdump n’a pas de CAP_SYS_PTRACE (ce n’est pas le cas par défaut), le processus cible en cours de vidage doit être marqué comme « vidable ». Par défaut, la plupart des processus sur Linux sont vidables, mais vous pouvez modifier ce paramètre en appelant prctl() avec l’option PR_SET_DUMPABLE. Si vous ajoutez des fonctionnalités à un processus à l’aide de l’outil setcap, cela peut également entraîner l’arrêt du vidage d’un processus. Pour obtenir une description plus détaillée du paramètre vidable et de ce qui l’entraîne sa désactivation, consultez la documentation Linux.
• Tous les modules de sécurité Linux activés sont énumérés et chacun d’eux doit approuver l’accès. Malheureusement, si un LSM refuse l’accès, il n’existe aucun mécanisme de création de rapports Linux uniforme pour savoir qui est responsable. Au lieu de cela, vous devez déterminer ceux qui sont activés sur votre système, puis examiner chaque élément individuellement. Vous pouvez déterminer les machines virtuelles LSM actives en exécutant : cat /sys/kernel/security/lsm. Bien que n’importe quel LSM puisse être responsable, Yama, SELinux et AppArmor sont fréquemment les éléments pertinents.

AppArmor et SELinux disposent à la fois de mécanismes de configuration et de création de rapports riches. Par conséquent, si vous avez besoin d’apprendre à les utiliser, il est préférable d’afficher la documentation de chaque projet. Yama n’a qu’un seul paramètre de configuration, qui peut être affiché en exécutant :

cat /proc/sys/kernel/yama/ptrace_scope

Cette commande génère un nombre indiquant la stratégie de sécurité Yama ptrace actuelle :

• 0 : Autorisations ptrace classiques.
• 1 : ptrace restreint.
• 2 : Attachement administrateur uniquement.
• 3 : Aucune attachement.

Yama doit accorder l’accès pour createdump sous les stratégies 0 et 1, mais s’attendre à ce que l’accès soit refusé dans les stratégies 2 et 3. La stratégie 3 refuse toujours l’accès et la stratégie 2 ne fonctionne pas par défaut, car l’énumération créée n’a normalement pas la fonctionnalité CAP_SYS_PTRACE.

Certains systèmes Linux sont configurés avec des stratégies de sécurité qui nécessitent tout processus de collecte d’un vidage pour avoir la fonctionnalité CAP_SYS_PTRACE. Normalement, les processus n’ont pas cette fonctionnalité, mais l’exécution avec élévation de privilèges est un moyen de l’activer. Pour obtenir une description plus complète de la façon dont les stratégies de sécurité Linux ont un impact sur la collecte de vidages, consultez « Pourquoi la collecte de vidage échoue-t-elle sur Linux ? ».

Pour les applications s’exécutant sous n’importe quelle technologie Open Container Initiative, le seccomp profil doit autoriser les appels à ptrace(). Par exemple, Docker utilise le conteneur sous le capot comme runtime de conteneur. Lors de l’initialisation du runtime, il spécifie un profil seccomp par défaut qui autorise ptrace uniquement si l’hôte de conteneur a une version du noyau supérieure à 4.8 ou si la CAP_SYS_PTRACE fonctionnalité a été spécifiée.

Pour obtenir une description plus complète de la façon dont les stratégies de sécurité Linux affectent la collecte de vidages, consultez la question « Pourquoi la collecte de vidage échoue-t-elle sur Linux ? ».

Sur macOS, l’utilisation de ptrace l’hôte du processus cible doit être correctement autorisée. Pour plus d’informations sur les droits minimum requis, consultez Les droits par défaut.

Voici quelques ressources supplémentaires :

• Déboguer des vidages Linux
• Déboguer un interblocage dans une application .NET

Sur Linux, la DOTNET_ROOT variable d’environnement doit pointer vers le dossier approprié lors de la définition. Lorsqu’elle pointe vers une autre version de .NET, dotnet-dump génère toujours cette erreur. Lorsque la DOTNET_ROOT variable d’environnement n’est pas définie, une autre erreur est générée (« Vous devez installer .NET pour exécuter cette application »).