Re: [PATCH] ptrace: allow restriction of ptrace scope

Roland McGrath
2010-06-16T23:11:08Z

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