| |||||||||||||
Reactive vs. pro-active kernel securityReactive vs. pro-active kernel securityPosted Jul 14, 2011 20:18 UTC (Thu) by patrick_g (subscriber, #44470)In reply to: Reactive vs. pro-active kernel security by dlang Parent article: Reactive vs. pro-active kernel security
>>> there is seldom very much disagreement on the performance impact, so 'real performance impact numbers' don't help much.
(Log in to post comments)
Reactive vs. pro-active kernel security Posted Jul 14, 2011 20:33 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
getting good 'performance numbers' from an entire kernel is hard to do.
however, when particular patches are involved (such as the copy from/to user modifications referred to in the article), there's no disagreement that the extra checks will impact performance.
far to many security people take the stance that security checks should always be implemented, in as many places as possible, performance just doesn't matter in comparison (I'm sure I come across like this sometimes to my development folks ;-). When working on a particular installation or use case, this may be very valid, but when doing general purpose software where you don't know what it will be used for, you can't say "this change is below user perception so we'll make this change" or "we accept that we will need 101,000 machines instead of 100,000 machines to run this application, so we'll make this change"
Reactive vs. pro-active kernel security Posted Jul 17, 2011 21:56 UTC (Sun) by gmaxwell (subscriber, #30048) [Link]
The applications where security is far more important than performance are no less real because other things exists. Consider the firewalls and jump-hosts that mediate administrative access to those 100,000 machines.
General purpose software doesn't mean "ignores requirements that are less important to me, but more important to others" — I'd say that something general purpose software seeks to find a blended solution that works acceptably for all cases, and offers options where the needs differ.
There is obviously a maintainability concern with options, but copy from/to checks can be made fairly self-contained— far more so than, e.g. the peppering of the codebase that SELinux requires. I'd think that this kind generic boundary hardening is exactly the kind of optional feature a general purpose system should have.
Reactive vs. pro-active kernel security Posted Jul 18, 2011 8:03 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
actually, most of the protections we are talking about adding here are not really relevant to the firewall/jump box type of application. In those applications you severely limit what code you run on the box and test it extensively. these types of protections are mostly aimed at protecting the systems after you allow untrusted people to run arbitrary code on it.
there really are not that many situations where you do that.
Reactive vs. pro-active kernel security Posted Jul 15, 2011 16:01 UTC (Fri) by PaXTeam (subscriber, #24616) [Link]
http://grsecurity.net/~spender/benchmarks.txt (the features with the biggest impact have always been duly noted in the config help too, also i386 numbers would be better since the CPU support is better for some features).
|
|||||||||||||