Kernel.org's road to recovery

Posted Oct 8, 2011 12:26 UTC (Sat) by nix (subscriber, #2304)
In reply to: Kernel.org's road to recovery by malor
Parent article: Kernel.org's road to recovery

And, of course, imputations of bad faith and lying are *really likely* to make people trust you and want to work with you.

This is why PaXTeam's excellent technical nous goes largely wasted into out-of-tree stuff that is relatively little used[1]: when he tries to interact with other people, the moment any criticism of any kind is levelled -- which takes about six seconds on a list as hardboiled as the kernel list -- out come the vituperative personal attacks, conspiracy theories, and imputations of malice -- and of course he is never wrong either, no matter what evidence is presented. We've seen it virtually every time PaXTeam tries to participate in conversations on the kernel list, such that now I suspect most kernel devs have him killfiled. Nobody wants to work with someone like that: it's unpleasant even to read it. A Cassandra imprisoned by his own acid tongue. It's a great shame.

I expect further personal attacks in response to this comment, even though it's complimentary in part, but I don't care. He can't help it.

[1] yes, people do use grsec. But consider how much more widely used these fixes would be if more of them got into Fedora (the fixes ones that have an acceptable cost/benefit tradeoff, of course, I know that some have been rejected on those grounds, which is inevitable.

Kernel.org's road to recovery

Posted Oct 8, 2011 19:55 UTC (Sat) by malor (guest, #2973) [Link] (1 responses)

Well, for what it's worth, the 'lying' thing comes from me, not from PaXTeam, and I stand behind that assertion 100%. Whether or not anyone happens to like that description, it is accurate. Information is being deliberately suppressed, to the benefit of the people doing the suppressing, and the detriment of the people the information is being hidden from.

I don't see that any other word really suffices, in that context.

The rest of all the foofoorah, I know nothing about. My only contact with kernel devs is via these comments on LWN. I'm not affiliated with any particular camp. I just want to be told the whole truth, so I can make my own decisions, instead of having my agency taken from me. I'm not asking for any extra work, just that known security issues be revealed.

Indirectly, of course, my hope is that the quality of the kernel will improve, because if just how many security holes are coming out of that team becomes easily visible to the world, I think the pressure will ramp up to stop adding new features, and fix the old ones instead. And I think that's exactly what the kernel devs don't want to do.

Kernel.org's road to recovery

Posted Oct 8, 2011 21:48 UTC (Sat) by mpr22 (subscriber, #60784) [Link]

There are a number of words or phrases, at varying places along the sliding scale of euphemism vs. dysphemism, for describing deliberate concealment of true information, but the unqualified term "lying" is not one I regard as well-used for such, being better reserved for the knowing and deliberate emanation of false information. "Lying by omission" is adequate, if you are absolutely insistent that the word "lying" must be used.

Kernel.org's road to recovery

Posted Oct 8, 2011 20:01 UTC (Sat) by malor (guest, #2973) [Link] (9 responses)

And from a slightly different angle: if honesty about what developers are doing is a big controversial issue, then I would argue that the fundamental development process is extraordinarily broken.

Kernel.org's road to recovery

Posted Oct 9, 2011 14:47 UTC (Sun) by vonbrand (subscriber, #4458) [Link] (8 responses)

If Linux development is so completely broken, I do wonder why you even bother...

Kernel.org's road to recovery

Posted Oct 10, 2011 0:22 UTC (Mon) by malor (guest, #2973) [Link] (7 responses)

Because of habit, mostly. I am definitely coming to realize that the Linux development process does not produce trustworthy code, and further that the devs aren't really interested in security. They deride it as theater and want it to go away, while the security features in their kernel become less and less useful over time. At this point, getting user shell access on a Linux box is damn near equivalent to getting root.

Which means, of course, you get hacks like this one, and then a butchering of functionality because shell access can't be safely shared on a Linux machine.

There's going to be more compromises. Lots more.

Kernel.org's road to recovery

Posted Oct 10, 2011 0:39 UTC (Mon) by vonbrand (subscriber, #4458) [Link] (6 responses)

Any examples handy? They would make a great point... and they must be aplenty, if we are to believe your allegations.

Kernel.org's road to recovery

Posted Oct 10, 2011 1:19 UTC (Mon) by malor (guest, #2973) [Link] (5 responses)

Wow, you walked into that one.

https://lwn.net/Articles/460559/

Kernel.org's road to recovery

Posted Oct 10, 2011 2:28 UTC (Mon) by vonbrand (subscriber, #4458) [Link] (4 responses)

Sorry I wasn't clear. You claimed currently having shell access is equivalent to root. That I'd like to see the boatload of handy examples you've got to back this up. They would make a great point for your assertion that Linux' development is broken, and give hackers a great incentive to fix vulnerabilities and thighten up their coding.

Kernel.org's road to recovery

Posted Oct 10, 2011 22:41 UTC (Mon) by malor (guest, #2973) [Link] (2 responses)

Try the security alert from five days ago:

From RedHat errata:

* Flaws in the AGPGART driver implementation when handling certain IOCTL commands could allow a local user to cause a denial of service or escalate their privileges. (CVE-2011-1745, CVE-2011-2022, Important)
* An integer overflow flaw in agp_allocate_memory() could allow a local user to cause a denial of service or escalate their privileges (CVE-2011-1746, Important)

Bunch of other stuff too, but there's two likely local root exploits from October 5. Took me about ten minutes to spot, and that's only because I had to look through some lesser CVEs LWN posted about twenty minutes ago.

It would have proved the point even more thoroughly to have gotten a local root exploit today, but five days ago, I think, is adequate.

Kernel.org's road to recovery

Posted Oct 11, 2011 0:09 UTC (Tue) by vonbrand (subscriber, #4458) [Link] (1 responses)

And? How do you know whoever patched the bug knew the CVEs beforehand? This is a RHEL kernel, i.e., a stable kernel (+ patches), so this came probably via the stable patch stream.

Kernel.org's road to recovery

Posted Oct 11, 2011 0:24 UTC (Tue) by malor (guest, #2973) [Link]

Ok, I'm done talking to you. You just keep moving the goalposts around, anything to not be wrong.

Kernel.org's road to recovery

Posted Oct 10, 2011 22:47 UTC (Mon) by malor (guest, #2973) [Link]

Oh, and I didn't mention the remote root exploit from today's post, because that looks hard to exploit, involving an attempt to mount a CIFS share from a hostile server. But it is remote root, and using CIFS to share files across security boundaries is hardly unheard of.

Kernel.org's road to recovery

Posted Oct 10, 2011 13:15 UTC (Mon) by PaXTeam (guest, #24616) [Link]

> And, of course, imputations of bad faith and lying are *really likely*
> to make people trust you and want to work with you.

it was 'bad faith' and i think you've got enough proof now (straight from the horses's mouth even) that i was right ;). as a sidenote, calling someone a looney is "*really likely* to make people trust you and want to work with you". oh the irony ;).

> This is why PaXTeam's excellent technical nous goes largely wasted into
> out-of-tree stuff that is relatively little used[1]:

being out-of-tree is not a waste, it's called a fork and is actively encouraged by kernel developers (i'm sure you can google some Linus quotes to that effect yourself). second, PaX is more like a research project, not a product, so it's natural that its userbase is restricted. nevertheless, the ideas pioneered there over the years have found their way into every major OS these days (linux, BSDs, iOS (both kinds of them), OS X, Windows, etc). i wish every good thing in the world was this 'wasted' ;).

> when he tries to interact with other people, the moment any criticism of
> any kind is levelled -- which takes about six seconds on a list as
> hardboiled as the kernel list -- out come the vituperative personal
> attacks, conspiracy theories, and imputations of malice -- and of course
> he is never wrong either, no matter what evidence is presented

that was quite a mouthful, but let me try to make some sense of it. first, some kind of proof would be useful in general when you throw out accusations (the irony is that you asked for the same in the past, yet are refusing to do the exact same thing when it's your turn ;). second, you should probably be reading more lkml to know the context better and understand the social interactions there. third, what evidence are you talking about? last i checked, i had a few dozen unanswered questions left, both on lkml and here, and i'm still waiting patiently for the 'evidence' ;).

> I expect further personal attacks in response to this comment [...]

so you go out of your way to attack me personally and at the same time make also snide remarks at kernel developers. and then you run and cry 'but pretty please do not come after me'. IOW, you've just proven yourself to be a troll (not that i had any doubts before ;).

PS: your knowledge of the linux ecosystem is kinda outdated. Fedora et al. are 'irrelevant'. what matters today is android, by virtue of having an install base of orders of magnitude bigger than even Ubuntu. the rest is 'also run' (no disrespect meant, but nix's playing the numbers game here and the numbers are like this. i personally don't care which particular linux flavour ends up using PaX or other ideas, the important thing is that they're available for those who need them).