User: Password:
|
|
Subscribe / Log in / New account

Reactive vs. pro-active kernel security

Reactive vs. pro-active kernel security

Posted Jul 14, 2011 7:56 UTC (Thu) by dsommers (subscriber, #55274)
Parent article: Reactive vs. pro-active kernel security

I just wonder when we will see a fork of the kernel, where different security patches from different people are implemented and kept in-sync with the latest upstream kernel. This could be those mentioned in the article, PaX, etc, etc.

Then as these patches are proved to be stabilised, maybe providing some real performance impact numbers, maybe even generalised or made to solve real issues in the kernel, they might be accepted gradually in the end upstream. Just like the realtime patches, where even Linus knows what's happening - but as it solves issues he can see and understand, he let them in - one by one.


(Log in to post comments)

Reactive vs. pro-active kernel security

Posted Jul 14, 2011 18:34 UTC (Thu) by dlang (subscriber, #313) [Link]

such forks already exist, it's just that very few people use them.

there is seldom very much disagreement on the performance impact, so 'real performance impact numbers' don't help much. the disagreement is in the value of the protection being provided.

As the article says, if someone can show a way to use one of these things in an exploit, the problem gets fixed fast (and a generic solution to the type of bug _is_ preferred when a fix like this is done)

but if there's not known way to exploit the vulnerability, or the exploit can only be done by the system administrator, there is a lot of resistance to impacting performance 'just in case someone figures out how to exploit it later'

Reactive vs. pro-active kernel security

Posted Jul 14, 2011 20:18 UTC (Thu) by patrick_g (subscriber, #44470) [Link]

>>> there is seldom very much disagreement on the performance impact, so 'real performance impact numbers' don't help much.

I haven't seen any performance numbers between the mainline kernel and the GRSecurity/PaX kernel. Do you have a link ? I think it will be very interesting to see a benchmark like this.

Reactive vs. pro-active kernel security

Posted Jul 14, 2011 20:33 UTC (Thu) by dlang (subscriber, #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 (guest, #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 (subscriber, #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 (guest, #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).


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds