☰

루트가 아닌 사용자로 setuid 바이너리 디버깅

tag-icon • tag-icon setuid gdb
루트가 아닌 사용자로 setuid 바이너리 디버깅

CentOS 7 시스템이 있습니다. 이미 실행 중인 애플리케이션에 GDB를 연결해야 하는데 (분명히 일반적인) "ptrace: Operation not allowed" 메시지가 나타납니다. 실수. GDB를 루트로 실행하면 이 오류를 방지할 수 있지만 이에 의존하고 싶지는 않습니다.

이 질문을 조사한 결과 /proc/sys/kernel/yama/ptrace_scope값을 수정 0하거나 파일을 영구적으로 복구하면 된다는 여러 답변을 찾았습니다 /etc/sysctl.d/10-ptrace.conf.

글쎄, 분명히 모든 사람들은 당신이 YAMA를 사용하고 있다고 생각하지만 여기서는 그렇지 않은 것 같습니다. 그러나 나는 내 상황에 대해 무엇을 해야할지 찾지 못했습니다.

확인해 보니 내 시스템이 SELinux로 구성된 것 같지만 활성화되지 않았습니다. 내 커널 부팅 설정에는 플래그 selinux=0와 명령이 포함되어 있습니다.

grep CONFIG_SECURITY /boot/config-`uname -r`

읽다

# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
# CONFIG_SECURITY_PATH is not set
CONFIG_SECURITY_SECURELEVEL=y
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_YAMA is not set

마침내 getsebool deny_ptrace돌아왔다 getsebool: SELinux is disabled.

내가 이해한 바에 따르면 LSM은 현재 내 시스템에서 활성화되어 있지 않지만 여전히 ptrace에 의해 제한됩니다. 여기서 다음에 어디로 가야할지, 심지어 이 시점에서 ptrace가 제한되는 원인이 무엇인지도 모르겠습니다.

내 실행 파일에 설정된 setuid 비트가 이 문제를 일으킬 가능성이 있습니까? gdb와 애플리케이션 자체는 특별히 추가된 수퍼유저 권한 없이 동일한 사용자를 사용하여 시작됩니다. ps -eouid,comm또한 둘 다 동일한 uid를 가지고 있음을 보여줍니다. 응용 프로그램만 setuid 비트로 실행되며 파일은 root:root에 속합니다.

답변1

권한이 있는 프로그램을 디버깅하면 실제로 디버거에 동일한 권한이 제공됩니다. 따라서 보안 설정에 관계없이 추가 권한이 있는 프로그램을 디버깅하려면 디버거에 최소한 해당 권한이 모두 있어야 합니다. 예를 들어 setuid 프로그램에는 원래 사용자와 대상 사용자 모두에 대한 권한이 있으므로 디버거는 두 사용자 모두에 대한 권한을 가지고 있어야 합니다. 실제로 이는 디버거가 루트여야 함을 의미합니다. Linux에서는 디버거에 이 기능을 제공하는 것으로 충분합니다. CAP_SYS_PTRACE이는 디버거의 유효 권한을 감소시키지 않지만 디버거가 실수로 다른 사용자의 파일을 덮어쓸 수 없음을 의미합니다.

추가 권한 없이 프로그램이 실행되는 동안 디버깅하는 것이 더 편리한 경우가 많습니다. 이에 따라 파일 권한, 경로 등을 조정하십시오. 권한이 있는 디버거를 실제로 사용해야 하는 경우 디버거를 루트로 실행해야 합니다. Linux에서는 관련된 두 사용자가 모두 포함된 사용자 네임스페이스의 루트일 수 있습니다.

관련 정보