Linux kernel team rejects University of Minnesota researchers’ apology

They still seem to believe that what they did, increases the security of Linux. And comments still suggest the fix to make Linux less "open" to contributions.

It does not seem to me that they have thought much about what they are saying. For example, in a project like Linux, there is new code, but they majority of contributions, especially small fixes (as compared to new drivers and rewrites of subsystems), are very likely bug fixes. And many bugs can intruduce security issues, too, even if that might not be obvious. Therefore, it is not clear at all that making Linux more "closed" (which seems to be the solution which the UMN people and their friends suggest) would make it any more secure. More scrutiny by top maintainers means more time is needed; needing more time means automatically less fixes can be applied, since the maintainer's time is the bottleneck; applying less fixes means more open bugs, and having more open bugs can at least easily mean to have more security issues.

There are plenty of closed source projects with a security which is clearly worse than Linux. And not only that, but core Internet security infrastructure like DNS or OpenSSL is open source. The issue is rather that companies cannot be arsed to support that infrastructure they depend on. It would be interesting if the UMN people could come up with research or a hack which motivates them to change. (OTOH, one mayor windows worm per decade such as locky, wannacry, petya, tiny banker, cryptolocker, flame, and so on may be sufficient for the latter in the long run.)

What I don't understand is what the theoretical endgame would have been here?

Putting the circumstance aside that their submissions are effectively indistinguishable from malicious content (and should be treated as such anyway), if you stay in their line of "it's just research", then getting banned is just another possible outcome that should have been expected as a possibility from the beginning, no?

What they are doing now is basically saying "Yeah we know we did this to see whether actors like us get blocked, but you see, it's US, we should clearly get different treatment".

Ars is stirring the pot for drama.

> The biggest problem is that even experienced kernel developers far too often cannot clearly decide whether the code is better with or without the patch.

It was a bulk revert; not "we can't tell if these are bad" but "we're reverting all of these until we can re-review them". Or, if you're claiming they shouldn't have been merged in the first place if it wasn't possible to be 100% confident in them... that's not how humans work, nor programming. Even if you specify your code in coq or something, you still have to verify that the model is correct and there's still room for human error.

> the kernel community prefers kludges over simpler, visibly more robust code if the latter has performance impact (The biggest example of this is of course choosing a monolithic kernel instead of a microkernel.)

Yes, they should have followed in the footsteps of all those other successful feature-complete microkernels like, um.... maybe QNX? Maybe? To be fair, I don't know that there's a reason why microkernels seem stuck in the "theoretically great but nobody's made one that works in the real world", but here we are.

So in broad strokes: You seem to be very confident that if kernel devs would just Do It Right then they could eliminate all bugs and malicious code, but this seems unlikely.

> * the kernel community prefers kludges over simpler, visibly more robust code if the latter has performance impact (The biggest example of this is of course choosing a monolithic kernel instead of a microkernel.)

You should just run Minix.

In my experience, it's not a lack of empathy, but trying to prove to management that they shouldn't get rid of the security team. At most companies I've done security testing at, telling management that you didn't find any vulnerabilities immediately puts you and your team on the chopping block because they think you're a waste of money if you don't find anything. I've noticed it's mostly new people who aren't confident they can easily find a job are the ones most often going out of their way to report security issues that aren't actually a big deal.

At least those phishing exercises are done with the informed consent of the organization.

If they go too far and impact day-to-day work, or if people complain, the executives understand what is going on and who they can talk to about improving the process.

And if it feels lacking in empathy, consider that the company's management needs to sign off on any (legal) phishing tests that their employees are subjected to.

Please note that the senior management is always in the loop for the phishing tests along with some of the security team. It's just the users who are not told. You can't just send out a phishing email without telling anyone about it, you are liable to get fired for it. Remember the first rule of cybersecurity testing is to get written permission and then establish rules of engagement.

All these researchers had to do was reach out to Greg, loop him in the study to get his go ahead for it.

Now that several of these 'patches' are now in stable and in fact did introduce issues is a big problem and a major waste of time for the maintainers.

why such extreme take?