User: Password:
|
|
Subscribe / Log in / New account

2.6.32.9 Release notes

2.6.32.9 Release notes

Posted Feb 22, 2010 19:07 UTC (Mon) by clugstj (subscriber, #4020)
In reply to: 2.6.32.9 Release notes by spender
Parent article: 2.6.32.9 Release notes

It's not a straw man. I'm too lazy to look it up, but nearly every time that there is a security problem in a kernel update, someone belly aches that the kernel developers should figure out for if this bug is a security problem for them.

It's very hard work to do this even in the general case. I'd much rather the kernel developers spend their time FIXING bugs than trying to imagine the possible uses a black hat could have for it.

I didn't point anyone out explicitly, but it does appear that I hit a nerve.


(Log in to post comments)

2.6.32.9 Release notes

Posted Feb 22, 2010 19:22 UTC (Mon) by spender (subscriber, #23067) [Link]

Not only are you too lazy to look it up, but if you try you won't find anything. I did a simple search for you, so you can see what we've said *repeatedly* and exactly why you're attacking a straw man.

http://lwn.net/Articles/286263/
"Willy, please do read the previous discussion before commenting. the problem isn't that people are unable to determine whether a given bug has a security impact or not. that is a separate issue and is not the point raised now. the problem we exposed is that of covering up security impact information when it *is* already known to the kernel developers."

"2. as you were told about a dozen times already, the problem isn't with not recognizing a bug for its security impact (or rather, that's a separate problem), but the intentional omission of such information when it is already known."

http://lwn.net/Articles/290570/
"yes, it would be the next step after the already known security issues are acknowleged at least."

http://lwn.net/Articles/373731/
"And again, before anyone brings it up again, it's not about the developers themselves trying to figure out if every bug is a security bug -- it's about not hiding or obfuscating what they are clearly aware of."

"If you don't omit the security information you're aware of, nothing changes on the blackhat side because they can already spot developer weasel words when the developers are committing a vulnerability fix."

I look forward to your apology.

-Brad

2.6.32.9 Release notes

Posted Feb 22, 2010 20:16 UTC (Mon) by clugstj (subscriber, #4020) [Link]

Pardon me if I don't believe your "search" - it could be a bit biased. Why would I apologize to you? Did I mention you or the others going bonkers in this thread by name at any point in this discussion?

If you told a kernel developer that such and such a bug has this security impact, why should he automatically believe you? Unless he very much trusts your opinion or has the time to check your findings, he would be foolish to do so.

I made the original comment for two reasons:

1) I have seen the kind of comment of which I speak. I never said it was from you, nor did I have you in mind.
2) I don't mind stirring the pot.

2.6.32.9 Release notes

Posted Feb 22, 2010 20:24 UTC (Mon) by bojan (subscriber, #14302) [Link]

> If you told a kernel developer that such and such a bug has this security impact, why should he automatically believe you?

Er, because he found and wrote exploits for quite a few security problems in the kernel?

2.6.32.9 Release notes

Posted Feb 25, 2010 13:52 UTC (Thu) by vonbrand (guest, #4458) [Link]

Please stop this nonsense. If Linus (or whoever) knows about the possible security implications of, let's say, 10 or 20% of the bugs, and only marked those, the majority of security sensitive bug patches would just be ignored by would-be "experts", and the whining about the other "not reported" bugs would start whenever some box gets broken into...

A bug in the kernel is potentially extremely serious, go and fix it. Questions are optional, patching isn't.

2.6.32.9 Release notes

Posted Feb 25, 2010 14:55 UTC (Thu) by PaXTeam (guest, #24616) [Link]

> If Linus (or whoever) knows about the possible security implications of,
> let's say, 10 or 20% of the bugs, and only marked those the majority of
> security sensitive bug patches would just be ignored by would-be "experts"

stop that nonsense. you have zero evidence for it. in the previous thread a kernel developer only offered anecdotal evidence which is of course as good as mine or anyone else's. you might want to understand who patch users are too: http://lwn.net/Articles/374094/ . also you might want to explain why file system corruption bugs are marked as such in commit messages whereas there's no guarantee that unmarked commits don't fix file system corrupting bugs.

> A bug in the kernel is potentially extremely serious[...].

it depends on the bug. and as we learned from local experts here, it also depends on what one considers a bug at all ;).

> Questions are optional, patching isn't.

you've never really had a real job, have you.

2.6.32.9 Release notes

Posted Feb 25, 2010 20:44 UTC (Thu) by nix (subscriber, #2304) [Link]

Filesystem corruption bugs are marked as such *if people realise at fix
time that they are filesystem corruption bugs*.

Not all filesystem-corrupting bugs are recognised as such at fix time,
just like not all security bugs are recognised as such. (It is probably
easier to detect a filesystem-corrupting bug than a security bug, because
at least there are broad regions of the kernel where bugs are unlikely to
affect filesystems, which is not true for security holes.)

btw, nice to see you're vilely rude to everyone, not just me (and fifty
seconds' googling would make it clear that he's had multiple real jobs in
the free software community. He gives out his real name, you see.)

2.6.32.9 Release notes

Posted Feb 25, 2010 22:42 UTC (Thu) by PaXTeam (guest, #24616) [Link]

> *if people realise at fix time that they are filesystem corruption bugs*.

aha. and "if people realise at fix time that they are security bugs" they... don't mark them as such. not only that, they even try to explain why that's a good thing. now you tell me why the same arguments don't apply to filesystem corruption bugs (and many others, i just picked an obvious one for this exercise). or more to the point, why the arguments for marking known filesystem corruption bugs don't apply to known security bugs. btw, i'm glad that after years of misunderstanding you're slowly getting it ;).

> [...]because at least there are broad regions of the kernel where bugs
> are unlikely to affect filesystems,

anything that can result in kernel memory corruption, in those broad regions of the kernel included, has a fair chance to trash filesystem related (meta)data as well. speaking of which, by the same token if said memory corruption bugs are not marked for security, they should at least be marked for potential filesystem corruption but not even that is done.

> btw, nice to see you're vilely rude to everyone, not just me

i wasn't rude to you, you yourself admitted that you sometimes post under the influence of drugs that you later regret. i was merely wondering if the same happened here as well because you so obviously posted crap about something that wasn't ever said (you're welcome to prove your post with quotes from us).

> (and fifty seconds' googling would make it clear that he's had multiple
> real jobs in the free software community.

make it 5 seconds, but then we've got bigger skill differences i guess ;). and yes, i know where he teaches and it's also clear that he has no idea whatsoever about how a real corporation works where people have real responsibilities and the "Questions are optional, patching isn't" mentality doesn't fly in *any* production environment i've ever seen (hint: it's not how RH/Novell work either). but someone like you should know better than defending such a stand.

> He gives out his real name, you see.

this coming from an anonymous coward sounds just way too funny ;).

2.6.32.9 Release notes

Posted Feb 25, 2010 23:09 UTC (Thu) by nix (subscriber, #2304) [Link]

aha. and "if people realise at fix time that they are security bugs" they... don't mark them as such.
And I agree that that is a bad thing, and have said so repeatedly, although I'd understand it if you were too busy sniping to actually read what I write.

2.6.32.9 Release notes

Posted Feb 22, 2010 19:28 UTC (Mon) by PaXTeam (guest, #24616) [Link]

> It's not a straw man.

it is as none of us made such a claim you're trying to push here, in fact every time this comes up we make a claim to the contrary: kernel devs are not expected to figure out the security impact of bugs because they're not qualified to do so. just look at Jon's effort here and how he missed #1 and mischaracterized #2.

> I'm too lazy to look it up

you're not lazy to look it up, you're unable to but needed a convenient excuse.

> but nearly every time that there is a security problem in a kernel update

you're welcome to find a *single* post from us that makes a claim you wish to attribute to us. after all, if it was 'nearly every time' you won't have to spend more than a few seconds to find one.

> someone belly aches that the kernel developers should figure out for if this bug is a security problem for them.

we never made such a claim, and in fact i don't recall anyone else making it either. but the onus is on you to back up your statement.

> I didn't point anyone out explicitly, but it does appear that I hit a nerve.

considering the amount of trolling and shouting from you, i know whose nerve was hit ;).

2.6.32.9 Release notes

Posted Feb 22, 2010 20:22 UTC (Mon) by bojan (subscriber, #14302) [Link]

> It's not a straw man. I'm too lazy to look it up, but nearly every time that there is a security problem in a kernel update, someone belly aches that the kernel developers should figure out for if this bug is a security problem for them.

I certainly never asked for anything like that.

So, once again: if it is known, it should be passed on. That's it.

2.6.32.9 Release notes

Posted Feb 22, 2010 20:25 UTC (Mon) by clugstj (subscriber, #4020) [Link]

Guys, get over yourselves. When did I mention anyone by name?

2.6.32.9 Release notes

Posted Feb 22, 2010 20:33 UTC (Mon) by bojan (subscriber, #14302) [Link]

Just making sure that "someone" doesn't include me.

2.6.32.9 Release notes

Posted Feb 22, 2010 21:41 UTC (Mon) by PaXTeam (guest, #24616) [Link]

if you weren't just trolling then you can name at least one of those 'whiners'. with actual proof of that whining to back it up of course. should be easy since "nearly every time that there is a security problem in a kernel update, someone belly aches that the kernel developers should figure out for if this bug is a security problem for them".


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds