Their view that security bugs are just normal bugs remains very immature and damaging. It it somewhat mitigated by Linux having so many eyes on it and so many developers, but a lot of problems in the past could have bee avoided if they adopted the stance the rest of the industry recognizes as correct.
Classifying bugs as security bugs is just theater - and any company or organization that tries to classify bugs that way is immature and hasn't put any thought into it.
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.
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,
Linus has been very clear on avoiding the opposite, which is the OpenBSD situation: they obsess about security so much that nothing else matters to them, which is how you end up with a mature 30 year old OS that still has a dogshit unreliable filesystem in 2026.
To paraphrase LT, security bugs are important, but so are all the other bugs.
The rest of the industry relies on following a CVE list and ticking off vulnerabilities as a way to ensure "owners" are correctly assigned risk and sign it off - because there is nothing else that "owners" could do. The whole security through CVE is broken and is designed to be useful to create large "security organizations" that have the single purpose of annoying everyone with reports without solving any issues.
Sometimes I dream about a 100% secure OS. Maybe formal verification is the key, or Rust, I don’t know. But I would love to know that I can't be hacked.
> If you are forced to use encryption to report security problems, please reconsider this policy as it feels counterproductive (UK government, this means you…)
I think the most practical reason not to flag which bugs are security bugs is to avoid helping blackhat hackers by painting a giant neon sign and that should be more than enough.
I think all the other explanations are just double-think. Why? If "bugs are just bugs" is really a true sentiment, why is there a separate disclosure process for security bugs? What does it even mean to classify a bug as a security bug during reporting if it's no different than any other bug report? Why are fixes developed in secret & potential embargoes sometimes invoked? I guess some bugs are more equal than others?
Recently, things have been advancing which may finally allow a seamless virtualization experience on the Linux desktop (and match QubesOS in some security aspects).
GPU drivers supporting native contexts with Mesa support.
Wayland sharing between guest and host. It used to be somewhat sloppy (involved protocol parsing; sommilier & wayland-proxy-virtwl) but recently someone undertook a project to do it properly that may soon bear fruit: https://codeberg.org/drakulix/wl-cross-domain-proxy
I wonder if it would be possible to live-migrate apps from one machine running munix to another. You could pause, transfer, and resume the virtual machine.
There's a massive difference between "DoS requiring root" and "I can own you from an unprivileged user with one system call". You can say "but that DoS could have been a privesc! We don't know!" but no one is arguing otherwise? The point is that we do know the impact of some bugs is strictly a superset of other bugs, and when those bugs give control or allow a violation of a defined security boundary, those are security bugs.
This has all been explained to Greg for decades, nothing will change so it's just best to accept the state - I'm glad it's been documented clearly.
Know this - your kernel is not patched unless you run the absolute latest version. CVEs are discouraged, vuln fixes are obfuscated, and you should operate under that knowledge.
Attackers know how to watch the commit log for these hidden fixes btw, it's not that hard.
edit: Years later and I'm still rate limited so I can't reply. @dang can this be fixed? I was rate limited for posting about Go like... years ago.
To the person who replies to me:
> This is correct for a lot of different software, probably most of it. Why is this a point that needs to be made?
That's not true at all. You can know if you're patched for any software that discloses vulnerabilities by checking if your release is up to date. That is not true of Linux, by policy, hence this entire post by Greg and the talks he's given about suggesting you run rolling releases.
Sorry but it's too annoying to reply further with this rate limiting, so I'll be unable to defend my points.
21 comments
[ 0.18 ms ] story [ 59.3 ms ] threadFirst 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.
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.
Such as?
To paraphrase LT, security bugs are important, but so are all the other bugs.
LOL
I think all the other explanations are just double-think. Why? If "bugs are just bugs" is really a true sentiment, why is there a separate disclosure process for security bugs? What does it even mean to classify a bug as a security bug during reporting if it's no different than any other bug report? Why are fixes developed in secret & potential embargoes sometimes invoked? I guess some bugs are more equal than others?
There must be a way to ship a docker image without a kernel, since it doesn’t get used for anything anyway.
GPU drivers supporting native contexts with Mesa support.
Wayland sharing between guest and host. It used to be somewhat sloppy (involved protocol parsing; sommilier & wayland-proxy-virtwl) but recently someone undertook a project to do it properly that may soon bear fruit: https://codeberg.org/drakulix/wl-cross-domain-proxy
A VMM to utilize these features: https://github.com/AsahiLinux/muvm
And a solution which ties these things together: https://git.clan.lol/clan/munix
I wonder if it would be possible to live-migrate apps from one machine running munix to another. You could pause, transfer, and resume the virtual machine.
There's a massive difference between "DoS requiring root" and "I can own you from an unprivileged user with one system call". You can say "but that DoS could have been a privesc! We don't know!" but no one is arguing otherwise? The point is that we do know the impact of some bugs is strictly a superset of other bugs, and when those bugs give control or allow a violation of a defined security boundary, those are security bugs.
This has all been explained to Greg for decades, nothing will change so it's just best to accept the state - I'm glad it's been documented clearly.
Know this - your kernel is not patched unless you run the absolute latest version. CVEs are discouraged, vuln fixes are obfuscated, and you should operate under that knowledge.
Attackers know how to watch the commit log for these hidden fixes btw, it's not that hard.
edit: Years later and I'm still rate limited so I can't reply. @dang can this be fixed? I was rate limited for posting about Go like... years ago.
To the person who replies to me:
> This is correct for a lot of different software, probably most of it. Why is this a point that needs to be made?
That's not true at all. You can know if you're patched for any software that discloses vulnerabilities by checking if your release is up to date. That is not true of Linux, by policy, hence this entire post by Greg and the talks he's given about suggesting you run rolling releases.
Sorry but it's too annoying to reply further with this rate limiting, so I'll be unable to defend my points.