问题
Why do I need to run as root (not r00t_)?
// main()
scan.scanProcessOffset(10838, 0x7f8c14000000); // proper pid and offset
void MemoryMapper::scanProcessOffset(unsigned int procId, unsigned long long offset)
{
long attach = ptrace(PTRACE_ATTACH, procId, NULL, NULL);
cout << attach << endl << errno << endl;
long memory = ptrace(PTRACE_PEEKDATA, procId, offset);
if (memory == -1 && errno == 3)
{
cout << errno << endl;
errno = 0;
}
cout << memory;
}
As you can see the process I'm hooking into is owned by r00t_
r00t_@:/proc/10838$ ls -l
lrwxrwxrwx 1 r00t r00t_ 0 2012-04-15 08:21 exe -> /usr/bin/gedit
-rw------- 1 r00t r00t_ 0 2012-04-15 09:04 mem
Output not running as root:
r00t_@:~/memedit$ ./a.out
-1
1
3
-1
Output as root:
r00t_@:~/memedit$ sudo ./a.out
0
0
140239607693344
why cant I attach when I am the owner of the process I'm trying to attach to?
回答1:
While some applications use prctl()
to specifically disallow PTRACE_ATTACH
(e.g. ssh-agent), a more general solution implemented in Yama is to only allow ptrace
directly from a parent to a child process (i.e. direct gdb
and strace
still work), or as the root user (i.e. gdb BIN PID
, and strace -p PID
still work as root).
In the event of a local app compromise, the attacker is then not able to attach to other processes and inspect their memory and running state.
This behaviour is controlled via the /proc/sys/kernel/yama/ptrace_scope
sysctl value. The default is "1" to block non-child ptrace
calls. A value of "0" restores the more permissive behaviour, which may be more appropriate for development systems and/or servers with only administrative accounts. Using sudo
can also temporarily grant ptrace
permissions via the CAP_SYS_PTRACE
capability, though this method allows the ptrace
of any process.
来源:https://stackoverflow.com/questions/10163678/ptrace-ptrace-attach-failure-linux-permissions-of-user-owned-process