Recent Features
| |||||||||||||
Stable kernel 2.6.25.6Stable kernel 2.6.25.6Posted Jun 11, 2008 6:49 UTC (Wed) by nix (subscriber, #2304)In reply to: Stable kernel 2.6.25.6 by ncm Parent article: Stable kernel 2.6.25.6
I'm not missing the point, really. I *agree* with the primary point, that security holes should be described better: I just don't think that it's a sign of malice (or intent at all) that they aren't described better, and I can't see any practical way once the changelog is written to get them described better, and for Linus and upstreams to scan every change for signs of this sort of thing and rewrite their changelogs does not scale (not to mention that that sort of changelog rewrite in effect means a rebase, and Linus rebasing his tree a lot would be... problematic for everyone pulling from him). The thing that has to be done, of course, is to educate people to think securitywise, so that they ask the same questions Brad asks: `how might this be abused?' for starters. But most people, even most kernel hackers, don't think like that (and if programmers did then a lot of security holes wouldn't appear in the first place). It's just that there is no quick fix. If this was some conspiracy on the part of a few individuals, as some above suggest, then fixing it would be easy. It's not.
(Log in to post comments)
Stable kernel 2.6.25.6 Posted Jun 11, 2008 8:56 UTC (Wed) by PaXTeam (subscriber, #24616) [Link] why do you keep talking about *rewriting* commits post-facto? noone was asking for that (and to the credit of the -stable crew, they do try to put at least the CVE entry into them, even when Linus didn't although he had had it at the time already). what we are talking about is exactly what you find unbelievable: the conscious and deliberate circumvention of the full disclosure policy they supposedly have. i already hinted at several examples, but if you want actual raw meat, go ask for the kernel security archives. that'll be quite a shock, i can assure you.
Let's talk about how to improve things, instead? Posted Jun 11, 2008 13:47 UTC (Wed) by hmh (subscriber, #3838) [Link] Assuming such downplaying did happen, what we would need is better guidelines on how to react first, and getting on the case of any further such downplaying after the guidelines are published. That will make it clear that downplaying is frowned upon (no, that concept is NOT known to all, otherwise nobody would ask about it). Joe-random kernel developer needs to know the answers to at least these: How should we deal with security fixes restricted to non-released kernels (-mm, -rc, -next, etc)? How should we deal with security fixes that also address a problem on released kernels? What is the bar above which we are to treat it as a critical issue, and escalate it well outside the normal workflow (remote exploitable, probably)? What is the critical issue workflow (needs at least Linus, -stable, and vendor sec coordination to preserve secrecy until the time of a coordinated release, since we cannot do secret releases)... Documentation/SecurityBugs fails to answer the above questions fully in a definite way. It does imply that "downplaying" is not the idea, but IMHO it is not worded strongly enough on that area, either. Why don't you guys come up with these guidelines and improve Documentation/SecurityBugs? It might not help fix ALL the problems, but it IS a starting point to fix them, and first steps are important. Also, accessing the impact of patches to -stable before the next stable is released is *easy* (if you have the skill to do such accessments). If you do that, you can flag a next -stable release as one containing security fixes replying on the LKML for all to see. Then, if it is released without the proper wording (which I *doubt* would happen), you will be in a very strong position to make a damn big racket about it and demand explanations. You just need to write to the -stable team, and request to be in the permanent stable review team. You'd get CC'ed with all patches at least 24H before the release is out (except for "security fix-only stable releases, which are not an issue since they are already flagged as a security-fix release anyway). Note that if you read LKML and vger.k.o is not having issues, you already get ALL the patches that will be in the next -stable with more than 24H forewarning anyway.
Let's talk about how to improve things, instead? Posted Jun 11, 2008 14:15 UTC (Wed) by PaXTeam (subscriber, #24616) [Link] i think you should be having this discussion on lkml, not here. after all, that's where the kernel devs in question are. also, what is not clear about: We prefer to fully disclose the bug as soon as possible. (quote from Documentation/SecurityBugs)? it later elaborates only on the disclosure date, never on the extent of the disclosure. in other words, nothing ever even just hints at possible partial or non-disclosure at all. and that's exactly what has happened as you can see from the few examples in this thread. what else do you really want to put into writing? as for -stable, i guess you haven't read the whole thread, so please do so now and understand that the problems don't start with -stable per se (most of the time, there're exceptions like the ptrace case documented above), it's way before and for these security related bugs, on a closed and secret list (read: noone is accountable, that's why they think they can get away with it).
|
|||||||||||||