| |||||||||||||
SELinuxDenyPtrace and security by defaultSELinuxDenyPtrace and security by defaultPosted Apr 12, 2012 6:31 UTC (Thu) by JoeBuck (subscriber, #2330)Parent article: SELinuxDenyPtrace and security by default "if you understand what ptrace or gdb are, you probably can figure out how to turn this feature off." What Dan misses is that his employer has sold a number of large deployments to corporate customers, where the software developers don't have root on the systems they use. What he also doesn't seem to sufficiently appreciate is that if a security feature has to be turned off to diagnose any problems, everyone will wind up being forced to turn it off so he might has well have saved the work and not bothered with the feature. That said, of course ptrace can be a security issue. Maybe there can be a more sophisticated way of limiting its use. For example, I don't want my browser, or any helper app that it launches, to be able to ptrace, but if I start a debugger from my terminal, it should be able to trace any non-setuid process I own. Come up with a way to prevent processes we don't expect to use ptrace to be forbidden to do it.
(Log in to post comments)
SELinuxDenyPtrace and security by default Posted Apr 12, 2012 10:32 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
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.
SELinuxDenyPtrace and security by default 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:
https://developer.android.com/guide/topics/manifest/appli...
SELinuxDenyPtrace and security by default Posted Apr 13, 2012 15:50 UTC (Fri) by bronson (subscriber, #4806) [Link]
That doesn't fix the drkonqui problem... Maybe reverse the sense? Only allow programs marked by root as ptrace-trusted to run ptrace?
SELinuxDenyPtrace and security by default Posted Apr 12, 2012 14:23 UTC (Thu) by niner (subscriber, #26151) [Link]
"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."
The policy is to let the developers work as local administrator which hardly is an improvement over unrestricted ptrace...
SELinuxDenyPtrace and security by default Posted Apr 12, 2012 14:33 UTC (Thu) by raven667 (subscriber, #5198) [Link]
That's still an improvement over everyone who is not developing software also having this enabled.
SELinuxDenyPtrace and security by default Posted Apr 12, 2012 18:22 UTC (Thu) by Fats (subscriber, #14882) [Link]
"What Dan misses is that his employer has sold a number of large deployments to corporate customers, where the software developers don't have root on the systems they use."
I do hope this employer then has proper IT group that during testing finds out the ptrace() should be allowed for the programmers. Otherwise I think that company will be doomed because in general they won't be able to properly support their programmers.
greets,
|
|||||||||||||