General > General Technical Chat

University of Minnesota Linux code security issues; banned and to be removed

<< < (18/23) > >>

Ed.Kloonk:
I suspected the K devs would back down. Oh well. Too bad.

tunk:
Letter requesting withdrawal (April 26, 2021):
https://www-users.cs.umn.edu/~kjlu/papers/withdrawal-letter.pdf
There's more info on his page, including a letter to the Linux foundation from the department head:
https://drive.google.com/file/d/1z3Nm2bfR4tH1nOGBpuOmLyoJVEiO9cUq/view

Looks like the he has been removed from the program committee of IEEE S&P 2022:
https://www.ieee-security.org/TC/SP2022/cfpapers.html
But this has not been updated on his home page:
https://www-users.cs.umn.edu/~kjlu/

--- Code: ---News
[03/03/2021] I will be on the program committee of IEEE S&P 2022.
[02/12/2021] Our work on detecting unsafe DMA accesses was accepted to USENIX Security'21. Unchecked and inconsistent DMA accesses are very common in drivers; we found about 300 such bugs in Linux drivers.
....

--- End code ---

ataradov:
There is nothing to back down from. Those guys are lucky they did not get into more trouble than this.

You don't go to the store and start testing their security by shoplifting stuff. The laws exist against what they did. It is all fun and games until someone goes to jail.

bd139:
There's actually no legal consequence here because quite frankly it's not illegal to do this. 18USC1030(a)(5) and (b) as previously mentioned does not apply because the authorization of the code is implicit in the patch acceptance process and they haven't accessed any protected computers. If they introduced a law to cover this, we'd probably have to ban pull requests on github and it would open everyone up to being sued in the sector.

The whole point of my previous argument is that the kernel team's process is completely flawed and that's where the responsibility lies and they need to fess up to that rather than shitting on the researchers.

The researchers did the equivalent of driving a tank through a hole in the fence at Area 51, donning chicken suits and dancing around making clucking noises. Everyone is complaining at them rather than wondering why there is a massive hole in the fence.

The hole in the fence scares the shit out of me more than the finger pointing game.

Whether or not that is a reasonable position to be in from a software sourcing perspective i.e. "should we trust the Linux kernel" is a massive can of compliance and security worms this entire thing has opened which is now on my plate as well.

"perhaps we should use zOS instead of Linux" is looking like a good option on paper...

ataradov:

--- Quote from: bd139 on April 29, 2021, 09:04:54 pm ---The whole point of my previous argument is that the kernel team's process is completely flawed and that's where the responsibility lies and they need to fess up to that rather than shitting on the researchers.

--- End quote ---
Their model matches standard industry practices. You can do this with any other project, open, or closed.

Sure, it would be better if that was not possible. It would be better if bugs did not exist at all. But we live in a reality-based world.


--- Quote from: bd139 on April 29, 2021, 09:04:54 pm ---The researchers did the equivalent of driving a tank through a hole in the fence at Area 51, donning chicken suits and dancing around making clucking noises. Everyone is complaining at them rather than wondering why there is a massive hole in the fence.

--- End quote ---
This is criminal trespass, at least in the US. This is very much illegal whether there is a hole in the fence or a simple "NO TRESPASSING" sign and no fence at all.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod