Not so fast [LWN.net]

Not so fast

Posted Jun 19, 2008 13:18 UTC (Thu) by man_ls (subscriber, #15091)
In reply to: Not so fast by PaXTeam
Parent article: Stable kernel 2.6.25.7 released

OK, I see your point now: publicize all vulnerabilities as much as possible. Still I am not sure that you see mine: kernel devs are not security experts (most of them are probably not in the security list), and you cannot expect that they go out of their way doing security impact analysis. Also, you probably don't want them to. You have shown us several examples of sloppy security assessments; they are probably just not very good at it.

Maybe kernel devs need more training in security, or maybe an independent body doing risk analysis would be the way to go. As a developer who is not a security expert, I can tell you that things look pretty different from the inside. When Linus talks about the tendency to hide bugs and the need to fight it, he has a point.

(Log in to post comments)

Not so fast

Posted Jun 19, 2008 14:06 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]

> OK, I see your point now: publicize all vulnerabilities as much as
> possible.

well, that's not so much *my* point, it's what full disclosure means and it's what kernel devs
have committed to. i never said whether i liked/disliked this form of disclosure myself, i
just said that if someone publicly declared to follow such a policy, he'd better do that else
people will be misled and may make bad judgements affecting innocent users.

> kernel devs are not security experts (most of them are probably not in
> the security list), and you cannot expect that they go out of their way
> doing security impact analysis. Also, you probably don't want them to

actually, i did say the very same thing myself, e.g., here: http://lwn.net/Articles/286439/
(there was a reason i asked you to read all the previous posts before making your own).

> You have shown us several examples of sloppy security assessments; they
> are probably just not very good at it. 

no, the examples we wanted to draw attention to were cases where the kernel devs *knowingly*
omitted the security impact information (such as the ptrace self-attach fix). figuring out the
security impact of bugs is a whole different problem and noone expects regular kernel devs to
solve that. but when they see or are told what a given bug does, they'd better not sweep it
under the carpet yet that's exactly what happened.