Comment by tptacek
5 days ago
From their perspective, on their project, with the constraints they operate under, bugs are just bugs. You're free to operationalize some other taxonomy of bugs in your organization; I certainly wouldn't run with "bugs are just bugs" in mine (security bugs are distinctive in that they're paired implicitly with adversaries).
To complicate matters further, it's not as if you could rely on any more "sophisticated" taxonomy from the Linux kernel team, because they're not the originators of most Linux kernel security findings, and not all the actual originators are benevolent.
For sure, but you don't need to file CVEs for every regular bug.
In the context of the kernel, it’s hard to say when that’s true. It’s very easy to fix some bug that resulted in a kernel crash without considering that it could possibly be part of some complex exploit chain. Basically any bug could be considered a security bug.
plainly, crash = DoS = security issue = CVE.
QED.
9 replies →
> From their perspective, on their project, with the constraints they operate under, bugs are just bugs.
That's a pretty poor justification. Their perspective is wrong, and their constraints don't prevent them from treating security bugs differently as they should.
> almost any bugfix at the level of an operating system kernel can be a “security issue” given the issues involved (memory leaks, denial of service, information leaks, etc.)
On the level of the Linux kernel, this does seem convincing. There is no shared user space on Linux where you know how each component will react/recover in the face of unexpected kernel behaviour, and no SKUs targeting specific use cases in which e.g. a denial of service might be a worse issue than on desktop.
I guess CVEs provide some of this classification, but they seem to cause drama amongst kernel people.
You have a pretty strongly worded stance, but you don't provide an argument for it. May I suggest you detail why exactly you think their perspective is wrong, apart from "a lot of problems in the past could have been avoided"?
My view here isn't uncommon, even if it's a minority view. I've noticed a lot of people tend to just defend and adopt the stances of projects they like or use without necessarily thinking things through, and I assume that's at least partly the case here.
There's been a lot of criticism written on the kernel devs stance over the last, what, 20 years? One obvious problem is that without giving security bugs, i.e. vulnerabilities priority, systems stay vulnerable until the bug gets patched at whatever place in the queue it happens to be at.