Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
Nobody is asking for something like this to be done. What various people have asked for is that _known_ (by developers) security issues be called as such when fixed, instead of using euphemism like "strongly encouraged to upgrade".
what security fix?
Posted Nov 9, 2008 12:36 UTC (Sun) by tialaramex (subscriber, #21167)
Posted Nov 9, 2008 13:13 UTC (Sun) by PaXTeam (subscriber, #24616)
Posted Nov 9, 2008 13:21 UTC (Sun) by tialaramex (subscriber, #21167)
Please, PaXTeam, slow down, and read things carefully before replying to them. I said that it is bogus to /prioritise/ fixing the bugs based on this arbitrary "security bug" label. Not that it is bogus to fix the bugs.
If the user wants bug fixes, this announcement makes it perfectly plain that it contains bug fixes. The question being asked is what use it would be to label /some/ of them as specifically "security bugs" and by implication, not the others.
Posted Nov 9, 2008 14:17 UTC (Sun) by nix (subscriber, #2304)
Posted Nov 9, 2008 14:57 UTC (Sun) by PaXTeam (subscriber, #24616)
now speaking of prioritization and that 'arbitrary' security label: why is it arbitrary? are you suggesting that non-security bugs are labeled as security ones (false positive issue) or that not all security bugs are labeled as such (false negative issue)? the former has no impact on one's security (just a bit of 'useless' work) and the latter assumes your bogus closed world model. so what is it you wanted to say here again?
Posted Nov 9, 2008 16:39 UTC (Sun) by tialaramex (subscriber, #21167)
"Given bug A and bugs B1-26, I think I should apply a patch for A but not for B1-26. Why is this bogus?" where:
Bug A is the subject of a long rambling Bugtraq post "Linux security is a joke" which claims that there's a serious buffer overflow and that it will "inevitably" be exploited in the wild. Linux writes and commits a two line patch, and nobody makes a working exploit, because unknown to everyone a structure alignment decision by the compiler makes the exploit condition impossible in the real world. Thus Bug A is a "security bug".
Bug B14 is 14th in a list of 26 patches fixing clearly incorrect use of an API for accessing the PCI bus. Only three people even read it, and Linus applied it because it looked similar to the other 25. But in reality it happens to fix a problem where anyone with access to play sound through an HDA compatible sound chip can also read & write arbitrary kernel memory using the right parameters to mremap(). Eventually someone will stumble on this problem and produce a POC, but not today. Thus Bug B14 is "not a security bug".
The answer is that it's bogus because it gives you (or your users) a false sense of security. You've fixed the "security bug" but actually you spent a lot of cycles on something that had no practical impact and left out the most important fix for something serious. Waiting three months for Bug B14 to "become" a security bug makes little sense, the fix is right there now. The easiest path, upgrading to stable, is in fact the best option if you don't have the cycles to do your own due diligence.
If you struggle to buy this argument, imagine that I have the set of all bug fixes, in the form of a hypothetical git branch against 2.6.27. Since my branch has no bugs, it also has no security bugs. Now, to cherry pick from my branch just fixes which you think are "security fixes" will certainly not produce a kernel which has /less/ security bugs than mine, indeed it will probably have more. Do you see?
Posted Nov 9, 2008 17:26 UTC (Sun) by PaXTeam (subscriber, #24616)
summary: your problem is, as was explained back in july or so, that you're living in a black&white world (pretty ironic from someone who called the closed world model bogus ;). real life ain't anything like that. in real life people manage risks and often take them - it's not up to you or anyone else to make that call for them.
last but not least: you can't have that hypothetical git branch because that's only possible in a closed world model which according to you is bogus. nor can you have assurance that your supposed fixes don't introduce more problems which is what actually happens in real life at times (witness the frequent reverts). so no, i still don't see what you're trying to say but i'm beginning to feel that i'm up against an armchair security expert turned kernel programmer with no real life experience in either matter and i've seen that where that leads.
Posted Nov 9, 2008 18:41 UTC (Sun) by tialaramex (subscriber, #21167)
Let me suggest one thing to you: Pragmatism.
Posted Nov 9, 2008 21:52 UTC (Sun) by ncm (subscriber, #165)
A useful remark would be "this fixes a bug in SCTP", which means I can skip it, and be the better off for skipping it if I don't run any programs that use SCTP.
Posted Nov 10, 2008 14:09 UTC (Mon) by tialaramex (subscriber, #21167)
It would be relatively easy to carve out patches that only touch code in a specific area of the tree (for example, the SCTP implementation). But the recent e1000e bug illustrates beautifully that bugs aren't very good at respecting modularisation of design, since they're not designed but are instead unintentional.
If you do want to try this, as I said, it's fairly possible, Git makes it very practical for you to knock together a script that lists only those patches which touch your subset of the kernel, assuming you have the technical knowledge to understand how the kernel is laid out, and you have a complete list of the components you do or don't use, plus the time to examine architectural changes that might alter that list.
One thing that's going on is that there are many different constituencies who think that the kernel developers ought to make /their/ lives easier by doing just a minute or two's extra work. Since the kernel developers are a very precious resource I suggest that wherever possible you should look for ways to make things better without asking the developers to do more paperwork for you.
Posted Nov 10, 2008 14:54 UTC (Mon) by PaXTeam (subscriber, #24616)
huh? are you sure you understood the discussion at all? since when is withholding information *less* work than simply passing along what they already have?
Posted Nov 10, 2008 18:00 UTC (Mon) by tialaramex (subscriber, #21167)
I have a copy of the novel "A Fire Upon the Deep" here but those tired of this increasingly long thread will be glad to know that it was perfectly simple to "withhold" the contents of the novel from this message, I simply didn't choose to manually retype the entire thing into this little text box, saving myself hours of work.
On the other hand, this post will automatically identify me as the poster. To create another account in order to disguise my true identity would be a considerable amount of work just to withhold some information...
Posted Nov 10, 2008 19:24 UTC (Mon) by PaXTeam (subscriber, #24616)
Posted Nov 10, 2008 18:23 UTC (Mon) by iabervon (subscriber, #722)
Then everybody would want to apply the patch, since either it would provide a benefit (either stability or security) or it would not require any downtime to apply. For that matter, it would be nice to have a make target that wouldn't recopy modules that hadn't changed, and an lsmod flag to show modules which are different on disk from what's loaded.
Posted Nov 10, 2008 18:31 UTC (Mon) by dlang (✭ supporter ✭, #313)
Posted Nov 9, 2008 22:15 UTC (Sun) by efexis (guest, #26355)
If there are known security issues, I need to know, because I need to protect my servers and my clients, either by applying the fix, or by creating a seperation between the bug and potential triggers of it. If not, if it's say, timing tweaks to the schedulars to undo a regression, I need to make sure that it applies to me. If the regression hasn't affected my workloads, changes to the schedular could, and I wouldn't want to apply it without some stress testing during a planned upgrade time (we lost *loads* during early 2.6.2x kernels as IO would grind to a halt under certain loads as each of the cores just seemed to be blocking... the problem went away dropping back to the maintained 2.6.16 series, and post 2.6.25 seems okay, but boy did it cost us and did we learn our lesson).
Note that this isn't a complaint, I play about with risky experimental code because I enjoy the new stuff. If I thought they were crap, I wouldn't be using their kernel.
Posted Nov 10, 2008 2:01 UTC (Mon) by qg6te2 (guest, #52587)
Personally I'd like to know whether a kernel upgrade fixes a "known possible security bug", where the bug can be triggered by a deliberate and remote attack. However, one can also suspect that a reason for the rather obfuscated security warnings by Greg KH et al (i.e. "strongly encouraged to upgrade") is not the definition of a security issue, but the politics of the Linux Foundation. Once a bug has a CVE number, the count of security issues in Linux goes up. Obviously it's very useful for marketing reasons if the number of security issues in Linux is lower than other systems. Hence why add to the count of security bugs (even though they may lack CVEs), through kernel update disclosures ?
Posted Nov 10, 2008 7:21 UTC (Mon) by nix (subscriber, #2304)
Posted Nov 10, 2008 8:12 UTC (Mon) by PaXTeam (subscriber, #24616)
Posted Nov 10, 2008 16:02 UTC (Mon) by mrshiny (subscriber, #4266)
Bugs can be categorized as follows:
Known vulnerability, known to be exploitable
Known vulnerability, assumed to be exploitable (may not be)
Not known to be a security flaw, but it is one
Not known to be a security flaw, and it isn't one
Known to not be a security flaw
Now obviously we'd like to have patches for all of the first three classes, but we can't include the third because they're unknown. But clearly getting the KNOWN problems solved is better than nothing? And from a risk management perspective, fewer changes is better. Believe me, if I could just upgrade the parts of the kernel which required security fixes, I would. The last year I've had nothing but pain when upgrading my kernel and minimizing the changes makes sense. Thankfully I don't have to maintain a bunch of servers, just my one laptop. I'd hate to deploy a security fix to my enterprise and find that my entire workforce's wifi cards stopped working, making it extremely difficult for them to go back to a working kernel.
Posted Nov 9, 2008 21:04 UTC (Sun) by bojan (subscriber, #14302)
Posted Nov 9, 2008 21:44 UTC (Sun) by bojan (subscriber, #14302)
I noticed an intermittent grinding sound coming out of my car's steering. Although the mechanic said that it probably wasn't dangerous and they couldn't replicate the problem when I brought the car to service, I insisted the car stays with them. On the second day, they called me and told me they replicated the problem and that they will be replacing the whole steering mechanism. I picked my car up on the third day, so I was willing to be without the car for almost three days to get this fixed, because I didn't want to risk the lives of my kids over it.
I also have a broken air conditioning vent coming out in front of the back seat. I didn't even remember to mention it to the mechanics.
I know you'll now ask "how is this relevant to the kernel". Gee, I don't know...
Posted Nov 9, 2008 23:00 UTC (Sun) by nix (subscriber, #2304)
Posted Nov 9, 2008 23:22 UTC (Sun) by bojan (subscriber, #14302)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds