덤프에 대한 FAQ

이 문서에서는 .NET에서 덤프를 수집하는 방법에 대한 일반적인 질문에 답변합니다.

Linux에서 덤프 수집이 실패하는 이유는 무엇인가요?

덤프 수집을 구현하기 위해 .NET 프로세스는 createdump라는 자식 프로세스를 생성합니다. 이 자식 프로세스는 Linux API ptrace() 를 사용하고 /proc 파일 시스템에서 읽어 덤프 파일에 기록된 스레드 및 메모리 데이터에 액세스합니다. 많은 Linux 배포판의 기본 보안 설정에서 API 사용을 허용하지만, 때로는 덜 일반적인 보안 구성이 액세스를 거부합니다. 다음과 같이 덤프되는 애플리케이션의 콘솔에 기록된 createdump 프로세스의 출력을 볼 수 있습니다.

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

액세스를 거부할 수 있는 한 가지 이유는 보안 샌드박스가 seccomp BPF 필터를 사용하여 호출을 가로채는 경우입니다. Open Container Initiative 기술을 사용하여 컨테이너에서 실행되는 애플리케이션의 경우 프로필에서 seccomp 호출을 ptrace허용해야 합니다. 예를 들어 Docker 내부적으로 컨테이너된 컨테이너를 컨테이너 런타임으로 사용합니다. 초기화할 때 컨테이너 호스트에 커널 버전이 4.8보다 높거나 CAP_SYS_PTRACE 컨테이너에 기능이 지정된 경우에만 허용하는 ptrace 기본 seccomp 프로필을 지정합니다.

호출이 가로채지 않으면 커널은 다양한 기본 제공 액세스 검사를 수행합니다. ptrace()에 대한 문서에는 끝부분에 "Ptrace 액세스 모드 검사"라는 자세한 설명이 포함되어 있습니다. /proc 파일 시스템에 액세스하는 경우 동일한 ptrace 액세스 모드 검사의 변형도 사용합니다. 다음은 수행된 보안 검사 및 액세스가 거부될 수 있는 위치에 대한 요약 요약입니다.

• 호출 프로세스에 대상 프로세스와 동일한 사용자 ID가 있어야 하거나 호출 프로세스에 CAP_SYS_PTRACE 있어야 합니다. 둘 다 true가 아니면 액세스가 거부됩니다. .NET 런타임은 createdump를 시작할 때 사용자 계정을 변경하는 데 아무 작업도 수행하지 않으므로 사용자 ID가 일치해야 하며 이 단계가 성공해야 합니다.
• createdump에 CAP_SYS_PTRACE 없는 경우(기본적으로 그렇지 않음) 덤프되는 대상 프로세스를 "덤프 가능"으로 표시해야 합니다. 기본적으로 Linux의 대부분의 프로세스는 덤프 가능하지만 PR_SET_DUMPABLE 옵션을 사용하여 prctl() 을 호출하여 이 설정을 변경할 수 있습니다. setcap 도구를 사용하여 프로세스에 기능을 추가하면 프로세스가 덤프 가능하지 않을 수도 있습니다. 덤프 가능 설정에 대한 자세한 설명과 사용 안 함의 원인은 Linux 설명서를 참조하세요.
• 사용하도록 설정된 모든 Linux 보안 모듈 (LSM)이 열거되고 각 모듈은 액세스를 승인해야 합니다. 아쉽게도 LSM이 액세스를 거부하는 경우 어떤 것이 책임지는지 알 수 있는 균일한 Linux 보고 메커니즘이 없습니다. 대신 시스템에서 사용할 수 있는 항목을 확인한 다음 개별적으로 조사해야 합니다. 다음을 실행 cat /sys/kernel/security/lsm하여 활성 상태인 LSM을 확인할 수 있습니다. 모든 LSM이 책임질 수 있지만 Yama, SELinux 및 AppArmor 는 종종 관련 항목입니다.

AppArmor 및 SELinux에는 풍부한 구성 및 보고 메커니즘이 있으므로 작업하는 방법을 배워야 하는 경우 각 프로젝트의 설명서를 보는 것이 가장 좋습니다. Yama에는 다음을 실행하여 표시할 수 있는 단일 구성 설정만 있습니다.

cat /proc/sys/kernel/yama/ptrace_scope

이 명령은 현재 Yama ptrace 보안 정책을 나타내는 숫자를 출력합니다.

• 0: 클래식 ptrace 권한.
• 1: 제한된 ptrace.
• 2: 관리자 전용 연결.
• 3: 연결이 없습니다.

Yama는 정책 0 및 1에 따라 만든 덤프에 대한 액세스 권한을 부여해야 하지만 정책 2와 3에 따라 액세스가 거부될 것으로 예상합니다. 정책 3은 항상 액세스를 거부하며, createdump에는 일반적으로 CAP_SYS_PTRACE 기능이 없으므로 정책 2가 기본적으로 작동하지 않습니다.

dotnet-dump 또는 크래시 프로세스가 관리자 권한으로 실행되는 경우에만 Linux에서 덤프를 가져오는 이유는 무엇인가요?

일부 Linux 기반 시스템은 기능을 CAP_SYS_PTRACE 위해 덤프를 수집하는 모든 프로세스가 필요한 보안 정책으로 구성됩니다. 일반적으로 프로세스에는 이 기능이 없지만 관리자 권한으로 실행하는 것이 이를 사용하도록 설정하는 한 가지 방법입니다. Linux 보안 정책이 덤프 수집에 미치는 영향에 대한 자세한 설명은 'Linux에서 덤프 컬렉션이 실패하는 이유는 무엇인가요?'를 참조하세요.

컨테이너 내에서 실행할 때 덤프를 수집할 수 없는 이유는 무엇인가요?

Open Container Initiative 기술로 실행되는 애플리케이션의 경우 프로필에서 seccompptrace()에 대한 호출을 허용해야 합니다. 예를 들어 Docker 내부적으로 컨테이너된 컨테이너를 컨테이너 런타임으로 사용합니다. 런타임을 초기화할 때 컨테이너 호스트에 커널 버전이 4.8보다 높거나 CAP_SYS_PTRACE 기능이 지정된 경우에만 허용하는 ptrace 기본 seccomp 프로필을 지정합니다.

Linux 보안 정책이 덤프 수집에 미치는 영향에 대한 자세한 설명은 'Linux에서 덤프 수집이 실패하는 이유는 무엇인가요?'라는 질문을 참조하세요.

macOS에서 덤프를 수집할 수 없는 이유는 무엇인가요?

macOS에서 사용 ptrace 하려면 대상 프로세스의 호스트에 적절한 자격이 있어야 합니다. 필요한 최소 자격에 대한 자세한 내용은 기본 자격을 참조하세요.

덤프를 활용하여 .NET 애플리케이션에서 문제를 진단하는 방법에 대해 자세히 알아볼 수 있는 위치는 어디인가요?

몇 가지 추가 리소스는 다음과 같습니다.

• Linux 덤프 디버그
• .NET 앱에서 교착 상태 디버그

"호환되는 프레임워크 버전을 찾을 수 없음"을 어떻게 해결할 수 있나요?

Linux에서 환경 변수는 DOTNET_ROOT 설정 시 올바른 폴더를 가리킵니다. 다른 .NET 버전을 dotnet-dump 가리키면 항상 이 오류가 발생합니다. 환경 변수가 DOTNET_ROOT 설정되지 않으면 다른 오류가 발생합니다("이 애플리케이션을 실행하려면 .NET을 설치해야 함").

이 문서에서는 .NET에서 덤프를 수집하는 방법에 대한 일반적인 질문에 답변합니다.

덤프 수집을 구현하기 위해 .NET 프로세스는 createdump라는 자식 프로세스를 생성합니다. 이 자식 프로세스는 Linux API ptrace() 를 사용하고 /proc 파일 시스템에서 읽어 덤프 파일에 기록된 스레드 및 메모리 데이터에 액세스합니다. 많은 Linux 배포판의 기본 보안 설정에서 API 사용을 허용하지만, 때로는 덜 일반적인 보안 구성이 액세스를 거부합니다. 다음과 같이 덤프되는 애플리케이션의 콘솔에 기록된 createdump 프로세스의 출력을 볼 수 있습니다.

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

액세스를 거부할 수 있는 한 가지 이유는 보안 샌드박스가 seccomp BPF 필터를 사용하여 호출을 가로채는 경우입니다. Open Container Initiative 기술을 사용하여 컨테이너에서 실행되는 애플리케이션의 경우 프로필에서 seccomp 호출을 ptrace허용해야 합니다. 예를 들어 Docker 내부적으로 컨테이너된 컨테이너를 컨테이너 런타임으로 사용합니다. 초기화할 때 컨테이너 호스트에 커널 버전이 4.8보다 높거나 CAP_SYS_PTRACE 컨테이너에 기능이 지정된 경우에만 허용하는 ptrace 기본 seccomp 프로필을 지정합니다.

호출이 가로채지 않으면 커널은 다양한 기본 제공 액세스 검사를 수행합니다. ptrace()에 대한 문서에는 끝부분에 "Ptrace 액세스 모드 검사"라는 자세한 설명이 포함되어 있습니다. /proc 파일 시스템에 액세스하는 경우 동일한 ptrace 액세스 모드 검사의 변형도 사용합니다. 다음은 수행된 보안 검사 및 액세스가 거부될 수 있는 위치에 대한 요약 요약입니다.

