lkml.org 
[lkml]   [2014]   [Dec]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subject[PATCH RFC] 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

--

Signed-off-by: Stijn Volckaert <Stijn.Volckaert@elis.ugent.be>

--- a/kernel/ptrace.c 2014-12-24 13:53:23.055346526 +0100
+++ b/kernel/ptrace.c 2014-12-24 14:17:20.617824840 +0100
@@ -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) &&


\
 
 \ /
  Last update: 2014-12-24 15:01    [W:0.421 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site