Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That's not an argument for sticking with the old programming language that apparently is impossible to use safely (if you think that you can use it safely, what makes you think that you are better than the all-star cast of C programmers that have contributed CVEs over the years?). There were better alternatives to C in the 80s, there most certainly are better alternatives to C these days. I'm so sick of the Uncle Bob school of thought that all that is needed for better software engineering is discipline. If we haven't managed to impose that discipline yet after five decades, why would we believe that it will magically appear in the future? My guess is that a programmer that had the requisite mythical discipline would gravitate to programming languages like Rust or Ada anyway, because that developer wouldn't mind tooling that helped with it.


IIUC, this is just another case where unprivileged users are now allowed to do what once was allowed only to superusers. As long as only root was allowed to add net filter rules, what did it matter if they could do bad stuff? They're root already!

Now, in places where security didn't matter, it suddenly does. Thus, it's not about bad coding habits, but inadequate care in extending privileges to untrusted users. The code should have been cleaned up first.


No it's both. There's a ton of issues like overflows in the kernel but people have prioritized looking at unpriv -> kernel or unpriv -> root, and not root -> kernel. Now many of the root -> kernel vulns are unpriv -> kernel.

The issue is still the code, it's just the impact that has changed.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: