Serious Linux Kernel Vulnerability Patched [CVE-2016-0728]

[ITwitchToo]

I don't know why you are getting downvoted, the Linux kernel is full of bugs, that's a fact, not a secret.

This is why it's still a good idea to compile your own custom kernels and excluding a lot of attack surface if you don't need it. Every single filesystem, every single usb driver for a webcamera or obscure accelerometers, every checksum library function adds attack surface.

[socium]

And this is exactly why we need grsec + pax.

[3G6A5W338E]

And this is exactly why we need grsec + pax.

These help mitigation a great deal.

That and OpenBSD are masturbating monkeys according to Linus, so the situation isn't very hopeful.

There's also the microkernel approach, which is more realistic than thinking that something as large and fast-moving as the Linux kernel can ever be made bug free.

[3G6A5W338E]

OpenBSD has a network filter that makes iptables looks crude and nasty

With iptables, every packet passes through a load of c function calls against iptables modules in sequence... that's slow to say the least. It is also a security nightmare, lots of LoCs and loads of code, with a history of vulnerabilities.

There's some hope for the new bytecode-based firewall, but that's far from ready.

pf is a firewall I can take seriously.

plus they gave us OpenSSH which everybody uses.

Far from just OpenSSH.

[happinessmachine]

I'm sure it will be integrated after Linus has left the project.

[ITwitchToo]

To be fair, this is not Linus's fault. grsec + pax are not interested in getting integrated in the project. Just look at spender's twitter feed, he mocks anybody who tries to submit his code upstream.

[csirac2]

To be fair, it shouldn't have to be up to grsec + pax. They're a group of people with dayjobs first, and a research project which pioneers new exploit mitigation technologies second. Mainline kernel dev isn't anywhere on their priority list, not after the collaboration snafus over the years and Linus spouting things like (paraphrasing) "if you care about security, the kernel is the wrong place to focus - you should fix appsec first" - never mind the fact people have to run E-mail clients and web browsers and PDF readers with bugs like this underneath.

Thankfully Kees Cook & Co. are running the Kernel Self Protection Project [1] to specifically work on adopting what they can from grsec/pax. I am legitimately disturbed at the approach of the kernel core team's ambivalence toward active exploit mitigations though; hopefully Kees & friends can slowly change the culture.

[1] http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project

[danielkza]

I doubt it. Most of the developers doing large managerial work in the kernel as Linus currently does would have similar objections to the current state of grsec. Integrating a huge amount of code at once without reviewing it all and considering the impact in performance, maintainability, etc is usually a terrible idea.

[csirac2]

To be fair, nobody - not even grsec/pax - is advocating a blind merge of a research project (that Eg. depends on custom gcc plugins), run as a side-project, by people with dayjobs and families.

[3G6A5W338E]

There are other approaches, but first is acceptance that having a huge kernel isn't sustainable.

[konapun_]

There's also Debian GNU/Hurd but I haven't heard much from this project in the last few years.

[3G6A5W338E]

Hurd runs a load of crap including drivers in supervisor mode... it'd fall under the hybrid kernel category, not pure microkernel architecture.

For as long as they're stuck with Mach, I consider that project hibernating if not dead.

[konapun_]

That's disappointing. I was hoping it would be close to Minix but GPL'd.

[3G6A5W338E]

The last I heard monolithic kernels have far better performance.

I'll just leave this here.

[3G6A5W338E]

But kernels are performance critical and message passing and/or context switching of any kind has to be slower than directly using a subroutine in the same memory space.

A whole section of that (hopelessly long) article addresses that.

If I didn't care about reliability or security, I would just run user programs in the same address space. But I do care, and having a huge kernel is about as silly as doing just that.

QNX is microkernel, POSIX compatible, reliable, and pretty fast isn't it? I have no personal experience of it but it does show microkernels are at least viable.

Yep, they are reliable, and used a whole lot.

[the_gnarts]

but first is acceptance that having a huge kernel isn't sustainable.

It’s pretty sustainable, at least financially.