| |||||||||||||
Reactive vs. pro-active kernel securityReactive vs. pro-active kernel securityPosted Jul 15, 2011 3:39 UTC (Fri) by dlang (✭ supporter ✭, #313)In reply to: Reactive vs. pro-active kernel security by naptastic Parent article: Reactive vs. pro-active kernel security
again, if someone can show that there is a real problem (i.e. it is possible to exploit this), then a fix gets put in, no matter what the performance cost.
the cost of these things isn't just performance, it's also maintainability (especially if you end up with multiple paths due to this being a configurable option)
(Log in to post comments)
Reactive vs. pro-active kernel security Posted Jul 15, 2011 5:53 UTC (Fri) by naptastic (subscriber, #60139) [Link]
Sorry; I thought one of the points of the article is that some pro-active security measures (I think of them as prophylactic or preventative) are unpalatable to kernel developers, but would remove avenues for abuse by buggy user-space programs; removing symlinks in sticky directories is one example.
I understand and agree with the rejection of these kinds of patches: it's not the kernel's job to fix user-space bugs. But as an option, under debugging or something, could it at least warn, "Hey, app developer, you've left a potential security hole"?
Maybe there's a better way to do this?
|
|||||||||||||