Domande frequenti per i dump

Questo articolo risponde alle domande frequenti sulla raccolta di dump in .NET.

Perché la raccolta di dump ha esito negativo in Linux?

Per implementare la raccolta di dump, i processi .NET generano un processo figlio denominato createdump. Questo processo figlio usa l'API Linux ptrace() e legge anche dal file system /proc per accedere ai dati di thread e memoria scritti nel file dump. Anche se l'utilizzo dell'API è consentito dalle impostazioni di sicurezza predefinite in molte distribuzioni Linux, a volte una configurazione di sicurezza meno comune negherà l'accesso. È possibile che venga visualizzato l'output del processo createdump scritto nella console dell'applicazione di cui viene eseguito il dump, ad esempio:

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

Un motivo per cui l'accesso può essere negato è se una sandbox di sicurezza intercetta la chiamata usando un filtro BPF seccomp. Per le applicazioni in esecuzione in un contenitore tramite la tecnologia Open Container Initiative, il seccomp profilo deve consentire le chiamate a ptrace. Ad esempio, Docker usa contenitori in un contenitore sotto forma di runtime del contenitore. Durante l'inizializzazione, specifica un profilo seccomp predefinito che consente ptrace solo se l'host del contenitore ha una versione del kernel successiva alla 4.8 o se la CAP_SYS_PTRACE funzionalità è stata specificata nel contenitore.

Se le chiamate non vengono intercettate, il kernel esegue un'ampia gamma di controlli di accesso predefiniti. I documenti per ptrace() includono una descrizione dettagliata vicino alla fine, intitolata "Controllo della modalità di accesso Ptrace", che descrive come vengono eseguite queste operazioni. L'accesso al file system /proc usa anche una variante della stessa modalità di accesso ptrace. Di seguito è riportato un riepilogo abbreviato dei controlli di sicurezza eseguiti e le posizioni in cui l'accesso potrebbe essere negato:

• Il processo chiamante deve avere lo stesso ID utente del processo di destinazione oppure il processo chiamante deve avere CAP_SYS_PTRACE. Se nessuno di questi valori è true, l'accesso viene negato. Poiché il runtime .NET non esegue alcuna operazione per modificare l'account utente all'avvio di createdump, gli ID utente devono corrispondere e questo passaggio dovrebbe avere esito positivo.
• Se createdump non ha CAP_SYS_PTRACE (non per impostazione predefinita), il processo di destinazione sottoposto a dump deve essere contrassegnato come "dumpable". Per impostazione predefinita, la maggior parte dei processi in Linux è dumpable, ma è possibile modificare questa impostazione chiamando prctl() con l'opzione PR_SET_DUMPABLE. Se si aggiungono funzionalità a un processo usando lo strumento setcap, questo può anche causare l'arresto del dump di un processo. Per una descrizione più dettagliata dell'impostazione dumpable e delle cause della disabilitabilità, vedere la documentazione di Linux.
• Tutti i moduli di sicurezza Linux abilitati (LSM) vengono enumerati e ognuno di essi deve approvare l'accesso. Sfortunatamente, se un LSM nega l'accesso, non esiste un meccanismo uniforme di creazione di report di Linux per sapere quale sia responsabile. È invece necessario determinare quali sono abilitate nel sistema e quindi esaminarne ognuna singolarmente. È possibile determinare quali LSM sono attivi eseguendo: cat /sys/kernel/security/lsm. Anche se qualsiasi LSM potrebbe essere responsabile, Yama, SELinux e AppArmor sono spesso quelli rilevanti.

AppArmor e SELinux hanno entrambi meccanismi avanzati di configurazione e creazione di report, quindi se è necessario imparare a usarli, è consigliabile visualizzare la documentazione di ogni progetto. Yama ha una sola impostazione di configurazione, che può essere visualizzata eseguendo:

cat /proc/sys/kernel/yama/ptrace_scope

Questo comando restituisce un numero che indica i criteri di sicurezza yama ptrace correnti:

• 0: autorizzazioni ptrace classiche.
• 1: ptrace limitato.
• 2: Collegamento solo amministratore.
• 3: Nessun collegamento.

Yama dovrebbe concedere l'accesso per createdump in base ai criteri 0 e 1, ma si prevede che l'accesso venga negato ai criteri 2 e 3. Il criterio 3 nega sempre l'accesso e il criterio 2 non funziona per impostazione predefinita perché createdump normalmente non ha la funzionalità CAP_SYS_PTRACE.

