3 ms·

That's not a fair (or useful) assessment. Obviously, the narrow-minded security people you describe exist, but they're a minority. Many security people are deve

by lima 9y ago

That's not a fair (or useful) assessment. Obviously, the narrow-minded security people you describe exist, but they're a minority. Many security people are developers who specialized in security, and are very much capable of building software. The kernel code is question is exactly what you ask for - instead of finding and fixing single bugs, it's a mitigation that prevents all occurrences of a particular class of bugs.

alanfranzoni 9y ago
Of course it's "anecdata" because I've never personally conducted a test of all security consultants for their programming skills. But the people you tell about (developers who specialized in security) maybe exist in large shops (Google, MS, FB), but many, many security consultants will work for specialized firms that offer security services, but not software development, and vice versa. Take a look at most Defcon/BlackHat talks where a vuln is explained/uncovered/exploited: most such researchers don't pertain to a software development firm, but to independent security firms. Why should my assessment not be useful? I proposed a very clear solution to what is the problem. Source: I worked for almost ~10 years in a firm who had both a software development and a security services branch, met tens of security consultants and worked in remediation activities for software issues where the security consultants weren't able to do it. EDIT: about the kernel code, I agree with you that such code is a step in the right direction, but I agree with Linus that the "warn" should come before the "kill".
watwut 9y ago
When I was looking to learn about how to systematically make secure software, I did not found all that great actionable information. There is a lot about particular hacks and vulnerabilities, lists of popular vulnerabilities categories etc. There are was one book dealing with architecture and such I found. Development quite clearly is not focus of security research. A lot of advice, especially that found on blogs, was literally naive and felt like something written by someone who never even seen larger team working.
- lima 9y ago
  There are many good books on security architecture. The technical details change every week, but the fundamental approach does not change. "Security Engineering" by Ross Anderson is a must-read: https://www.cl.cam.ac.uk/~rja14/book.html https://www.cl.cam.ac.uk/~rja14/book.html (it's freely available, too)
- extrapickles 9y ago
  As a infosec guy who was a software developer, its non-trivial to write actionable general security advice. There is an entire academic field of study on making network related security blunders hard (lang-sec). It generally boils down to do all your parsing in one spot and a small set of features are evil. What is really needed is a site where one can pick a bunch of features that your software project has/wants and then it gives semi-tailored advice on what to do, what to watch out for, or that you need to rethink things (eg: rolling your own TLS implementation=world of hurt).
PeterisP 9y ago
The mitigation does not prevent a particular class of bugs, it prevents a particular class from being exploitable by turning an invisible-but-possibly-exploitable bug to a crash bug. The bug is still there, but now it has a larger impact on most customers. That's a serious tradeoff, especially (as Linus is complaining) turning a rare bug into a crashbug doesn't allow you to detect and fix it, you need a mode where the bug is logged but the process is not stopped (and might be exploited) so that the bug can be reported, reproduced and fixed.

by lima 9y ago

alanfranzoni 9y ago

Of course it's "anecdata" because I've never personally conducted a test of all security consultants for their programming skills. But the people you tell about (developers who specialized in security) maybe exist in large shops (Google, MS, FB), but many, many security consultants will work for specialized firms that offer security services, but not software development, and vice versa. Take a look at most Defcon/BlackHat talks where a vuln is explained/uncovered/exploited: most such researchers don't pertain to a software development firm, but to independent security firms. Why should my assessment not be useful? I proposed a very clear solution to what is the problem. Source: I worked for almost ~10 years in a firm who had both a software development and a security services branch, met tens of security consultants and worked in remediation activities for software issues where the security consultants weren't able to do it. EDIT: about the kernel code, I agree with you that such code is a step in the right direction, but I agree with Linus that the "warn" should come before the "kill".

watwut 9y ago

When I was looking to learn about how to systematically make secure software, I did not found all that great actionable information. There is a lot about particular hacks and vulnerabilities, lists of popular vulnerabilities categories etc. There are was one book dealing with architecture and such I found. Development quite clearly is not focus of security research. A lot of advice, especially that found on blogs, was literally naive and felt like something written by someone who never even seen larger team working.

lima 9y ago
There are many good books on security architecture. The technical details change every week, but the fundamental approach does not change. "Security Engineering" by Ross Anderson is a must-read: https://www.cl.cam.ac.uk/~rja14/book.html https://www.cl.cam.ac.uk/~rja14/book.html (it's freely available, too)
extrapickles 9y ago
As a infosec guy who was a software developer, its non-trivial to write actionable general security advice. There is an entire academic field of study on making network related security blunders hard (lang-sec). It generally boils down to do all your parsing in one spot and a small set of features are evil. What is really needed is a site where one can pick a bunch of features that your software project has/wants and then it gives semi-tailored advice on what to do, what to watch out for, or that you need to rethink things (eg: rolling your own TLS implementation=world of hurt).

PeterisP 9y ago

The mitigation does not prevent a particular class of bugs, it prevents a particular class from being exploitable by turning an invisible-but-possibly-exploitable bug to a crash bug. The bug is still there, but now it has a larger impact on most customers. That's a serious tradeoff, especially (as Linus is complaining) turning a rare bug into a crashbug doesn't allow you to detect and fix it, you need a mode where the bug is logged but the process is not stopped (and might be exploited) so that the bug can be reported, reproduced and fixed.