Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UMN CS&E Statement on Linux Kernel Research

cse.umn.edu

Post reply on HN
Print view View original

151–160 of 332 posts

Re: UMN CS&E Statement on Linux Kernel Research

#151

Post by agf »

ellisv wrote: post #108
agf wrote: post #99

Earlier quoted context omitted.

It is a good statement, and I believe they'll follow through, but it's missing something important that is often missing from otherwise professional communication. The last line is "We will report our findings back to the community as soon as practical." It should be followed by "and we will provide an update in no more than 30 days". Without any explicit time frame, holding them publicly accountable becomes trickier…

This sort of incident is difficult to set expectations for reporting back. I expect UMN to move swiftly on this but it’s a large university and may move more slowly than we’d like.

That's why you promise an update, not a resolution.

Re: UMN CS&E Statement on Linux Kernel Research

#152

Post by agf »

boomboomsubban wrote: post #106
agf wrote: post #99

Earlier quoted context omitted.

It is a good statement, and I believe they'll follow through, but it's missing something important that is often missing from otherwise professional communication. The last line is "We will report our findings back to the community as soon as practical." It should be followed by "and we will provide an update in no more than 30 days". Without any explicit time frame, holding them publicly accountable becomes trickier…

> At any point they can just say "we're still investigating" until enough time has passed people aren't paying attention any more. They need to act to get the ban rescinded, they can't just ignore this issue away.

I agree, that's why in this case (as I say in my post) I believe they'll follow through.

Re: UMN CS&E Statement on Linux Kernel Research

#153

Post by easton »

alpb wrote: post #122
Animats wrote: post #7

This is starting to snowball. Industry news sites are picking up the story.[1] Hasn't hit the mainstream press yet. No word from DHS Cybersecurity yet. [1] https://www.google.com/search?channel=fs&q=university+of+min...

How is DHS Cybersecurity related to this?

They’d be concerned about (known-ish) bad actors getting commits into Linux without anyone catching it, and probably want to tell the foundation to start red-teaming the kernel commit process.

Re: UMN CS&E Statement on Linux Kernel Research

#154

Post by prepend »

ghughes wrote: post #148
prepend wrote: post #144

Earlier quoted context omitted.

He didn’t succeed in injecting anything, right? It would be interesting if someone found bad stuff in the kernel, but pet of the org structure makes this hard.

He landed code that nobody seems to understand the purpose of. That looks like success to me.

Thanks, I was wrong and thought the patches weren’t accepted

Re: UMN CS&E Statement on Linux Kernel Research

#155

Post by nolok »

dpwm wrote: post #138
nolok wrote: post #98

Earlier quoted context omitted.

I entirely disagree. Not once do they talk about getting the ban removed, instead they talk about figuring out why it happened and how to be better at having research done being ethical. Was the ban the trigger to them (the heads) looking into it ? Of course since they do already have safeguards and review processes in place, this happened despite those, so they're saying they will investigate them to figure out how…

> Not once do they talk about getting the ban removed, instead they talk about figuring out why it happened and how to be better at having research done being ethical. I feel as if we’re discussing two different statements. > The research method used raised serious concerns in the Linux Kernel community and, as of today, this has resulted in the University being banned from contributing to the Linux Kernel. Here the…

Yes that's called the trigger. You have a trigger, that leads you to focus on and review what caused said trigger, and reach conclusions.

The ban is the trigger. The review is about to happen, so they really can't talk about its result yet. For all you and me know, said review will say their processes are just fine which I would personally disagree with but it could happen. Then, if there was an issue, they will update their processes, which is the end goal stated.

So your quote:

> the ban is the focus – not what led to the ban

The ban is the trigger that starts it, but the focus, the thing on which they will work, is their process. "Something important happened so we will spend lots of time figuring it out how it could have happened despite our processes made to protect against it" makes it pretty clear the focus, the thing they will spend their time on, is the review of their processes.

Re: UMN CS&E Statement on Linux Kernel Research

#156

Post by lmeyerov »

re wrote: post #90
lmeyerov wrote: post #54

Interesting, looks like the 2nd time they're doing the same thing, and 2nd time they're in hot water for it. They even apologized the first time by pleading naivete: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.... . First time they initially skipped IRB review for sending malicious patches to the mailing list, which people do install. (So IRB exemption should not apply.) A top security conference allo…

> looks like the 2nd time they're doing the same thing It's not clear that they're doing the same thing--we don't know that these recent patches are deliberately bogus. See this comment with clarifications from the other post: https://news.ycombinator.com/item?id=26890583

Agreed! The broader R&D group seems to work on symbolic execution, and given the patches, which it seems to stem from.

Most charitably, the tool makes changes maintainers largely don't care about -- see the revert reviews that characterize past acceptances as being rubberstamping of irrelevant patches to irrelevant code -- so this just violates basics like informed consent by not disclosing what's happening. Maintainers had to figure out the nonsense, and instead of declining a second round of undesirable non-opt-in participation, banned. What would normally happen is the patches would be tagged w/ the R&D tool, so people know they're part of an experiment, and can ignore / ask them to stop / consent through action.

Less charitably, it is a DoS attack on reviewers, and who knows what else is in here.

Either way... not good.

Re: UMN CS&E Statement on Linux Kernel Research

#157

Post by ethbr0 »

agf wrote: post #99
Traster wrote: post #2

This is a great statement, they confirm they're aware of the issue, they acknowledge the concerns and they set out their intention to gather the full facts whilst suspending the operation of the research in the meantime. They also acknowledge the systematic way the need to deal with this. I hope their follow up is as thorough but I want to applaud this, it's a good approach.

It is a good statement, and I believe they'll follow through, but it's missing something important that is often missing from otherwise professional communication. The last line is "We will report our findings back to the community as soon as practical." It should be followed by "and we will provide an update in no more than 30 days". Without any explicit time frame, holding them publicly accountable becomes trickier…

> explicit time frame

This seems incompatible with the pace of academia, as I have experienced it.

Re: UMN CS&E Statement on Linux Kernel Research

#158

Post by Taniwha »

kapp_in_life wrote: post #102
earthscienceman wrote: post #10

Earlier quoted context omitted.

Anyone saying that it was a bad idea to ban the entire University isn't looking at the big picture. I look at it from a very philosophical standpoint: The entire idea of an academic (research) institution can be summarized as "an entity representing a group of trusted people who act in good faith of that institution". The moment one of your researchers acts in bad faith, or shows that they cannot be trusted, it's cle…

Banning the university is fine to send a message, but reverting all patches from umn emails seems very shortsighted to me. Especially blindly reverting patches years before this "research" was conducted that almost certainly have had context changes around them, likely introducing more harm than good.

I think that reverting them so that they can be reviewed is entirely appropriate - sure there are lots of people at that particular university, but it's not the linux maintainer's job to know which of them are bad actors - better that the entire university gets locked out, if only to get their attention, and then let them sort out their bad actors before being let back into the fold

Re: UMN CS&E Statement on Linux Kernel Research

#159

Post by a-dub »

a-dub wrote: post #128
detaro wrote: post #93

Earlier quoted context omitted.

If you wanted to know if the kernel review process is able to reliably catch malicious attempts you literally could have just asked the kernel maintainers and they'd told you that no, review can't go that deep. Or looked at non-malicious bugs and observed that no, review does not catch all bugs with security implications. You'd very likely would have been able to get code past them even if you told them that there ar…

the project is 30 something odd years old now, and is no longer a hobby, it is now critical infrastructure that powers virtually everything. it's unfortunate that something happened in the project that cost the maintainers a lot of hours, that comes with the territory of working on important software, i'd argue. i don't want an espionagetastic fundamentally untrustable and inescapable computing hellscape, airplanes f…

> Lots of slippery slopes there, and science has spend a long time to get away from such an "the end justifies the means" attitude.

if the developers were working for a private company, there could be a similar loss in time for a similar exercise that could be approved by company leadership, no? if tim cook ordered an audit and didn't tell anyone, wouldn't there be developers at apple feeling the same way?

look, i get it, it's unfortunate and people feel like it's a black eye... but it's also a real issue that needs real attention. moreover, linux is no longer a hobby, it is critical infrastructure that powers large chunks of society.

Re: UMN CS&E Statement on Linux Kernel Research

#160

Post by kapp_in_life »

shultays wrote: post #147
kapp_in_life wrote: post #102

Earlier quoted context omitted.

Banning the university is fine to send a message, but reverting all patches from umn emails seems very shortsighted to me. Especially blindly reverting patches years before this "research" was conducted that almost certainly have had context changes around them, likely introducing more harm than good.

they are re-reviewing the patches and will be accepting them back if they look fine, it is not really blindly rejecting them all

And in the meantime allowing patched permissions vulnerabilities to reappear in mainline? Seems to be a bit of an overreaction no? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Post reply on HN