Debug a setuid binary as non-root

Question

I have a CentOS 7 system. I need to attach my GDB to an already running application, but get the (apparently usual) "ptrace: Operation not permitted." error. Running GDB as root prevents the error, but I would rather not resort to this.

I have researched the issue and did find multiple answers stating that you simply needed to either modify /proc/sys/kernel/yama/ptrace_scope with the value 0 or go for a permanent fix regarding the file /etc/sysctl.d/10-ptrace.conf...

Well, apparently everyone assumes you are using YAMA, which seems not to be the case over here. Yet, I have not been able to find what to do in my situation yet.

I have checked, and it seems my system is configured with SELinux, but it is not enabled. My Kernel boot settings include the flag selinux=0, and the command

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

reads

# 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

Finally, getsebool deny_ptrace returns getsebool: SELinux is disabled.

From my understanding, no LSM is currently enabled on my system, yet I still get the ptrace limitations. I am here clueless about where to look next, or what even causes the ptrace limitation at this point.

Is the fact that the setuid bit is set on my executable file potentially causing this issue? Both gdb and the application are themselves launched using the same user, without any super-user privileges specifically added to either. ps -eouid,comm also shows both as having the same uid. Only the application is run using the setuid bit, and the file belongs to root:root.

Answer 1

Debugging a program that has privileges effectively gives the debugger the same privileges. Therefore, regardless of any security settings, debugging a program that has extra privileges must require the debugger to have at least all of these privileges. For example, a setuid program has the privileges of both the original and the target user, so the debugger has to have the privileges of both users. In practice, this means that the debugger must be root. On Linux, it's enough to give the debugger the capability CAP_SYS_PTRACE (this doesn't reduce the debugger's effective privileges, but it means that the debugger won't e.g. accidentally overwrite files of another user).

It's generally more convenient to debug the program while running without extra privileges. Adjust file permissions, paths and so on accordingly. If you need to debug the program in real conditions with the privileges then the debugger needs to run as root. On Linux, this can be root in a user namespace that contains the two users involved.