• 호출 프로세스에 대상 프로세스와 동일한 사용자 ID가 있어야 하거나 호출 프로세스에 CAP_SYS_PTRACE 있어야 합니다. 둘 다 true가 아니면 액세스가 거부됩니다. .NET 런타임은 createdump를 시작할 때 사용자 계정을 변경하는 데 아무 작업도 수행하지 않으므로 사용자 ID가 일치해야 하며 이 단계가 성공해야 합니다.
• createdump에 CAP_SYS_PTRACE 없는 경우(기본적으로 그렇지 않음) 덤프되는 대상 프로세스를 "덤프 가능"으로 표시해야 합니다. 기본적으로 Linux의 대부분의 프로세스는 덤프 가능하지만 PR_SET_DUMPABLE 옵션을 사용하여 prctl() 을 호출하여 이 설정을 변경할 수 있습니다. setcap 도구를 사용하여 프로세스에 기능을 추가하면 프로세스가 덤프 가능하지 않을 수도 있습니다. 덤프 가능 설정에 대한 자세한 설명과 사용 안 함의 원인은 Linux 설명서를 참조하세요.
• 사용하도록 설정된 모든 Linux 보안 모듈 (LSM)이 열거되고 각 모듈은 액세스를 승인해야 합니다. 아쉽게도 LSM이 액세스를 거부하는 경우 어떤 것이 책임지는지 알 수 있는 균일한 Linux 보고 메커니즘이 없습니다. 대신 시스템에서 사용할 수 있는 항목을 확인한 다음 개별적으로 조사해야 합니다. 다음을 실행 cat /sys/kernel/security/lsm하여 활성 상태인 LSM을 확인할 수 있습니다. 모든 LSM이 책임질 수 있지만 Yama, SELinux 및 AppArmor 는 종종 관련 항목입니다.

AppArmor 및 SELinux에는 풍부한 구성 및 보고 메커니즘이 있으므로 작업하는 방법을 배워야 하는 경우 각 프로젝트의 설명서를 보는 것이 가장 좋습니다. Yama에는 다음을 실행하여 표시할 수 있는 단일 구성 설정만 있습니다.

cat /proc/sys/kernel/yama/ptrace_scope

이 명령은 현재 Yama ptrace 보안 정책을 나타내는 숫자를 출력합니다.

• 0: 클래식 ptrace 권한.
• 1: 제한된 ptrace.
• 2: 관리자 전용 연결.
• 3: 연결이 없습니다.

Yama는 정책 0 및 1에 따라 만든 덤프에 대한 액세스 권한을 부여해야 하지만 정책 2와 3에 따라 액세스가 거부될 것으로 예상합니다. 정책 3은 항상 액세스를 거부하며, createdump에는 일반적으로 CAP_SYS_PTRACE 기능이 없으므로 정책 2가 기본적으로 작동하지 않습니다.

일부 Linux 기반 시스템은 기능을 CAP_SYS_PTRACE 위해 덤프를 수집하는 모든 프로세스가 필요한 보안 정책으로 구성됩니다. 일반적으로 프로세스에는 이 기능이 없지만 관리자 권한으로 실행하는 것이 이를 사용하도록 설정하는 한 가지 방법입니다. Linux 보안 정책이 덤프 수집에 미치는 영향에 대한 자세한 설명은 'Linux에서 덤프 컬렉션이 실패하는 이유는 무엇인가요?'를 참조하세요.

Open Container Initiative 기술로 실행되는 애플리케이션의 경우 프로필에서 seccompptrace()에 대한 호출을 허용해야 합니다. 예를 들어 Docker 내부적으로 컨테이너된 컨테이너를 컨테이너 런타임으로 사용합니다. 런타임을 초기화할 때 컨테이너 호스트에 커널 버전이 4.8보다 높거나 CAP_SYS_PTRACE 기능이 지정된 경우에만 허용하는 ptrace 기본 seccomp 프로필을 지정합니다.

Linux 보안 정책이 덤프 수집에 미치는 영향에 대한 자세한 설명은 'Linux에서 덤프 수집이 실패하는 이유는 무엇인가요?'라는 질문을 참조하세요.

macOS에서 사용 ptrace 하려면 대상 프로세스의 호스트에 적절한 자격이 있어야 합니다. 필요한 최소 자격에 대한 자세한 내용은 기본 자격을 참조하세요.

몇 가지 추가 리소스는 다음과 같습니다.

• Linux 덤프 디버그
• .NET 앱에서 교착 상태 디버그

Linux에서 환경 변수는 DOTNET_ROOT 설정 시 올바른 폴더를 가리킵니다. 다른 .NET 버전을 dotnet-dump 가리키면 항상 이 오류가 발생합니다. 환경 변수가 DOTNET_ROOT 설정되지 않으면 다른 오류가 발생합니다("이 애플리케이션을 실행하려면 .NET을 설치해야 함").