Posted by chmaynard 4 days ago
There must be a way to ship a docker image without a kernel, since it doesn’t get used for anything anyway.
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.
QED.
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.
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.
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.
First of all "security" is undefined. Second, nearly every bug can be be exploited in a malicious way, but that way is usually not easy to find. So should every bug be classified as a security bug?
Or should only bugs where a person can think of a way on the spot during triage to exploit that bug as a security bug? In that case only a small subset of your "security" bugs are classified as such.
It is meaningless in all cases.
Even the line between "this is a bug" and "this is just a missing, incomplete, or poorly thought out feature" can get a bit blurry. At a certain point, many engineers get frustrated trying to pick apart the difference between all these ways of classifying the code they are writing and just want to get on with making the system work better.
No it isn't. Security boundaries exist and are explicit. It isn't undefined at all. Going from user X to user Y without permission to do so is an explicit vulnerability.
The kernel has permissions boundaries. They are explicit. It is defined.
> Second, nearly every bug can be be exploited in a malicious way,
No they can't.
Security is not a dirty word, Blackadder.
Nonsense.
To paraphrase LT, security bugs are important, but so are all the other bugs.
> To paraphrase LT, security bugs are important, but so are all the other bugs.
Right, this is wrong, and that's the problem. Security bugs as a class are always going to be more important than certain other classes of bugs.
This can be looked upon when compiling the linux kernel, the mitigation options are rather numerous - and you'll have to also pick a sleep time ; what i'm saying is - currently linux only allows you to tune a machine to a specific requirement - it's not a spaceship on which you can change the sleep time frequency; dynamically shutdown mitigation ; and imagine that you are performing - In the same spirit, if you are holding keys on anything else than open-bsd ; I hope for you that you have properly looked up what you were installing.
I think the OpenBSD approach of secure coding is outdated. The goal should have always been to take human error out of the equation as much as possible. Rust and other modern memory safe languages move things in that direction, you don’t need ultra strict coding standards and a bible of compiler flags.
I don't think it's outdated it's a core part of the puzzle. The problem with their approach is they rely on it 100%, and have not enough in place (and yes, I'm aware of all the mitigations they do have) to protect against bugs they miss. This is a lot less true now than it was 15 - 20 years ago, but it's still not great IMO.
Such as?