This constraint seems fairly insane to me, but I don't really care about people using sysctl to enable insane things if that's what floats your boat. GDB's "attach", "strace -p", etc. are pretty normal (and highly useful) things for ordinary users debugging their own programs. I tend to think that this constraint offers more a delusion of security than much real protection. But I'm too lazy to try to come up with a more contorted exploit that this wouldn't prevent, so I won't belabor the point. I think those who are actually paranoid would use something more meaningful via the LSM ptrace check, like SELinux with a policy that only permits known debugger applications to use ptrace. Aside from SELinux, it could also be done with a new capability like CAP_PTRACE_MINE and filesystem capabilities on installed debugger application binaries, for example. You've described this as allowing ptrace on "children", but really it's "unorphaned descendants", i.e. also children of children, etc. I don't think "task->pid > 0" is a sort of check that is used elsewhere in the kernel for this. Perhaps "task == &init_task" would be better. It's not immediately obvious to me how this interacts with pid_ns, or should. Probably it shouldn't pay attention to pid_ns, as it doesn't. But I think it merits an explicit statement of intent about that. I suspect you really want to test same_thread_group(walker, current). You don't actually mean to rule out a debugger that forks children with one thread and calls ptrace with another, do you? Oh, and surely you meant real_parent. Off hand I think that might only really add up to a different constraint if you had some ptrace attaches already live when you did set the sysctl flag. But I have the vague sensation I'm overlooking some other arcane case. And it just doesn't logically match the stated intent of the thing to depend on parent rather than real_parent. Thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
