Kernel space: Full disclosure for security holes

Linux developers fix kernel security holes out in the open. Is a bug a bug, or do security-related fixes deserve special treatment?

By Jonathan Corbet , LinuxWorld.com, 07/22/08

 Start a discussion    Print article

 Comments (1)    Print article

Even the most casual observer of the linux-kernel mailing must have noticed that, in the shadow of the firmware flame war, there is also a heated discussion over the management of security issues. There have also been some attempts to turn this local battle into a multi-list, regional conflict. Finding the right way to deal with security problems is difficult for any project, and the kernel is no exception. Whether this discussion will lead to any changes remains to be seen, but it does at least provide a clear view of where the disagreements are.

Things flared up this time in response to the 2.6.25.10 stable kernel update. The announcement stated that "any users of the 2.6.25 kernel series are STRONGLY encouraged to upgrade to this release," but did not say why; none of the patches found in this release were marked as security problems. As it happens, there were security-related fixes in that update; some users are upset that they were not explicitly called out as such. They have reached the point of accusing the kernel developers of hiding security problems.

These problems, it is said, are fixed with relatively benign-sounding commit messages ("x86_64 ptrace: fix sys32_ptrace task_struct leak," for example) and users are not told that a security fix has been made. This, in turn, is thought to put users at risk because (1) they do not know when they need to apply an update, and (2) there is no clear picture of how many security problems are surfacing in the kernel code. So, as "pageexec" (or "PaX Team") put it:

 

the problem i raised was that there's one declared policy in Documentation/SecurityBugs (full disclosure) yet actual actions are completely different and now Linus even admitted it. the problem arising from such inconsistency is that people relying on the declared disclosure policy will make bad decisions and potentially endanger their users. there're two ways out of this sitution: either follow full disclosure in practice or let the world at large know that you (well, Linus) don't want to. in either case people will adjust their security bug handling processes and everyone will be better off.

There are two aspects to the charge that the kernel is not following a full disclosure policy: commit messages are said to obscure security fixes, and kernel releases do not highlight the fact that security problems have been fixed. There is an aspect of truth to the first charge, in that Linus will freely admit to changing commit logs which discuss security problems too explicitly:

Featured Whitepapers

The Trend from UNIX to Linux in SAP(r) Data Centers

LinuxCast Listen to the latest Linux news.

About Us | Contact Us | Advertising Info | Terms of Service/Privacy

Copyright, 2006-2007 Network World, Inc. All rights reserved.