Allow introspection to already attached ptracer in __ptrace_may_access
RFC PATCH 1/1 Allow introspection to already attached ptracer in __ptrace_may_access
Hello,
I ran across the following problem recently but I'm not entirely sure whether this should be fixed in ptrace or in Yama. I'm working on a ptrace-based monitor that forks off its own tracee during startup. The monitor attaches to the tracee and then lets the tracee perform an execve call. This is much like running a program in gdb.
My monitor is multi-threaded and uses one monitor thread for every tracee thread so whenever the tracee forks/vforks/clones, I fire up a new monitor thread, detach the old monitor thread from the tracee thread and attach the new monitor thread to the tracee thread.
I have recently stumbled upon several applications in which the main process A forks off process B and then immediately exits. Under normal circumstances the following would happen:
Monitor[0] --- FORKS OFF ---> Monitor[0]'
Monitor[0] --- PTRACE_ATTACH ---> Monitor[0]'
Monitor[0]' --- EXECVE ---> Process A
Process A --- FORKS OFF ---> Process B Monitor[0] --- PTRACE_DETACH ---> Process B Monitor[1] --- PTRACE_ATTACH ---> Process B
With Yama enabled (and the scope set to YAMA_SCOPE_RELATIONAL) however, a few interesting things can (and usually do) happen:
1) If Process A dies before Monitor[1] is attached to Process B, the attach will fail since from Yama's point of view, Process B is no longer a descendant of Monitor[1]. This problem is probably hard to fix but I've circumvented it by delaying the death of Process A until Process B is attached to Monitor[1].
2) More interestingly though, even if Process B does get attached to Monitor[1], as soon as Process A dies, all process_vm_readv and process_vm_writev calls on Process B start failing. Any other ptrace operations peformed on Process B do succeed.
process_vm_readv|writev use __ptrace_may_access to check whether the operation is permitted, whereas other ptrace operations (with the exception of PTRACE_ATTACH) use ptrace_check_attach.
To fix this problem, __ptrace_may_access should be forced to return 0 if the calling process is already attached to the target process.
The question now is whether or not it's the security module's responsibility to check whether a tracee relationship is already in place or if ptrace itself should do it. For the latter case, which seems more logical to me, you could use the patch below.
What do you guys think?
Regards,
Stijn Volckaert
--
kernel/ptrace.c +3 -0
@@ -232,6 +232,9 @@ static int __ptrace_may_access(struct ta/* Don't let security modules deny introspection */ if (same_thread_group (task, current))return 0 ; +/* Don't deny introspection to already attached ptracer */ +if (!ptrace_check_attach (task, true)) +return 0 ;rcu_read_lock (); tcred =__task_cred (task); if (uid_eq(cred->uid, tcred->euid) &&
Oleg Nesterov
maintainerQuoted 4 lines · Stijn Volckaert
The question now is whether or not it's the security module's responsibility to check whether a tracee relationship is already in place or if ptrace itself should do it.
Honestly, I have no idea
kernel/ptrace.c static int __ptrace_may_access(struct ta · line 237
Quoted 9 lines
kernel/ptrace.c +3
-0@@ -232,6 +232,9 @@ static int __ptrace_may_access(struct ta/* Don't let security modules deny introspection */ if (same_thread_group (task, current))return 0 ; +/* Don't deny introspection to already attached ptracer */ +if (!ptrace_check_attach (task, true)) +return 0 ;
Perhaps this makes sense, probably security checks do not make sense if the target is traced.
But in this case I'd suggest to simply
if (ptrace_parent(task) == current) return 0;
Oleg.
Quoted 25 lines · Stijn Volckaert
Hello,
I ran across the following problem recently but I'm not entirely sure whether this should be fixed in ptrace or in Yama. I'm working on a ptrace-based monitor that forks off its own tracee during startup. The monitor attaches to the tracee and then lets the tracee perform an execve call. This is much like running a program in gdb.
My monitor is multi-threaded and uses one monitor thread for every tracee thread so whenever the tracee forks/vforks/clones, I fire up a new monitor thread, detach the old monitor thread from the tracee thread and attach the new monitor thread to the tracee thread.
I have recently stumbled upon several applications in which the main process A forks off process B and then immediately exits. Under normal circumstances the following would happen:
Monitor[0] --- FORKS OFF ---> Monitor[0]'
Monitor[0] ---PTRACE_ATTACH---> Monitor[0]'
Monitor[0]' --- EXECVE ---> Process AProcess A --- FORKS OFF ---> Process B Monitor[0] --- PTRACE_DETACH ---> Process B Monitor[1] --- PTRACE_ATTACH ---> Process B
Quoted 8 lines
With Yama enabled (and the scope set to
YAMA_SCOPE_RELATIONAL) however, a few interesting things can (and usually do) happen:1) If Process A dies before Monitor[1] is attached to Process B, the attach will fail since from Yama's point of view, Process B is no longer a descendant of Monitor[1]. This problem is probably hard to fix but I've circumvented it by delaying the death of Process A until Process B is attached to Monitor[1].
Just to make sure I understand this better, "Monitor" is the initial process, and [0] and [1] are separate threads within that process? I would expect B to have Monitor as its parent after A died, but I must be misunderstanding something.
Regardless, your "interesting thing 1" is certainly a side-effect of YAMA_SCOPE_RELATIONAL trying to do its job.
Quoted 8 lines
2) More interestingly though, even if Process B does get attached to Monitor[1], as soon as Process A dies, all
process_vm_readvandprocess_vm_writevcalls on Process B start failing. Any other ptrace operations peformed on Process B do succeed.process_vm_readv|writev use
__ptrace_may_accessto check whether the operation is permitted, whereas other ptrace operations (with the exception ofPTRACE_ATTACH) useptrace_check_attach.
Right, process_vm_{read,write}v use PTRACE_MODE_ATTACH (which is what Yama interposes via the LSM entry point in __ptrace_may_access).
Quoted 21 lines
To fix this problem,
__ptrace_may_accessshould be forced to return 0 if the calling process is already attached to the target process.The question now is whether or not it's the security module's responsibility to check whether a tracee relationship is already in place or if ptrace itself should do it. For the latter case, which seems more logical to me, you could use the patch below.
What do you guys think?
Regards,
Stijn Volckaert--
Signed-off-by Stijn Volckaert <[email protected]>
kernel/ptrace.c 2014-12-24 14:17:20.617824840 +0100 static int __ptrace_may_access(struct ta · line 240
Quoted 9 lines
kernel/ptrace.c 2014-12-24 14:17:20.617824840 +0100 renamed from kernel/ptrace.c 2014-12-24 13:53:23.055346526 +0100 +3
-0@@ -232,6 +232,9 @@ static int __ptrace_may_access(struct ta /* Don't let security modules deny introspection */ if (same_thread_group(task, current)) return 0; + /* Don't deny introspection to already attached ptracer */ + if (!ptrace_check_attach(task, true)) + return 0; rcu_read_lock(); tcred = __task_cred(task); if (uid_eq(cred->uid, tcred->euid) &&
I'm nervous to add this (or Oleg's suggestion) generally to __ptrace_may_access, as it would mean other LSMs would stop seeing access checks even when attached. It does seem silly to deny ptrace checks when already attached, but it does change the behavior here.
If the other LSM folks don't see a problem here, then it should live in the general case. Otherwise, I'm happy to add this check only in Yama. The existing Yama scopes should ignore attach requests when already attached.
-Kees
Signature · 2 lines
Kees Cook Chrome OS Security
Quoted 80 lines · Kees Cook
Quoted 25 lines · Stijn Volckaert
Hello,
I ran across the following problem recently but I'm not entirely sure whether this should be fixed in ptrace or in Yama. I'm working on a ptrace-based monitor that forks off its own tracee during startup. The monitor attaches to the tracee and then lets the tracee perform an execve call. This is much like running a program in gdb.
My monitor is multi-threaded and uses one monitor thread for every tracee thread so whenever the tracee forks/vforks/clones, I fire up a new monitor thread, detach the old monitor thread from the tracee thread and attach the new monitor thread to the tracee thread.
I have recently stumbled upon several applications in which the main process A forks off process B and then immediately exits. Under normal circumstances the following would happen:
Monitor[0] --- FORKS OFF ---> Monitor[0]'
Monitor[0] ---PTRACE_ATTACH---> Monitor[0]'
Monitor[0]' --- EXECVE ---> Process AProcess A --- FORKS OFF ---> Process B Monitor[0] --- PTRACE_DETACH ---> Process B Monitor[1] --- PTRACE_ATTACH ---> Process BQuoted 8 lines
With Yama enabled (and the scope set to
YAMA_SCOPE_RELATIONAL) however, a few interesting things can (and usually do) happen:1) If Process A dies before Monitor[1] is attached to Process B, the attach will fail since from Yama's point of view, Process B is no longer a descendant of Monitor[1]. This problem is probably hard to fix but I've circumvented it by delaying the death of Process A until Process B is attached to Monitor[1].
Just to make sure I understand this better, "Monitor" is the initial process, and [0] and [1] are separate threads within that process? I would expect B to have Monitor as its parent after A died, but I must be misunderstanding something.
Regardless, your "interesting thing 1" is certainly a side-effect of
YAMA_SCOPE_RELATIONALtrying to do its job.Quoted 8 lines
2) More interestingly though, even if Process B does get attached to Monitor[1], as soon as Process A dies, all
process_vm_readvandprocess_vm_writevcalls on Process B start failing. Any other ptrace operations peformed on Process B do succeed.process_vm_readv|writev use
__ptrace_may_accessto check whether the operation is permitted, whereas other ptrace operations (with the exception ofPTRACE_ATTACH) useptrace_check_attach.Right, process_vm_{read,write}v use
PTRACE_MODE_ATTACH(which is what Yama interposes via the LSM entry point in__ptrace_may_access).Quoted 26 lines
To fix this problem,
__ptrace_may_accessshould be forced to return 0 if the calling process is already attached to the target process.The question now is whether or not it's the security module's responsibility to check whether a tracee relationship is already in place or if ptrace itself should do it. For the latter case, which seems more logical to me, you could use the patch below.
What do you guys think?
Regards,
Stijn Volckaert--
Signed-off-by Stijn Volckaert <[email protected]>kernel/ptrace.c 2014-12-24 14:17:20.617824840 +0100 renamed from kernel/ptrace.c 2014-12-24 13:53:23.055346526 +0100 +3
-0@@ -232,6 +232,9 @@ static int __ptrace_may_access(struct ta /* Don't let security modules deny introspection */ if (same_thread_group(task, current)) return 0; + /* Don't deny introspection to already attached ptracer */ + if (!ptrace_check_attach(task, true)) + return 0;
Quoted 8 lines
kernel/ptrace.c 2014-12-24 14:17:20.617824840 +0100 static int __ptrace_may_access(struct ta · line 240
Quoted 4 lines
kernel/ptrace.c 2014-12-24 14:17:20.617824840 +0100 renamed from kernel/ptrace.c 2014-12-24 13:53:23.055346526 +0100 +0
-0rcu_read_lock(); tcred = __task_cred(task); if (uid_eq(cred->uid, tcred->euid) &&I'm nervous to add this (or Oleg's suggestion) generally to
__ptrace_may_access, as it would mean other LSMs would stop seeing access checks even when attached. It does seem silly to deny ptrace checks when already attached, but it does change the behavior here.
An LSM may chose to do checks on a per access basis. Think in terms of access checks on read/write instead of open. Smack and SELinux do this for some network checks. It is reasonable to think that there is a case where a security attribute (or access rule) could change between the attach and the access.
Example: You allow the access when the developer mode switch is set, but not when it isn't. Someone flips the switch.
Quoted 8 lines
If the other LSM folks don't see a problem here, then it should live in the general case. Otherwise, I'm happy to add this check only in Yama. The existing Yama scopes should ignore attach requests when already attached.
-Kees
Casey Schaufler schreef op 6/01/2015 om 1:17:
Quoted 36 lines · Kees Cook
Quoted 35 lines
Quoted 33 lines · Stijn Volckaert
Hello,
I ran across the following problem recently but I'm not entirely sure whether this should be fixed in ptrace or in Yama. I'm working on a ptrace-based monitor that forks off its own tracee during startup. The monitor attaches to the tracee and then lets the tracee perform an execve call. This is much like running a program in gdb.
My monitor is multi-threaded and uses one monitor thread for every tracee thread so whenever the tracee forks/vforks/clones, I fire up a new monitor thread, detach the old monitor thread from the tracee thread and attach the new monitor thread to the tracee thread.
I have recently stumbled upon several applications in which the main process A forks off process B and then immediately exits. Under normal circumstances the following would happen:
Monitor[0] --- FORKS OFF ---> Monitor[0]'
Monitor[0] ---PTRACE_ATTACH---> Monitor[0]'
Monitor[0]' --- EXECVE ---> Process AProcess A --- FORKS OFF ---> Process B Monitor[0] --- PTRACE_DETACH ---> Process B Monitor[1] --- PTRACE_ATTACH ---> Process BWith Yama enabled (and the scope set to
YAMA_SCOPE_RELATIONAL) however, a few interesting things can (and usually do) happen:1) If Process A dies before Monitor[1] is attached to Process B, the attach will fail since from Yama's point of view, Process B is no longer a descendant of Monitor[1]. This problem is probably hard to fix but I've circumvented it by delaying the death of Process A until Process B is attached to Monitor[1].
Quoted 7 lines
Quoted 7 lines
Just to make sure I understand this better, "Monitor" is the initial process, and [0] and [1] are separate threads within that process? I would expect B to have Monitor as its parent after A died, but I must be misunderstanding something.
Regardless, your "interesting thing 1" is certainly a side-effect of
YAMA_SCOPE_RELATIONALtrying to do its job.
Correct. Process B is obviously still descendant from the process that is ptracing it so you'd think that this would work with YAMA_SCOPE_RELATIONAL. However, after process A dies, /sbin/init becomes the new parent of Process B. If you want to see this yourselves, you can reproduce this problem with this little test program:
$ cat ptrace_bug.c #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/stat.h> #include <fcntl.h> #include <string.h>
void daemon_process() {
printf("pre-open\n");
int fd = open("test.txt", O_RDWR | O_CREAT, S_IRUSR | S_IWUSR);
if (fd != -1) {
write(fd, "post-open\n", strlen("post-open\n"));
close(fd); }
exit(0);
}
int main(int argc, char** argv) {
if (fork() == 0)
daemon_process(); return 0; } $ gcc -o ptrace_bug ptrace_bug.c
If I strace this on a machine which I've patched with my proposed patch below, I see the following output for the "daemon_process":
$ strace -o strace_out -ff ./ptrace_bug
$ cat strace_out.2815
...
write(1, "pre-open\n", 9) = 9
open("test.txt", O_RDWR|O_CREAT, 0600) = 3
write(3, "post-open\n", 10) = 10
...However, on a machine which I haven't patched and with YAMA_SCOPE_RELATIONAL, I see:
...
write(1, 0x7f74338c0000, 9) = 9 open(0x4007bd, O_RDWR|O_CREAT, 0600) = 3 write(3, 0x4007c6, 10) = 10
...
This is the exact same problem: you can still read the regs and stop/resume tracees but you can't do process_vm_{read,write}v or the ptrace ops that depend on it.
If I now add a pause() call just before the exit of the daemon process, you'll see the following after process A dies:
$ ps u USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND stijn 29772 0.0 0.0 4852 820 pts/0 S+ 09:41 0:00 strace -o strace_out -ff ./ptrace_bug stijn 29778 0.0 0.0 4300 92 pts/0 S+ 09:41 0:00 ./ptrace_bug
$ cat /proc/29778/status Name: ptrace_bug State: S (sleeping) Tgid: 29778 Ngid: 0 Pid: 29778 PPid: 1 TracerPid: 29772
PPid is 1 so /sbin/init is now the real parent. As far as I can tell, this whole reparenting goes on in kernel/exit.c due to:
do_exit
-> exit_notify
-> forget_original_parent
-> find_new_reaperFrom my viewpoint, it would make more sense to reparent Process B to the ptracer that originally forked off Process A. However, looking at the exit.c code, what actually goes on does seem like the intended behavior.
Quoted 45 lines
Quoted 37 lines
Quoted 8 lines
2) More interestingly though, even if Process B does get attached to Monitor[1], as soon as Process A dies, all
process_vm_readvandprocess_vm_writevcalls on Process B start failing. Any other ptrace operations peformed on Process B do succeed.process_vm_readv|writev use
__ptrace_may_accessto check whether the operation is permitted, whereas other ptrace operations (with the exception ofPTRACE_ATTACH) useptrace_check_attach.Right, process_vm_{read,write}v use
PTRACE_MODE_ATTACH(which is what Yama interposes via the LSM entry point in__ptrace_may_access).Quoted 26 lines
To fix this problem,
__ptrace_may_accessshould be forced to return 0 if the calling process is already attached to the target process.The question now is whether or not it's the security module's responsibility to check whether a tracee relationship is already in place or if ptrace itself should do it. For the latter case, which seems more logical to me, you could use the patch below.
What do you guys think?
Regards,
Stijn Volckaert--
Signed-off-by Stijn Volckaert <[email protected]>kernel/ptrace.c 2014-12-24 14:17:20.617824840 +0100 renamed from kernel/ptrace.c 2014-12-24 13:53:23.055346526 +0100 +3
-0@@ -232,6 +232,9 @@ static int __ptrace_may_access(struct ta /* Don't let security modules deny introspection */ if (same_thread_group(task, current)) return 0; + /* Don't deny introspection to already attached ptracer */ + if (!ptrace_check_attach(task, true)) + return 0;Quoted 8 lines
kernel/ptrace.c 2014-12-24 14:17:20.617824840 +0100 static int __ptrace_may_access(struct ta · line 240
Quoted 4 lines
kernel/ptrace.c 2014-12-24 14:17:20.617824840 +0100 renamed from kernel/ptrace.c 2014-12-24 13:53:23.055346526 +0100 +0
-0rcu_read_lock(); tcred = __task_cred(task); if (uid_eq(cred->uid, tcred->euid) &&I'm nervous to add this (or Oleg's suggestion) generally to
__ptrace_may_access, as it would mean other LSMs would stop seeing access checks even when attached. It does seem silly to deny ptrace checks when already attached, but it does change the behavior here.
Quoted 8 lines
An LSM may chose to do checks on a per access basis. Think in terms of access checks on read/write instead of open. Smack and SELinux do this for some network checks. It is reasonable to think that there is a case where a security attribute (or access rule) could change between the attach and the access.
Example: You allow the access when the developer mode switch is set, but not when it isn't. Someone flips the switch.
That makes sense I guess. However, the problem in my case was not that the security policy had change between the "open" and the "read/write" check. Instead, after the death of Process A, the security check now lacks the context to see the relationship between the tracer and the tracee.
Quoted 7 lines
Quoted 7 lines
If the other LSM folks don't see a problem here, then it should live in the general case. Otherwise, I'm happy to add this check only in Yama. The existing Yama scopes should ignore attach requests when already attached.
-Kees
Oleg Nesterov
maintainerQuoted 5 lines · Kees Cook
I'm nervous to add this (or Oleg's suggestion) generally to
__ptrace_may_access, as it would mean other LSMs would stop seeing access checks even when attached. It does seem silly to deny ptrace checks when already attached, but it does change the behavior here.
Same here.
Quoted 3 lines
If the other LSM folks don't see a problem here, then it should live in the general case. Otherwise, I'm happy to add this check only in Yama.
In this case this check should probably go into ptracer_exception_found().
Btw it looks buggy... RCU protects ptrace_relation object, but not relation->tracer (the final __put_task_struct() calls yama_task_free() and frees task_struct without rcu gp).
This means that task_is_descendant(parent, tracer) can dereference the already freed/unmapped parent, no?
And the usage of ->group_leader looks strange. tracee->group_leader can point to nowhere if the task is already dead. In this case "relation->tracee == tracee" can be false-positive (the same task_struct can be re-allocated), but probably this is not that bad exactly because the task is dead anyway.
prctl(PR_SET_PTRACER) looks strange too wrt group_leader. What if the caller execs later? The comment says "we want process-level granularity of control", but this is only true if the main thread does exec.
And get/out_task_struct(myself) look unneeded.
And it seems that task_is_descendant() doesn't need ->group_leader at all, it could simply do
static int task_is_descendant(struct task_struct *parent,
struct task_struct *child)
{
int rc = 0;
struct task_struct *walker = child;
if (!parent || !child)
return 0;
rcu_read_lock();
do {
if (same_thread_group(walker, parent)) {
rc = 1;
break;
}
walker = rcu_dereference(walker->real_parent);
} while (walker != &init_task);
rcu_read_unlock();
return rc;
}Oleg.
Kees Cook schreef op 6/01/2015 om 0:47:
Quoted 7 lines
Just to make sure I understand this better, "Monitor" is the initial process, and [0] and [1] are separate threads within that process? I would expect B to have Monitor as its parent after A died, but I must be misunderstanding something.
Regardless, your "interesting thing 1" is certainly a side-effect of
YAMA_SCOPE_RELATIONALtrying to do its job.
I've thought about it some more and there's actually a much easier way to show what is going on here. Suppose that you have a debugger that forks off its own tracee and then traces that tracee PLUS any of that tracee's future childs. At some point you may get:
+----------+ +----------+
| DEBUGGER | -- FORK + ATTACH --> | TRACEE A |
+----------+ +----------+
| |
| |
| FORK
ATTACH |
| |
| V
| +----------+
+--------------------------> | TRACEE B |
+----------+Now at this point, if tracee A dies, tracee B will get reparented to the init process. From that point onwards, the debugger can no longer perform any operations that go through __ptrace_may_access. These include process_vm_{read,write}v but also PTRACE_{POKE,PEEK}{TEXT,DATA}. I don't see how Yama can possibly tell that tracee B and the debugger are still related at this point so I see no easy fix for this. Patching __ptrace_may_access might indeed not be a good idea as it is used to check for credentials to perform a bunch of other non-ptrace operations throughout the kernel.
The possible solutions that I can see right now are:
1) Adding some sort of original_parent field to task_struct, just for the sake of relationship tracking
2) Changing the credentials check in process_vm_{read,write}v only so that you don't go all the way into __ptrace_may_access if you're already attached as a ptracer
-- Stijn
Oleg Nesterov
maintainerQuoted 4 lines · Stijn Volckaert
From that point onwards, the debugger can no longer perform any operations that go through
__ptrace_may_access. These include process_vm_{read,write}v but also PTRACE_{POKE,PEEK}{TEXT,DATA}.
PTRACE_POKE/PEEK should work? not that this really matters...
Quoted 3 lines
I don't see
how Yama can possibly tell that tracee B and the debugger are still related at this point so I see no easy fix for this.
Well, perhaps yama can also have PR_SET_PTRACEE, I dunno.
Quoted 3 lines
Patching
__ptrace_may_access
might indeed not be a good idea as it is used to check for credentials to perform a bunch of other non-ptrace operations throughout the kernel.
Just add the "ptrace_parent(task) == current" check into ptracer_exception_found() ?
Quoted 3 lines
The possible solutions that I can see right now are:
1) Adding some sort oforiginal_parentfield totask_struct, just for the sake of relationship tracking
And what should we do with this pointer if original_parent exits?
Quoted 3 lines
2) Changing the credentials check in process_vm_{read,write}v only so that you don't go all the way into
__ptrace_may_accessif you're already attached as a ptracer
This really doesn't look good, imo.
Oleg.