Perché si ottengono dump solo in Linux se dotnet-dump o il processo di arresto anomalo del sistema è in esecuzione con privilegi elevati?

Alcuni sistemi basati su Linux sono configurati con criteri di sicurezza che richiedono qualsiasi processo che raccoglie un dump per avere la funzionalità CAP_SYS_PTRACE. In genere i processi non dispongono di questa funzionalità, ma l'esecuzione con privilegi elevati è un modo per abilitarla. Per una descrizione più completa del modo in cui i criteri di sicurezza Linux influisce sulla raccolta di dump, vedere "Perché la raccolta di dump ha esito negativo in Linux?".

Perché non è possibile raccogliere dump durante l'esecuzione all'interno di un contenitore?

Per le applicazioni in esecuzione in qualsiasi tecnologia Open Container Initiative, il seccomp profilo deve consentire le chiamate a ptrace(). Ad esempio, Docker usa contenitori in un contenitore sotto forma di runtime del contenitore. Durante l'inizializzazione del runtime, specifica un profilo seccomp predefinito che consente ptrace solo se l'host del contenitore ha una versione del kernel superiore alla 4.8 o se è stata specificata la CAP_SYS_PTRACE funzionalità.

Per una descrizione più completa del modo in cui i criteri di sicurezza Linux influisce sulla raccolta di dump, vedere la domanda "Perché la raccolta di dump ha esito negativo in Linux?".

Perché non è possibile raccogliere dump in macOS?

In macOS l'uso di ptrace richiede che l'host del processo di destinazione sia autorizzato correttamente. Per informazioni sui diritti minimi obbligatori, vedere Entitlement predefiniti.

Dove è possibile ottenere altre informazioni su come è possibile sfruttare i dump per diagnosticare i problemi nell'applicazione .NET?

Ecco alcune risorse aggiuntive:

• Eseguire il debug di dump di Linux
• Eseguire il debug di un deadlock in un'app .NET

Come è possibile risolvere "Non è stato possibile trovare alcuna versione del framework compatibile"

In Linux, la DOTNET_ROOT variabile di ambiente deve puntare alla cartella corretta quando impostata. Quando punta a un'altra versione di .NET, dotnet-dump genera sempre questo errore. Quando la DOTNET_ROOT variabile di ambiente non è impostata, viene generato un errore diverso ("È necessario installare .NET per eseguire l'applicazione").

Questo articolo risponde alle domande frequenti sulla raccolta di dump in .NET.

Per implementare la raccolta di dump, i processi .NET generano un processo figlio denominato createdump. Questo processo figlio usa l'API Linux ptrace() e legge anche dal file system /proc per accedere ai dati di thread e memoria scritti nel file dump. Anche se l'utilizzo dell'API è consentito dalle impostazioni di sicurezza predefinite in molte distribuzioni Linux, a volte una configurazione di sicurezza meno comune negherà l'accesso. È possibile che venga visualizzato l'output del processo createdump scritto nella console dell'applicazione di cui viene eseguito il dump, ad esempio:

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

Un motivo per cui l'accesso può essere negato è se una sandbox di sicurezza intercetta la chiamata usando un filtro BPF seccomp. Per le applicazioni in esecuzione in un contenitore tramite la tecnologia Open Container Initiative, il seccomp profilo deve consentire le chiamate a ptrace. Ad esempio, Docker usa contenitori in un contenitore sotto forma di runtime del contenitore. Durante l'inizializzazione, specifica un profilo seccomp predefinito che consente ptrace solo se l'host del contenitore ha una versione del kernel successiva alla 4.8 o se la CAP_SYS_PTRACE funzionalità è stata specificata nel contenitore.

Se le chiamate non vengono intercettate, il kernel esegue un'ampia gamma di controlli di accesso predefiniti. I documenti per ptrace() includono una descrizione dettagliata vicino alla fine, intitolata "Controllo della modalità di accesso Ptrace", che descrive come vengono eseguite queste operazioni. L'accesso al file system /proc usa anche una variante della stessa modalità di accesso ptrace. Di seguito è riportato un riepilogo abbreviato dei controlli di sicurezza eseguiti e le posizioni in cui l'accesso potrebbe essere negato:

