[Bug server/30453] gdbserver cannot set breakpoints when /proc/pid/mem is not writable

["pedro at palves dot net" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30453

--- Comment #4 from Pedro Alves <pedro at palves dot net> ---
So your kernel hardening has a bug, which you should fix.

Restricting /proc/pid/mem by default might make sense, but not if the thread
that opens the mem file has ptrace permissions over pid.  If the caller is
already ptracing the target process, then it already has access to all the
inferior's memory.  If you want to block ptrace, then that's a different story.

The kernel already has some connection between ptrace permissions and
/proc/pid/mem.  From man proc:

~~~
       /proc/[pid]/mem
              This file can be used to access the pages of a process's memory
through open(2), read(2), and lseek(2).

              Permission to access this file is governed by a ptrace access
mode PTRACE_MODE_ATTACH_FSCREDS check; see ptrace(2).
~~~

You would extend these checks to check whether the calling thread is a ptracer
of the target pid.  Somewhere in fs/proc/base.c:mem_open and friends.  

Actually, Mike's patch already touched exactly that code back then, doing:

 static ssize_t mem_write(struct file *file, const char __user *buf,
                         size_t count, loff_t *ppos)
 {
+#ifdef CONFIG_SECURITY_CHROMIUMOS_READONLY_PROC_SELF_MEM
+       return -EACCES;
+#else
        return mem_rw(file, (char __user*)buf, count, ppos, 1);
+#endif
 }

so you'd just tweak that -EACESS code to first check whether the caller is a
ptracer of the target, and if so, continue on with the mem_rw path.

In Mike's commit log, you've already admited "Getting this merged upstream
seems unlikely", so this is all local changes to you.

-- 
You are receiving this mail because:
You are on the CC list for the bug.