Rafal Wojtczuk <nergalat_private>: > 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, tfat_private-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)
This archive was generated by hypermail 2b30 : Thu Oct 25 2001 - 13:56:36 PDT