• Il processo chiamante deve avere lo stesso ID utente del processo di destinazione oppure il processo chiamante deve avere CAP_SYS_PTRACE. Se nessuno di questi valori è true, l'accesso viene negato. Poiché il runtime .NET non esegue alcuna operazione per modificare l'account utente all'avvio di createdump, gli ID utente devono corrispondere e questo passaggio dovrebbe avere esito positivo.
• Se createdump non ha CAP_SYS_PTRACE (non per impostazione predefinita), il processo di destinazione sottoposto a dump deve essere contrassegnato come "dumpable". Per impostazione predefinita, la maggior parte dei processi in Linux è dumpable, ma è possibile modificare questa impostazione chiamando prctl() con l'opzione PR_SET_DUMPABLE. Se si aggiungono funzionalità a un processo usando lo strumento setcap, questo può anche causare l'arresto del dump di un processo. Per una descrizione più dettagliata dell'impostazione dumpable e delle cause della disabilitabilità, vedere la documentazione di Linux.
• Tutti i moduli di sicurezza Linux abilitati (LSM) vengono enumerati e ognuno di essi deve approvare l'accesso. Sfortunatamente, se un LSM nega l'accesso, non esiste un meccanismo uniforme di creazione di report di Linux per sapere quale sia responsabile. È invece necessario determinare quali sono abilitate nel sistema e quindi esaminarne ognuna singolarmente. È possibile determinare quali LSM sono attivi eseguendo: cat /sys/kernel/security/lsm. Anche se qualsiasi LSM potrebbe essere responsabile, Yama, SELinux e AppArmor sono spesso quelli rilevanti.

AppArmor e SELinux hanno entrambi meccanismi avanzati di configurazione e creazione di report, quindi se è necessario imparare a usarli, è consigliabile visualizzare la documentazione di ogni progetto. Yama ha una sola impostazione di configurazione, che può essere visualizzata eseguendo:

cat /proc/sys/kernel/yama/ptrace_scope

Questo comando restituisce un numero che indica i criteri di sicurezza yama ptrace correnti:

• 0: autorizzazioni ptrace classiche.
• 1: ptrace limitato.
• 2: Collegamento solo amministratore.
• 3: Nessun collegamento.

Yama dovrebbe concedere l'accesso per createdump in base ai criteri 0 e 1, ma si prevede che l'accesso venga negato ai criteri 2 e 3. Il criterio 3 nega sempre l'accesso e il criterio 2 non funziona per impostazione predefinita perché createdump normalmente non ha la funzionalità CAP_SYS_PTRACE.

Alcuni sistemi basati su Linux sono configurati con criteri di sicurezza che richiedono qualsiasi processo che raccoglie un dump per avere la funzionalità CAP_SYS_PTRACE. In genere i processi non dispongono di questa funzionalità, ma l'esecuzione con privilegi elevati è un modo per abilitarla. Per una descrizione più completa del modo in cui i criteri di sicurezza Linux influisce sulla raccolta di dump, vedere "Perché la raccolta di dump ha esito negativo in Linux?".

Per le applicazioni in esecuzione in qualsiasi tecnologia Open Container Initiative, il seccomp profilo deve consentire le chiamate a ptrace(). Ad esempio, Docker usa contenitori in un contenitore sotto forma di runtime del contenitore. Durante l'inizializzazione del runtime, specifica un profilo seccomp predefinito che consente ptrace solo se l'host del contenitore ha una versione del kernel superiore alla 4.8 o se è stata specificata la CAP_SYS_PTRACE funzionalità.

Per una descrizione più completa del modo in cui i criteri di sicurezza Linux influisce sulla raccolta di dump, vedere la domanda "Perché la raccolta di dump ha esito negativo in Linux?".

In macOS l'uso di ptrace richiede che l'host del processo di destinazione sia autorizzato correttamente. Per informazioni sui diritti minimi obbligatori, vedere Entitlement predefiniti.

Ecco alcune risorse aggiuntive:

• Eseguire il debug di dump di Linux
• Eseguire il debug di un deadlock in un'app .NET

In Linux, la DOTNET_ROOT variabile di ambiente deve puntare alla cartella corretta quando impostata. Quando punta a un'altra versione di .NET, dotnet-dump genera sempre questo errore. Quando la DOTNET_ROOT variabile di ambiente non è impostata, viene generato un errore diverso ("È necessario installare .NET per eseguire l'applicazione").