Why/how is GDB allowed to attach to a process and read/write to attached process' address space?

Question

The fact that GDB can attach to any process without having su rights is terrifying to me. For example, what prevents me from writing a malware/virus(/whatever the correct term is) that uses same system calls with GDB to attach to any processes, send interrupts, change instructions on the fly, add breakpoints to branching instructions to alter ZF etc.?

You can clearly do lots of harmful things with this ability. For example, I'm doing some minor hacks using some GDB Python scripts and I can't see what's preventing me from writing some seriously dangerous/malicious stuff.

So I have some number of questions related with how is this possible and how is this safe:

(I'm assuming that it's the operating system who allows a process to somehow send interrupts to some other one, and access to it's address space and alter the memory. Please correct me if I'm wrong)

1) What makes this safe? What prevents me from writing a program that alters behaviours of every single process running in a system?

2) What system calls are involved? How does operating system give me access to address space of some other process, while not taking my own address space from me. (e.g. GDB has it's own address space, but it can also read attached process' address space)

3) In my user-level program, is it possible to detect this kind of "attaching"? Like, can I print a message and terminate if another process is attached to my program? How do I detect this?

(I'm using "attaching" as "starting writing/reading my address space")

Thanks.

Answer 1

2) The system call is ptrace. That call has lots of functionality, including "copy a section of the tracee's memory into a local buffer in my address space" and the reverse "copy my buffer to the tracee's memory". These are quite similar to windows' ReadProcessMemory and WriteProcessMemory. The tracing program needs to use these to access memory in the traced program.

1) The fact that you can't, really, attach to processes that aren't yours, unless you have root access, or (on Linux), the CAP_SYS_PTRACE capability. In some newer Linuxes, you don't even have rights to ptrace all of your own processes, depending on the yama settings and whether the traced process is a (grand)child of the tracing process. The wikipedia page explains this in more detail.

3) No, you can't. At least not reliably. Whichever trick you'd want to use could be intercepted by the tracer. Also, you generally don't want to do this, since you need ptrace to debug your program, and whoever has rights to ptrace you could screw you in various other ways as well. However, a process can't have more than one tracer attached at a time, so you could have a master process that spawns and ptraces the worker, so noone else can attach to the worker to trace it. Of course, the worker would still need a way to check if it's parent is alive (compare getppid() with 1 for example) and that the tracer isn't intercepting your getppid() calls and patching them to return the old parent id.