| |||||||||||||
what security fix?what security fix?Posted Nov 9, 2008 13:21 UTC (Sun) by tialaramex (subscriber, #21167)In reply to: what security fix? by PaXTeam Parent article: Stable kernel 2.6.27.5
Huh?
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.
(Log in to post comments)
what security fix? Posted Nov 9, 2008 14:17 UTC (Sun) by nix (subscriber, #2304) [Link]
There is a distinction that may be worthwhile: between 'this release
certainly contains security fixes' and 'this release may contain security fixes but we don't know'. However, this distinction is already being made (if in somewhat whimsical language).
what security fix? Posted Nov 9, 2008 14:57 UTC (Sun) by PaXTeam (subscriber, #24616) [Link]
you said that you want a list of things one would do with such information (meaning the known security impact of bugs). one obvious thing one does with it is to prioritize them (meaning, backport/apply to one's own trees, be that a distro or something in-house). you said and now confirmed again that such prioritization is bogus. now you can either claim that this bogus premise has a non-bogus consequence (something i assume you wouldn't based on your seeming inclination to logical methods) or i'm left wondering, hence my question in the previous post (which in turn you can also interpret as 'why prioritization is bogus?' - if it isn't then neither is applying security fixes from which it follows that withholding what is known to be a security bug is wrong).
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?
what security fix? Posted Nov 9, 2008 16:39 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
OK, so your actual question is:
"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?
what security fix? Posted Nov 9, 2008 17:26 UTC (Sun) by PaXTeam (subscriber, #24616) [Link]
no, that's a strawman, not my question. once more: why is it bogus to prioritize known security fixes (over others)? or better, in light of your last post: why does it give anyone a false sense of security? why would anyone feel secure by applying known security fixes but not others? why would anyone believe that other fixes definitely have no security impact? why do you think the people maintaining distro and other kernels are stupid?
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.
what security fix? Posted Nov 9, 2008 18:41 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
Well now you've got lots of different questions again. I don't think there's any profit in me answering each question only for you to repeat that I'm wrong and offer yet more...
Let me suggest one thing to you: Pragmatism.
what security fix? Posted Nov 9, 2008 21:52 UTC (Sun) by ncm (subscriber, #165) [Link]
How's this for pragmatism: there are more IP protocols I don't use than protocols I do use. There are more devices I don't use than devices I do use. A bug, or a security hole, in one I don't use doesn't affect me at all. If a kernel is released to fix bugs only in protocols and drivers I don't use, there's no pragmatic reason at all for me to upgrade. Saying "you really would be better off upgrading", then, isn't just being obtuse; it's actually a falsehood.
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.
what security fix? Posted Nov 10, 2008 14:09 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
Are you /sure/ you can skip it? Do you disable SCTP in your builds? If you don't, then it may be that the bug can be tripped by a remote attacker despite the fact that you "don't use" SCTP. And that's just the first example that comes to mind.
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.
what security fix? Posted Nov 10, 2008 14:54 UTC (Mon) by PaXTeam (subscriber, #24616) [Link]
> 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.
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?
what security fix? Posted Nov 10, 2008 18:00 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
Well that rather depends on what it takes to "withhold" information.
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...
what security fix? Posted Nov 10, 2008 19:24 UTC (Mon) by PaXTeam (subscriber, #24616) [Link]
are you suggesting that kernel developers send patches on paper and integrators retype them carefully avoiding the security impact related info? impressive assumption, to say the least. because if that's not how kernel development works than your example has nothing to do with this thread's topic. as a sidenote, if you have to retype something then you don't 'have' it. you would 'have' it if you could copy-paste or attach it. incidentally, that's much more like how patches flow in kernel development. so give this one another try ;).
what security fix? Posted Nov 10, 2008 18:23 UTC (Mon) by iabervon (subscriber, #722) [Link]
Actually, I think it would be nice to have a version of the -stable patches which only updates a version number that's not in a file used by the build system. That way, you'd be able to apply the patch to your source tree and it would only rebuild anything if it affected code that you build.
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.
what security fix? Posted Nov 10, 2008 18:31 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
read the detailed list of fixes, not just the first paragraph, if you don't use anything listed, don't worry about it
what security fix? Posted Nov 9, 2008 22:15 UTC (Sun) by efexis (guest, #26355) [Link]
"Pragmatic" disproves your point! To be pragmatic one needs information to base decisions upon. Simply following "we urge you to upgrade" isn't pragmatic at all, that's faith, faith in the developers to now what's best. Now nine times out of ten that might be just fine, but the one time out of ten, where an upgrade breaks some other part of your system, can still be often enough to be problematic.
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.
what security fix? Posted Nov 10, 2008 2:01 UTC (Mon) by qg6te2 (guest, #52587) [Link]
One can go around in circles with arguments about what is a "known possible security bug" vs "bug with unknown security implications". To add to the hyperbole one could also ask what does it take to become a "security issue" (e.g. is a bug that causes a crash/lock-up but otherwise doesn't provide root access a security issue? One may shrug off a lock-up on a personal laptop, but many clients will be very annoyed with lock-ups on servers running essential services).
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 ?
what security fix? Posted Nov 10, 2008 7:21 UTC (Mon) by nix (subscriber, #2304) [Link]
My understanding was more 'once a bug has a CVE number, really annoying
embargo rules come into play, with the result that many people would rather rip off their own legs than try to get a CVE number assigned'.
what security fix? Posted Nov 10, 2008 8:12 UTC (Mon) by PaXTeam (subscriber, #24616) [Link]
asking for a CVE is independent of asking for an embargo. one does the latter out of courtesy to distros or to please the corporate bosses (say, if one's employed by one of the commercial distros), but otherwise there's nothing that would force anyone to observe any embargo. so yes, those arguments have always been bogus too.
what security fix? Posted Nov 10, 2008 16:02 UTC (Mon) by mrshiny (subscriber, #4266) [Link]
Given bug A, which appears to be a security vulnerability, and bugs B1-26 which are not known to be vulnerabilities, does it make sense to apply patch B13, which contains its own bug which renders the iwl4965 driver inoperable (again)? Or patch B25, which introduces its own security vulnerability?
Bugs can be categorized as follows:
Known vulnerability, known to be exploitable
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.
|
|||||||||||||