Rafal Wojtczuk <nergal@7bulls.com>:
> 1) the property of "having an ptrace-attached child" survives the execve
Okay, let's consider this from a more philosophical point-of-view.
(1) ptrace(2) *is* a dangerous system call.
(2) we have seen exploits twice this year now, though after the first
one, we *thought* to be safe
(3) it seems to be difficult to think of everything and get all the
details right.
(4) under normal circumstances, it's being rarely used.
But nevertheless, there are times where it comes in very handy.
We already have seen on this list a kernel module that completely kills
ptrace(); most users can indeed live without it, and especially on a
machine providing network services (like http), this may be a good idea.
Nevertheless, it's very convenient to have tools like strace(1) available
for debugging, also on production machines, and these require ptrace().
Hence, I'd like to suggest a very simple and more modest "solution" to
this problem for the paranoid. (Well, it's not really a solution, only a
simple, crude but effective hack, but it should make some people sleep
much better.)
Simply add a line to arch/<your-architecture>/kernel/ptrace.c:
asmlinkage int sys_ptrace(long request, long pid, long addr, long data)
{
struct task_struct *child;
struct user * dummy = NULL;
int i, ret;
if(!in_group_p(102))return -EPERM;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
or with whatever GID that is convenient for you. Then, create the
corresponding group and add to it all the users that you want to be able
to use ptrace on your system.
Of course, this will not be in the least bit new to people who ever had a
closer look at the kernel, but for the average paranoid webmaster
anticipating future problems here, it might be interesting to know how
simple it is to get a useful workaround.
--
regards, tf@cip.physik.uni-muenchen.de (o_
Thomas Fischbacher - http://www.cip.physik.uni-muenchen.de/~tf //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y) V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1)) (Debian GNU)
