3 ms·

That's a consequence of an "old" issue in the IT security field - security researchers and developers sit at opposite sides of the table, they've got different

That's a consequence of an "old" issue in the IT security field - security researchers and developers sit at opposite sides of the table, they've got different concerns and agendas. Pick some security researchers; now tell them to build any nontrivial piece of software; I doubt they'd be able to do it, and if they succeed their software will be full of bugs, including security ones. Security is part of the correctness and of proper building of the software, so it should be integrated into software development. Security experts can (and should) still exist, but the current state, where the infosec people appear to rule, is pointless - exactly because the same infosec people wouldn't be able to deliver better software than current developers. I highly regard somebody who can write a software without security bugs; I don't regard as highly somebody who shows me the bugs, but would be unable to write that software at all. Let's turn the infosec objective: not to undiscover security bugs, but to write software without security bugs. Then we're at the same side of the table.

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.
pjmlp 9y ago
Many developers care about security the same way as security researchers. Developers that care about design by contract, assertions, having warnings as errors, pedantic flags, get the CI system to break builds on static analyses errors, only allow for unsafe code when confirmed by profile measurements that it actually matters,.... Yet, we are able to deliver working software that fulfills project requirements, amazing!

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.

pjmlp 9y ago

Many developers care about security the same way as security researchers. Developers that care about design by contract, assertions, having warnings as errors, pedantic flags, get the CI system to break builds on static analyses errors, only allow for unsafe code when confirmed by profile measurements that it actually matters,.... Yet, we are able to deliver working software that fulfills project requirements, amazing!