News: 1619034447

that this was a CCP sponsored/encouraged attempt at "supply chain' code repository compromise?

Still, one should question whether the policy of "Don't probe possible vulnerabilities because it might upset us" is such a great idea in today's infosec security targeting world.

As noted in the story, making automatic assumptions on code quality strictly based on sourcing locations or personal accreditations is leaving the channel open to possible hacking (cough, SolarWinds and Git, cough).

In today's aggressive world we need better. A lot better. Probing vulnerabilities is what white hats do. That's their job. Whinging about the fact that they had the nerve to target *you* didn't fix your potential vulnerabilities.

I think that comment is missing the point.

"Still, one should question whether the policy of "Don't probe possible vulnerabilities because it might upset us" is such a great idea in today's infosec security targeting world."

Probing vulnerabilities in the code is important, and the Linux community doesn't have a problem with people doing that. Nor is there a problem looking at the ways people operate and suggesting that such ways lead to security problems. The key is that observation of others is good and probing of your own systems running others' code is good. Probing others' systems without permission is a very different story.

Consider a parallel. Penetration testing is important to ensure that security procedures are sufficient and followed. Hiring a penetration tester is a good idea. However, being a penetration tester of someone who didn't agree to it is not. At best, you have people angry at you though fixing problems you've demonstrated. At worst, you end up in jail. If these researchers had gained the agreement of someone in authority on the team that they would run the experiment, the community would probably be reacting very differently. They didn't even try to get permission.

All of the subjects in the subject line know how to get around domain-name and IP restrictions. That's a pretty bad way to enforce security of the jewels.

Many researchers have run afoul of authorities when they probed some product. Witness Randall Schwartz who exposed security vulnerabilities at Intel and was prosecuted.

It's the corporate PHB who are the most dangerous to security. They want profits over competence.

Lots of people are hanging a false choice argument that punishing the uni that approved this amounts denying that researchers should be able to look at the process as well as the code when it comes to kernel security.

Yeah, developers can try to make submissions that get around the crude email block. That should be your first clue this was a political move to punish the Uni for screwing up. That doesn't mean the actual reviewers aren't also doing additional screening. They are, and were before, now they just have one more dumb line on the checklist.

Before the Uni approved this, they should have checked with the kernel team to see if there was an established processes for this, and respected the teams wishes by not launching an attempt to subvert the process without a green light from the higher ups. That doesn't mean the kernel team should or can block all such research, or that the Uni couldn't publish their concerns or how the process is handled.

Instead the Uni clearly has it's own process issues to address, as their "dont give them a chance to say no" process has predictably left them wearing their own ass for a hat.

I suspect that ban might get rolled back if they publish and stick to some reasonable guidelines for campus sanctioned research. We'll see I guess, once steam stops shooing from Linus' ears.

One last point worth raising, the kernel teams response should probably treat Uni researchers the same regardless of their nationality. Do we really want them setting a precedent that Uni's in China, Iran, and Russia can attempt unauthorized penetrations without sanctions? Or out of all of the possibilities is maybe expecting a Uni level organization to get prior consent not such a bad option?

What these academics are doing is a form of Quality Control, something that should be routine for any repository that's likely to contain critical code. The result sounds like a typical "Me thinks they doth protest too much" type of reaction.

If the researchers informed the maintainers after the email and before it even became a commit then what was learned? If they wanted to see if such a patch would be accepted then you would think they would let the kernel review process happen, let it get past some level of scrutiny and then stop it at a late stage.

Yes, this would be far more annoying, but at least it would actually probe if the project would catch the malicious code. Perhaps I misunderstood the article?

That was a clear "Don't be so bloody stupid" moment for UMn; perfectly reasonable that the Linux kernel folks should do what the UMn hierarchy didn't. And, given that UMn allowed this once, perfectly reasonable to ban that behaviour again.

Thats an awful lot of files for things which never made it into the kernel apparently. Which makes me wonder if by reverting anything from U of M they are actually just getting rid of legitimate stuff, because the research stuff never made it in. I looked at a few of the, and they dont look either malicious or no-ops. So I am puzzled.

what will happen is that all the stuff from U of M will get ripped out, and then from that stuff other people will consider what's valuable, what's not, and re-submit the good stuff

> pointed to Kroah-Hartman's remarks about rejecting future contributions from University of Minnesota email addresses and argued that making trust decisions on the basis of email domains rather than confirmed code correctness is a more noteworthy problem.

Mister Valsorda doesn't understand the ban at all, just because somebody isn't banned doesn't mean they won't go through peer review before the merge.

What happened, is that UM proved themselves to be wholly untrustworthy , both on the "experiments on humans", and "keeping researchers from doing unethical experiments" fronts.

The easiest way to subvert software is to go to the distribution or more low profile infrastructure. Ethics are of course a very serious obstacle, but what about a (large) local government with a massive national security apparatus. They send your company a "request" to do XYZ to code UVW distributed to ABC. They do this in the form of a national security letter containing a non-disclosure clause.

Now you have several choices: a) you blab publicly and go 10..25 years to jail, or b) you refuse to cooperate and the national security threat database suddenly includes your company and you personally, or c) you reluctantly do as you are told.

Some choice, don't you think?