Known-exploit detection for the kernel

Posted Dec 19, 2013 1:07 UTC (Thu) by gerdesj (subscriber, #5446)
Parent article: Known-exploit detection for the kernel

This is very well intentioned (and I'm thankful that someone is thinking laterally) but I think it is not the right way.

The kernel should restrict itself with doing kernel related stuff - doing complicated things to and with my hardware. It should not try and be an IDS.

For IDS I would like my perfect kernel to provide access, in a reasonably safe way, to a wealth of information about what is happening in there.

As far as I can tell (as a non KDev) it does that rather well already and getting better as are the u/s tools.

If I want to somehow attach a form of Ksnort/KclamAV or whatever to the kernel then I will (I wont - it's daft) but I'm not convinced that you will do it better (but your's will be far cooler and bloody quick).

KDevs - please continue doing what you do remarkably well - we sysadmins will err... try and keep up.

I keep re-reading the article and also note the list of names of people I respect in there but I can't help but think that this is not a good approach to securing the Linux kernel - what am I missing?

Cheers
Jon

ooo look ... me .. yes: me

Posted Dec 19, 2013 1:27 UTC (Thu) by gerdesj (subscriber, #5446) [Link]

Got it at last.

Kernel devs: Do your best at making the bestest, fastest, safest and most featureful kernel you can.

Me (sysadmin): Keep an eye out for vulnerabilities. Notify the kernel devs accordingly.

That'll do pig.

Cheers
Jon

Known-exploit detection for the kernel

Posted Dec 19, 2013 1:28 UTC (Thu) by dlang (guest, #313) [Link]

This isn't a way to secure the kernel as much as a way to have it act as a honypot if a problem that's been fixed gets triggered.

There is currently no way to detect that this sort of thing is taking place, and short of logging every syscall, it's just not possible without explicit support like this.

As long as the maintinance of this is not a burden, I don't see a problem with this (done sanely, rate limited with decent log messages)

you already have the kernel logging a lot of things, this is just a little more to go into the logs that you can either ignore or take advantage of.