| |||||||||||||
"Stable" kernel 2.6.25.7 released"Stable" kernel 2.6.25.7 releasedPosted Jun 17, 2008 1:46 UTC (Tue) by dlang (✭ supporter ✭, #313)In reply to: "Stable" kernel 2.6.25.7 released by spender Parent article: Stable kernel 2.6.25.7 released
like it or not, despite the fact that SELinux is in the kernel, most kernel folks (like most other admins) don't use it. As such the fact that root can do something nasty is not considered a critical/exploitable fix as for the one where you complain about no CVE number, is there a number allocated for this, or are you complaining becouse the person who found and fixed the problem didn't jump through whatever hoops are needed to create one first? for the one that's in Linus' tree but didn't get into -stable, did anyone send it to -stable and they rejected it, or is it one of the many patches that got upstream that the author didn't send to -stable? as for the one in vendorsec, it is disappointing that vendors are taking this long to deal with it.
(Log in to post comments)
"Stable" kernel 2.6.25.7 released Posted Jun 17, 2008 2:32 UTC (Tue) by spender (subscriber, #23067) [Link] I'm not sure when the last time you used Linux was, but SELinux is enabled by default on Fedora and RHEL (and others I'm sure, but I haven't checked). Your usage argument doesn't apply anyways, since it doesn't come into play when labeling bugs as security-related for obscure hardware which may only affect a tiny number of users (much much smaller than the number of users of SELinux). Either these bugs need to be taken seriously (and they have in the past, so I'm not sure why this one was declared a non-issue) or people need to be told that SELinux is completely worthless against preventing complete compromise as any root-based vulnerability that can totally subvert its security isn't considered a security bug and thus won't be backported to any distribution-maintained kernel. Generally when a kernel bug is identified as security-relevant, someone creates a CVE for it. The problem in this case was the committer (Al Viro) knew of the security relevance of the bug but covered it up in his changelog, which resulted in it getting covered up at the -stable level. Now tell me how any distribution is supposed to know to backport this security fix if for this 2.6.25.7 release, as with the 2.6.25.6 release with silently fixed vulnerabilities, no security implications whatsoever are mentioned? I don't know about the one that didn't make it into -stable, I was just pointing out that it belongs to the class of trivially exploitable bugs. I'm sure when it makes it into -stable (if it does), its exploitability will again be covered up. -Brad
"Stable" kernel 2.6.25.7 released Posted Jun 17, 2008 3:02 UTC (Tue) by bojan (subscriber, #14302) [Link] > Now tell me how any distribution is supposed to know to backport this security fix if for this 2.6.25.7 release, as with the 2.6.25.6 release with silently fixed vulnerabilities, no security implications whatsoever are mentioned? Excellent point. I actually asked Fedora kernel maintainers to label the latest F9 kernel as a security fix (I went with the official .5 explanation, although LWN discussion about .6 made me do it): https://admin.fedoraproject.org/updates/F9/FEDORA-2008-5308 Although I'm neither security expert nor kernel developer, that double-free in the log made me think that there could be security issues being fixed. I'm not really sure what's going on with all this, but I reckon it's always better to err on the side of caution and open CVEs etc.
"Stable" kernel 2.6.25.7 released Posted Jun 17, 2008 6:15 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link] I have been using linux as my desktop full time for the last 11 years. I am aware of the fact that RedHat chooses to enable SELinux by default, but I am also aware of the fact that many (if not most) sysadmins (as opposed to casual users) end up disabling SELinux as a fairly routine thing as they start to configure the boxes to be something other then the defaults that RedHat ships. and from various discussions on the kernel mailing list it's clear that the most of the kernel developers do as well (those that have RedHat based systems). the useage argument is that since the kernel developers don't use it, they don't have the mindset to take it into account when evaluating the severity of bugs, and therefor something that requires root access to do is not considered that bad as root can already get around the limitations (even on a RedHat system root is the account that can disable SELinux, so pretending that SELinux can protect you from rootis wishful thinking) distribution-maintained kernels will backport or not backport patches on teir own criteria, not matter what the kernel devs decide to put in a -stable kernel (and note that this patch did make it into stable, it's not that they didn't fix the problem, it's that you are complaining that the commit message didn't identify it as a security problem)
"Stable" kernel 2.6.25.7 released Posted Jun 17, 2008 7:28 UTC (Tue) by nix (subscriber, #2304) [Link] Oh, in our previous go-round he was quite clear that the problem wasn't the commit message... after spending half a dozen messages whining about nothing else. I'm still unclear what the problem actually *is*. There's meant to be some sort of huge conspiracy, perhaps focused around not doing whatever Brad says the instant he says it (it would help if he didn't say it in such a profoundly unpleasant fashion.) (And I thought I was bad at diplomacy. At least I have interaction modes besides `J'accuse' and don't try that one first. If you want to get people to do something, telling them they're all in a conspiracy and intentionally attacking the general public(?) is not the way to go.)
"Stable" kernel 2.6.25.7 released Posted Jun 17, 2008 9:32 UTC (Tue) by PaXTeam (subscriber, #24616) [Link] > Oh, in our previous go-round he was quite clear that the problem wasn't > the commit message... after spending half a dozen messages whining about > nothing else. would you stop distorting the facts? first, it was me who posted quite a few messages, not Brad, second, the problem *is* with the commit messages in that they intentionally omit important and known-to-the-developers security information. you were given several examples, not one of which you contested. it's funny how you keep running around with a huge post sign shouting conspiracy whereas noone of us said anything like that. what we did talk about was good old human dishonesty hidden in an unaccountable mailing list. as you quite rightly said in your last post on that other thread, you should not be talking to us as we can't change the situation. you should be asking questions to your kernel developers and make them accountable. unfortunately it seems it's easier to pull strawmen than actually trying to get to the bottom of this problem.
"Stable" kernel 2.6.25.7 released Posted Jun 17, 2008 13:47 UTC (Tue) by nix (subscriber, #2304) [Link] Ah, right, you were talking in such similar ways that I confused you :/ However, you're assuming that a large number of people are each acting dishonestly for no obvious gain in different places, with the strong implication of coordination (in that they have all chosen to be 'dishonest' in exactly the same way: by not mentioning things you consider a security hole in their commit logs). That's called a conspiracy theory. If you remove the assumption of dishonesty, it's simply human error, or perhaps that they have lower thresholds for defining something a security hole than you do. (It would be a miracle if this were not true, given that most of these people are not security paranoids by nature, and thus are almost bound to have lower thresholds for such things than you are!) I'm not contesting the facts: I'm contesting your unnecessarily unpleasant interpretation of them. In fact your interpretation makes no sense at all: why would people spend time coordinating to hide security holes when knowingly doing that could have no consequence other than to harm the reputation of the system they're working on? Doing that would be ridiculous. Ergo, they aren't doing that: there is no magically coordinated decision to fix security holes while hiding them by the single means of describing them differently in commit logs, no conspiracy, no bad intent. Simply differently-set thresholds.
"Stable" kernel 2.6.25.7 released Posted Jun 17, 2008 14:47 UTC (Tue) by PaXTeam (subscriber, #24616) [Link] i'm not assuming or interpreting anything, i speak of facts i have. for one, it's not a large number of people, it's the membership of secret lists which by its nature is quite limited. second, it doesn't take a lot of coordination when you're within your normal social circle anyway (the same kernel devs who interact on lkml, at conferences, real life, etc), it's normal human behaviour to stick to the flock lest you get ejected. so no, this is not a conspiracy (you've been caught again ;). speaking of facts, what do you have to say about the Paul Mackerras quote and its visible result in the commit message? what is your interpretation? why was he even raising the point of how candid he should be in the commit? > In fact your interpretation makes no sense at all: why would people > spend time coordinating to hide security holes when knowingly doing that > could have no consequence other than to harm the reputation of the > system they're working on? Doing that would be ridiculous. why would there be consequences when all of this can take place outside of the public eye, in a completely unaccountable manner? > Ergo, they aren't doing that: and you determined that by...? oh right, you didn't. why don't you go ask for the mailing list archives? that would surely answer all questions, do you agree? and if there's nothing bad to hide in there, there shouldn't be any objections to getting them.
"Stable" kernel 2.6.25.7 released Posted Jun 17, 2008 15:40 UTC (Tue) by nix (subscriber, #2304) [Link] Er, if the holes get exploited, of *course* there's a consequence. And if there's no possibility that the holes would be exploited, then modifying the commit messages to conceal the security-related nature of the commits makes no sense. You're blatantly contradicting yourself now. I've had enough of this thread.
"Stable" kernel 2.6.25.7 released Posted Jun 17, 2008 16:09 UTC (Tue) by PaXTeam (subscriber, #24616) [Link] > Er, if the holes get exploited, of *course* there's a consequence. > And if there's no possibility that the holes would be exploited, then > modifying the commit messages to conceal the security-related nature of > the commits makes no sense. i have absolutely no idea what you are talking about now. probably another of your strawmen, but just in case: you were trying to speculate why it makes no sense to downplay/hide security information in commit messages (mind you, a few posts below you argued the *opposite*, so much for contradiction ;) since that would only endanger the reputation of their work. except you forgot the little fact that such coverup took place in a secret list, hence there was no danger of exposure, on the other hand there was a perceived advantage of not getting bad PR about the many silently fixed security bugs. and now, out of the blue, you come with this commit message modification and how it makes no sense for bugs that don't have a security impact. guess what, if a bug cannot possibly be exploited then it doesn't have a security-related nature. that's a tautology and i'm not sure what you tried to say with that. incidentally, we weren't talking about bugs without security impact either. another strawman down ;). > You're blatantly contradicting yourself now. hmm, where? you're making no sense to me now, sorry. but feel free to elaborate. of course if you just wanted a cheap cop-out, let this rest.
"Stable" kernel 2.6.25.7 released Posted Jun 17, 2008 18:07 UTC (Tue) by nix (subscriber, #2304) [Link]
As I said, I'm dropping this because we're talking past each other. ('Cheap cop-out'.
Charming.)
|
|||||||||||||