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

Kernel vulnerabilities: old or new?

Kernel vulnerabilities: old or new?

Posted Oct 20, 2010 18:35 UTC (Wed) by kees (subscriber, #27264)
In reply to: Kernel vulnerabilities: old or new? by intgr
Parent article: Kernel vulnerabilities: old or new?

Not only did those protections stop many of the vulnerabilities from being exploited, some of the vulnerabilities were discovered _because_ of the protections (see the history on how CVE-2010-2955 got reported).

The main difficulty with getting PaX and grsec protections into mainline is that the patchset is hard to separate into individual pieces. Additionally, many of the protections are done in a way that mainline folks do not like for various technical reasons. I suspect the only way to get these protections into mainline is to have someone (or better yet, a group of people) fighting for them that:
a) understands the code
b) understands why it is important
c) have the time to advocate for it and revise patches until they get in

So far, no one has really had all 3. Plenty of people get "b" (even if they don't have "a"), and "c" is insanely frustrating given the attitudes of the mainline maintainers towards security.


(Log in to post comments)

Kernel vulnerabilities: old or new?

Posted Oct 20, 2010 21:14 UTC (Wed) by clugstj (subscriber, #4020) [Link]

How about
d) are not so hardheaded that they will actually listen to what other people say.

Kernel vulnerabilities: old or new?

Posted Oct 20, 2010 23:42 UTC (Wed) by jamesmrh (guest, #31622) [Link]

Kees listened to what upstream folk said, but was lead in circles by them, and ultimately his Yama code was vetoed.

I'm not sure what the solution is.

Users can request the protections be added to their distros, which will at least get them better protected, and possibly help make a stronger case for upstream inclusion.

Another possibility is for a company with a strong involvement in Linux to hire someone with the traits a & b above, to act as a system-wide security coordinator / advocate. i.e. make it someone's paid job to work on kernel hardening.

Kernel vulnerabilities: old or new?

Posted Oct 21, 2010 9:15 UTC (Thu) by patrick_g (subscriber, #44470) [Link]

>>> Another possibility is for a company with a strong involvement in Linux to hire someone

Why not the Linux foundation ? Perhaps they can sponsors a few security experts ?
There is a "Linux fellow program" here => https://www.linuxfoundation.org/programs/developer/fellowship

Kernel vulnerabilities: old or new?

Posted Oct 21, 2010 11:30 UTC (Thu) by michaeljt (subscriber, #39183) [Link]

> Additionally, many of the protections are done in a way that mainline folks do not like for various technical reasons.

Would you be able elaborate on that, or provide a couple of pointers? (Sorry for lazily asking rather than researching myself!)

Kernel vulnerabilities: old or new?

Posted Oct 21, 2010 11:34 UTC (Thu) by michaeljt (subscriber, #39183) [Link]

> > Additionally, many of the protections are done in a way that mainline folks do not like for various technical reasons.

> Would you be able elaborate on that, or provide a couple of pointers? (Sorry for lazily asking rather than researching myself!)

Replying to myself - probably http://userweb.kernel.org/~jmorris/lss2010_slides/out-of-... will be one of the pointers.

Kernel vulnerabilities: old or new?

Posted Oct 24, 2010 12:09 UTC (Sun) by vonbrand (guest, #4458) [Link]

Sorry, but "widely used" isn't really an argument... the saying here goes "10,000,000,000,000 flies eat sh*t, so should you"

Kernel vulnerabilities: Promoting protection

Posted Oct 29, 2010 20:43 UTC (Fri) by jageorge (guest, #61413) [Link]

The biggest problem in this domain is one of egos. Influential kernel developers who don't care about stuff that they don't own, and security hackers who want to see their names in lights.

In the case of kernel hackers there is a tendency to use excuses which boil down to shooting down solutions which don't have a perfect "model" for resolving an exploit or class of exploits. (AppArmor) Also, kernel hackers tend to hate large patches which actually address a bunch of conceptually separate issues to the point where the aggregate gets blown off. (GrSec)

Security hackers on the other hand will legitimately discover bugs, but don't like Linus's attitude that their presumably security compromising exploit bugs are no more worthy of special recognition than any other kernel bug. Furthermore, there is a tendency to provide "fixes" which simply shift the point of exploitable failure from a current failure to a future or even concurrent failure point. This is sometimes combined with with creating solutions to a bunch of small kernel vulnerabilities in combination with larger frameworks which make them harder to apply to the root cause problems and to audit. There is sometimes a lack of consideration of balancing of performance, scalability, and complexity considerations against quick and dirty or overly complex framework solutions. Finally, there is often a desire to re-invent the wheel rather than understanding and working with existing robustness models.

The Solution (tm):
1. Preview solutions with key kernel developers who are interested in security.
2. Request reviews from other key kernel developers who can help with feedback.
3. Treat different conceptual problems with different patch sets. Debugging, tracing, simple patches, class of exploit preventions, etc.
4. Performance matters.
5. Compatibility matter even more. Breaking X.org, FTP, SSH, procfs, udev, or Apache is not OK. :-)
6. We already have SELinux and AppArmor - don't reinvent the wheel - invent the tire instead.
7. Document your work... When has this been a problem? Why should people care now? What is the design of the solution? Why couldn't it be simpler? Are there benchmarks? What issues were identified in review and how were they addressed?

I really wish that security (and performance) were addressed in a more rigorous fashion, but the best we can hope for is learning how to work together and maybe getting a corporate sponsor. :-)


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