What is the correct way to allow attaching gdb to a running process?

Enrico1989 · 2022-08-13 07:10:38

My understanding is that without sudo I'm not allowed to attach gdb to a non-child (e.g. already running) process because of security reasons (something along the lines of https://wiki.ubuntu.com/SecurityTeam/Ro … rotection).

This however is annoying when I want to debug a running process.

At this page I've found that a solution is to

echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

and then, after I'm done,

echo 1 | sudo tee /proc/sys/kernel/yama/ptrace_scope

to revert the change. I've tested this and it works. (I've not understood why this is not a permanent solution. Is the changed value restored after some timeout or after reboot or what?)

At the same link an alternative suggestion is to permanently change a line in /etc/sysctl.d/10-ptrace.conf from

kernel.yama.ptrace_scope = 1

to

kernel.yama.ptrace_scope = 0

I couldn't test this because I don't have a file named /etc/sysctl.d/10-ptrace.conf; actually /etc/sysctl.d/ is an empty directory for me.

On our Capabilities wiki I found that another solution is to attach gdb to a process, rather than simply by

gdb -p <pid>

via

sudo -E capsh --caps="cap_setpcap,cap_setuid,cap_setgid+ep cap_sys_ptrace+eip" --keep=1 --user="$USER" --addamb="cap_sys_ptrace" --shell=/usr/bin/gdb -- -p <pid>

I've verified this works.

Now the point is that the first and third solution, which I've verified as working, both require me to run something via sudo everytime I want to attach, so this complicates the use. As regards the second solution, if I was able to make it work (I guess I'd just need to now the path to 10-ptrace.conf in Arch), it would be indiscriminate on what program is allowed that capability.

So my question is, as per the title, what is the right way to allow myself to attach gdb to a PID? And why?

Last edited by Enrico1989 (2022-08-13 09:54:36)

dogknowsnx · 2022-08-13 07:37:03

Enrico1989 wrote:

I guess I'd just need to now the path to 10-ptrace.conf in Arch

You simply create the file yourself - that's what "dot-d" directories are for...

Enrico1989 · 2022-08-13 08:42:19

Ok, but still

it would be indiscriminate on what program is allowed that capability

No?

I mean, is that the right way?

seth · 2022-08-13 10:44:29

There's no "right" way.
Disabling yama/ptrace_scope will allow any process to ptrace other processes.
Raising the caps on gdb will allow anyone to use gdb to ptrace other processes (also this will get nuked w/ the next update, if you use setcap)

The most insecure way is to unconditionally remove yama/ptrace_scope through /etc/sysctl.d/10-ptrace.conf as that will open the floodgates for everyone.
Other than thatyou can either permanently or temporarily raise the caps on gdb or temporarily remove the yama/ptrace_scope

Only temporarily raise the caps on gdb is the most secure approach, whether permanently raising them or temporarily removing yama/ptrace_scope is more insecure is like standing somewhere on the road blindfolded and moving left or right - both can end you in front of a truck and it's impossible to pre-determine which is more likely.

Realistically, if gdb attach often, raising the caps on the binary is probably the better way - otherwise a short term removal of yama/ptrace_scope is less likely to result in an attack than a permanently open gdb (if you haven't pissed off some 3-letter agency that's currently monitoring your system real-time…)
(If you gdb attach for a living, it's not a short term removal anymore)

Enrico1989 · 2022-08-13 12:24:04

There's something I don't understand yet.

I can act on

gdb only
every program

and I can do so

permanently
temporarily

so there would be 4 ways to combine the above.

My understanding is that

changing /proc/sys/kernel/yama/ptrace_scope manually means acting on every program, but the change is only temporary (why is it only temporary? Is this change reverted on reboot?)
changing (or creating) /etc/sysctl.d/10-ptrace.conf means acting on every program, but the change is permanent (does it mean this is not reverted in any circumstance?)

but then?

The command

sudo -E capsh --caps="cap_setpcap,cap_setuid,cap_setgid+ep cap_sys_ptrace+eip" --keep=1 --user="$USER" --addamb="cap_sys_ptrace" --shell=/usr/bin/gdb -- -p <pid>

seems to be a temporary way of raising the caps on gdb. Literally I do this for attaching gdb once to one PID.

What do you mean by permanently raising the caps on gdb?

seth · 2022-08-13 18:54:30

why is it only temporary? Is this change reverted on reboot?

Yes, but also when you just reset it afterwards w/ "echo 1 | sudo tee /proc/sys/kernel/yama/ptrace_scope"

10-ptrace.conf means acting on every program, but the change is permanent (does it mean this is not reverted in any circumstance?)

You can likewise reset it, it just equals running "echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope" on every boot automatically.

What do you mean by permanently raising the caps on gdb?

man setcap

It's also in the wiki you linked.

joaot · 2024-08-21 15:58:56

sudo setcap cap_sys_ptrace=eip /usr/bin/gdb

is likely the answer to the original query "what is the right way to allow myself to attach gdb to a PID?" that you're looking for. Works as of today. Read the rest of the thread for the "why".

Arch Linux

#1 2022-08-13 07:10:38

What is the correct way to allow attaching gdb to a running process?

#2 2022-08-13 07:37:03

Re: What is the correct way to allow attaching gdb to a running process?

#3 2022-08-13 08:42:19

Re: What is the correct way to allow attaching gdb to a running process?

#4 2022-08-13 10:44:29

Re: What is the correct way to allow attaching gdb to a running process?

#5 2022-08-13 12:24:04

Re: What is the correct way to allow attaching gdb to a running process?

#6 2022-08-13 18:54:30

Re: What is the correct way to allow attaching gdb to a running process?

#7 2024-08-21 15:58:56

Re: What is the correct way to allow attaching gdb to a running process?

Board footer