Roughly the same problem exists on locked down Windows (installing a debugger hook requires System privileges, but the local user may not legitimately have System privileges) and presumably companies that want their C or C++ developers to be at all effective have come up with a policy and mechanisms to handle this case.
Would it be better to have millions of locked down machines where the user doesn't need ptrace and there is a boolean that would disable it, but the user lacks privileges to enable that boolean?
I _think_ SELinux could be configured to grant ptrace rights to binaries like gdb, but the problem is that this mostly undoes the security benefit of removing the privilege in the first place.
Maybe a nice alternative would be to enable ptrace by default only for processes which are marked at exec-time in some way as volunteering to be traced. The "your children" rule is a primitive version of this restriction, but a smarter one could allow for almost all legitimate debugging. The only special case where you'd want to turn off the boolean then would be debugging of a production system that has some error you can't reproduce under test conditions yet must anyhow diagnose and fix. That's a narrow enough case that requiring people to jump through hoops ought to be acceptable.
Posted Apr 12, 2012 13:48 UTC (Thu) by cesarb (subscriber, #6266)
[Link]
> Maybe a nice alternative would be to enable ptrace by default only for processes which are marked at exec-time in some way as volunteering to be traced.
Android has something like that, the android:debuggable attribute: