<= Archives =>
Proper severity assignment and open process
2014/04/08 13:06:17 CEST

Silent vulnerability fixes of the Linux kernel:

The fix to the Linux kernel was published last month. Its documentation did not mention that the code patched a critical vulnerability that could jeopardize the security of organizations running Linux in highly sensitive environments. This lack of security advisories has been standard practice for years among Linus Torvalds and other developers of the Linux kernel—and has occasionally been the subject of intense criticism from some in security circles.

And from a comment on the same page:

The Linux devs have a policy of saying anything could be a security bug, so they actively downplay known security bugs, not marking them as such in most cases.

If that is true, then there is a flow in that logic: if any bug could be a security bug, then any bug should be marked as a security bug.

With OpenBSD, the kernel and the base system ship together, there is no "distribution" and users just follow -current or -stable to stay up-to-date with security-or-not fixes. Any critical correction for the -stable branch is announced on the errata page, and the source-change list is your friend.

This is not the case for the Linux kernel, because it is integrated by third-parties in distributions, therefore security vulnerabilities and fixes should be announced loud and clear, so that users can keep up with fixes. Maybe there were good reasons for a given distribution not to include a fix - then, maybe a service should be deactivated for a while or trafnered to another system. Maybe security teams are aware of the silent fix and have also pushed it silently, but what if not? For a system administrator, access to openly available information is essential.

Meanwhile there is still no information on the kernel.org breach.

Tags security