Personally, I'm not too fond of the concept of keeping fixed security vulnerabilities obfuscated in the kernel changelogs. But it's probably due to me being the de facto maintainer of the Kernel Vulns thread. I mean, there have been several times when a new stable kernel is released and upon reading the changelog I'm not able to determine whether any of the fixes are for security issues. Most of the time there's a CVE ID included along those that are, which makes things nice and simple. But sometimes there is not even a mention of any security implications and I wouldn't ever know that a vulnerability is being fixed if it wasn't for the fact that I monitor third-party security sites. As an example, take the last two vulns I posted.

So anyway, I ran into this message today (you'll need to click that link in order to get where this post is coming from) and I was wondering where you guys stand on the issue. Like I said, I'm not too fond of the "security-through-coverup policy", but I can't really say that I'm 100% against it either. I've read what Linus Torvalds said on the matter (and I think of him as an extremely sane person), and his point about not making non-public vulnerabilities "greppable" does make sense IMHO.

So what do you think? Where do you draw the line? Perhaps you think there shouldn't be any line in the first place?

I'd love to get your thoughts on this.

Without having read everything, all the heated posts on forums/boards I've read of late about this seem to miss the fact that you can still compare a version with a previous version to find changes, you can get a list of patches which make that even easier, you can maintain a list ELSEWHERE in DETAIL of changes and what the point of them were.

Beyond that, I really have no interest in following any of the coverage of this public drama incident. Everyone needs to stop manipulating quotes for propaganda and address the issue at hand: Migrating detailed descriptions of vulnerabilities fixed to a different forum to avoid simple automated queries by people looking to exploit unpatched systems and helping vendors/distributors to push fixes to their installed base.

Linus has a rough approach at dealing with some issues, but his intentions have virtue. People shouldn't be so hasty to condemn him at every chance and should rather work to find a mutual solution.

In summary, from what I've quickly taken in, I agree that he has good motive, but I believe his words are being manipulated. Discussion would be better suited to finding a solution to the problem he is trying to avoid.

EDIT: just read your sig, I think that well applies here ;x

All software is buggy. A major part of maintaining software is fixing the flood of bugs coming in on bug reports. Now some bugs are potential security problems. Some programmer might be able to exploit a given bug to break security. But a potential cracker has to wade through thousands of bug reports to try to find one that he might be able to exploit. The fact that a given bug can be exploited for a security breach is rarely obvious and such a bug usually requires a fair bit of thought and perhaps experimentation before it can be proved useful for a security breach.

The same process holds true for the white hats. They spend a lot of time sifting through bugs to find one that can be used for a security exploit and then report the potential problem. When the bug becomes a security bug then its priority is raised regardless of the quality of the white hat's opinion on the severity of the bug.

I think that the white hat efforts would be better spent in just fixing bugs. The fixed bug queue would move faster. Also when the white hats post their findings on the bug report it makes the cracker's problem much easier. He can focus on the small subset of bugs that the white hats have reported as being potential security problems.

So I see nothing wrong with not flagging bugs as potential security problems unless somebody has actually written malicious code based on the bug.

--------------------
Steve Stites

It could be that someone found a bug and fixed it and didn't even know it was a reported security vulnerability. Personally, if I were fixing code and found an out-by-one problem (which could be a huge problem), I'd simply fix it. I wouldn't see any point in making a comment other than "fixed an off-by-one in variable blah". Unless I was specifically tracking a particular reported bug I wouldn't even post a "fixes bug #X" or "fixes CVE #Z".

So I don't think that there is any malice or laziness at all in some fixes not being tagged as related to security.

The one thing I must note about your post, is that the point of controversy that actually was discussed and has been quote manipulated to sound like what you described, is this: Linus doesn't want to make it extremely obvious of a FIXED problem that was already declared a vulnerability, hence avoiding people from instantly seeing what changes protected what, reversing the process to determine entry point, and exploiting that of unpatched systems.

I'm just pointing out that the controversy is being made to sound like what you described when the issue is actually making an already declared vulnerability obvious while systems downstream wait for the kernel to make its way through the distribution change.

I used to hold some advanced government security clearances. I did some very sensitive work for the military and for other organizations within the government.

As part of all of this, I periodically had to attend security briefings. I was informed of the latest attempts to breach security, and I was told repeatedly to "tell no one what you are doing. Don't talk to your wife about it. Don't talk to your girlfriend about it. Don't talk to your friends. Tell nothing. The most innocuous seeming remark can be the thin edge of the wedge that results in a major compromise.

So, I have to say that security through obfuscation is a valid step. It is the first step. Not the most effective, and not the only step, but certainly a first step.

I have no problem with not reporting the bugs as security-related if (a) they are fixed and (b) they weren't already public due to some high-profile exploit. Why give any information to the black hats? Let them put the whole thing together on their own, without any assistance at all.

Do I see Linus' point about not labelling fixes? Yes. Reality is that Linux is not a commercial enterprise but "just a hobby". So it doesn't even matter if others would call what's been done "obscuring". Plus labelling isn't "important" because it does not affect code quality as far as I know. Linus is the lead developer, it's his "toy" and if he doesn't care beyond playing with it who is gonna make him. I might not agree but I can understand that.


Does the absence of knowing any security-related fixes are included bother me? Yes. What I don't understand is users not having a problem with knowing if something fixes a security problem or not. Does that mean you accept any loss of data, any breach of security, any loss of trust as a result of flaws in the kernel? Or does that mean you don't care because you read kernel code and sync daily with -new anyway? Or does that mean you're willing to rely on others like kernel developers, distribution vendors or others (with maybe incomparable motives)?..

Yeah, I see it sort of the same way. I've heard people talk about this and compare it to when Microsoft issues updates and doesn't say that they fix security vulnerabilities. The problem with those people's comparisons is that Microsoft doesn't release the source code, which makes it a completely different situation IMHO. I mean, even if Linus would NEVER mention anything about security fixes being included in -stable patches, he is providing the source code for anyone to look at and make their own conclusions. So there isn't any secrecy about it, at least not technically. No matter how much he obscures the changelogs, he isn't hiding things from us - just making it difficult for people like me (who can't read C) to get the whole scoop about what a patch is doing.

Yeah, I think it's okay if one relies on a powerful commercial vendor (like, say, Red Hat) to analyze the patches and make the determination about whether they should be pushed downstream or not. Of course, it sucks for smaller distros, such as Slackware (for example), who don't have the money for a full-blown kernel development team.

As a side note, the 2.6.26.1 release had a patch for a security vulnerability in it, without any CVE ID being issued. Yet, if one would grep the changelog for "buffer overflow" one would have spotted it. So I'm not sure if Linus is really making an effort to make these things non-grepable or not. I'll say this much: I would be perfectly okay if every single security vulnerability addressed in a -stable patch would include a CVE ID. I think we gain more from being straight-up with everyone than from keeping things on the DL.

Of course relying on Big Corp is what one pays for (I hope) in terms of quality and efficiency. Maybe the bottomline question is: Who do you trust? Or put differently: should anyone (be expected to) have that knowledge to determine what's up or instead have access to easy methods of determining (like CVE markers) the upcoming release is a security fix?


I think it's bad news for anyone that doesn't follow their OS Security Officers bulletins or basic security news...