Weekly Edition
Return to the Kernel page
| |||||||||||||
Handling kernel security problems
Even the most casual observer of the linux-kernel mailing must have noticed
that, in the shadow of the firmware flame war, there is also a heated
discussion over the management of security issues. There have also been
some attempts to turn this local battle
into a multi-list, regional conflict. Finding the right way to deal with
security problems is difficult for any project, and the kernel is no
exception. Whether this discussion will lead to any changes remains to be
seen, but it does at least provide a clear view of where the disagreements
are.
Things flared up this time in response to the 2.6.25.10 stable kernel update. The announcement stated that "any users of the 2.6.25 kernel series are STRONGLY encouraged to upgrade to this release," but did not say why; none of the patches found in this release were marked as security problems. As it happens, there were security-related fixes in that update; some users are upset that they were not explicitly called out as such. They have reached the point of accusing the kernel developers of hiding security problems. These problems, it is said, are fixed with relatively benign-sounding commit messages ("x86_64 ptrace: fix sys32_ptrace task_struct leak," for example) and users are not told that a security fix has been made. This, in turn, is thought to put users at risk because (1) they do not know when they need to apply an update, and (2) there is no clear picture of how many security problems are surfacing in the kernel code. So, as "pageexec" (or "PaX Team") put it:
the problem i raised was that there's one declared policy in
Documentation/SecurityBugs (full disclosure) yet actual actions are
completely different and now Linus even admitted it. the problem
arising from such inconsistency is that people relying on the
declared disclosure policy will make bad decisions and potentially
endanger their users. there're two ways out of this sitution:
either follow full disclosure in practice or let the world at large
know that you (well, Linus) don't want to. in either case people
will adjust their security bug handling processes and everyone will
be better off.
There are two aspects to the charge that the kernel is not following a full disclosure policy: commit messages are said to obscure security fixes, and kernel releases do not highlight the fact that security problems have been fixed. There is an aspect of truth to the first charge, in that Linus will freely admit to changing commit logs which discuss security problems too explicitly:
I literally draw the line at anything that is simply greppable
for. If it's not a very public security issue already, I don't want
a simple "git log + grep" to help find it.
That said, I don't _plan_ messages or obfuscate them, so "overflow" might well be part of the message just because it simply describes the fix. So I'm not claiming that the messages can never help somebody pinpoint interesting commits to look at, I'm just also not at all interested in doing so reliably. His goal here is clear: make life just a little harder for people who are searching the commit logs for vulnerabilities to exploit. One may argue over whether this policy amounts to hiding security problems, or whether it will be effective in reducing exploits (and plenty of people have shown their willingness to do such arguing), but the fact remains that it is the policy followed by Linus at this time. In his view, the committing of a fix is the disclosure of the problem, and there is no need to be more explicit than that. That view extends to the whole security update process found in much of the community. He has no respect for embargo policies or delayed disclosure, and he criticizes the "whole security circus" which, in his opinion, emphasizes the wrong thing:
It makes "heroes" out of security people, as if the people who don't just
fix normal bugs aren't as important.
In fact, all the boring normal bugs are _way_ more important, just because there's a lot more of them. I don't think some spectacular security hole should be glorified or cared about as being any more "special" than a random spectacular crash due to bad locking. Beyond that, it is often hard to know which patches are truly security fixes. It has been argued at times that all bugs have security relevance; it's mostly just a matter of figuring out how to exploit them. So explicitly marking security fixes risks taking attention away from all of the other fixes, many of which may also, in fact, fix security issues. Thus, Linus says:
If people think that they are safer for only applying (or upgrading
to) certain patches that are marked as being security-specific,
they are missing all the ones that weren't marked as such. Making
them even _believe_ that the magic security marking is meaningful
is simply a lie. It's not going to be.
So why would I add some marking that I most emphatically do not believe in myself, and think is just mostly security theater? That said, the stable kernel updates go out with patches which are known to be security fixes. Some people clearly believe that being STRONGLY encouraged to update is not sufficient notification of that fact. It does seem that there has been a trend away from explicit recognition of security issues in the stable releases. The inclusion of CVE numbers was once common; in the 2.6.25 series, only 2.6.25.1, 2.6.25.2, and 2.6.25.5 had such numbers in the changelogs. It is, indeed, true that a straightforward reading of the stable release changelogs will not tell users whether those releases fix relevant security issues. There are a number of answers to that complaint too, of course. The real information is in the source code, and that is always public. The fixes in the stable series are unlikely to be all that relevant to most users anyway; they are running distributor kernels which are many months behind even the -stable series and which may (or may not) be affected by a specific problem. In the end, users who are concerned about security issues in their kernels have somebody to turn to: their distributors. Linux distributors follow disclosure rules and tend to do a pretty thorough job of fixing the known security problems and propagating those fixes to users. For users who need a high level of long-term support, there are distributors who are more than willing to provide that kind of service for a fee. As is often the case, what it really comes down to here is resources. It would be nice if somebody were to follow the patch stream (well over 100 patches/day into the mainline) and identify each one which has security implications. For each patch, this person could then figure out which kernel version was first affected by the vulnerability, obtain a CVE number, and issue a nicely-formatted advisory. But this is a huge job, one which nobody is likely to do in an uncompensated mode for any period of time. So somebody would have to pay for this work. And, to a great extent, that is just what the distributors are doing now - with the nice addition that they backport the fixes into the kernels they support. It is worth noting that those distributors have not been doing a whole lot of complaining about how security fixes are handled now. Instead, the complaining has come, primarily, from the maintainers of the out-of-tree grsecurity project which, from a suitably cynical point of view, could be seen to benefit from raising the profile of Linux kernel security problems. But, regardless of the validity of any such charge, there may be some value in what they are asking. It is good to have a clear sense for what the security problems in a piece of code are. If nothing else, it helps the project itself to understand where it stands with regard to security and whether things are getting better or worse. So it would be nice if the kernel developers could be a bit more diligent and organized in how they track security issues, much like the tracking of regressions has improved over the last couple of years. But this kind of improvement will not happen until somebody decides to put the work into it. Actually putting some time into documenting kernel security issues will accomplish far more than complaining on mailing lists. (Log in to post comments)
Handling kernel security problems Posted Jul 16, 2008 19:08 UTC (Wed) by nix (subscriber, #2304) [Link] Of course this particular flamewar started *here* and then graduated to l-k later on. Cross-medium flamage!
Handling kernel security problems Posted Jul 16, 2008 22:38 UTC (Wed) by pr1268 (subscriber, #24648) [Link] > and then graduated to l-k later on I suppose Pax Team finally got the message Greg K-H was trying to make. Of course, Pax Team still kept on during the LWN 2.6.25.11 release announcement. While I agree with Pax Team's philosophy that software bugs should be categorized on their severity (in order to help sysadmins, distro developers, and end-users prioritize updates), I feel that it's more important that the kernel developers not be bothered with having to do this taxonomy. As Linus said recently, "A bug is a bug." There are other groups, organizations, enterprise-level software distributors, and such whose task is to assess the severity impact of software bugs. (Disclosure: I've also asked on LWN about the recent rash of bugfix releases to 2.6.25 and requested clarification of the "strongly encouraged" verbiage I keep hearing in Greg's announcements.) I think Pax Team has heard the best answer he's going to get from the kernel devs. If he keeps up the flamewar, then likely it's because he hasn't heard an answer that he likes.
Handling kernel security problems Posted Jul 16, 2008 23:24 UTC (Wed) by PaXTeam (subscriber, #24616) [Link] > I think Pax Team has heard the best answer he's going to get from the > kernel devs. If he keeps up the flamewar, then likely it's because he > hasn't heard an answer that he likes. actually i don't think it was much of a flamewar at all. all that happened was that i tried to figure out what kernel devs actually think about security bugs, and why they think that. i got answers to both and that's about it. as time permits, i'll continue to point out security problems that they cover up because there is an apparent need for it.
Not much of a flamewar at all Posted Jul 17, 2008 0:01 UTC (Thu) by pr1268 (subscriber, #24648) [Link] Thanks for the reply and clarification. My use of the term "flamewar" was meant in the broadest sense of the word. My bottom paragraph describes how I perceived why you continued to post replies to the LKML even after many of the senior kernel devs had already pitched in on why they do things the way they do.
You're certainly welcome to you opinion that "there's an apparent need for [security problems being covered up]", and I partially agree with you in this matter, but continued discussions and debates on the LKML
Not much of a flamewar at all Posted Jul 17, 2008 0:45 UTC (Thu) by PaXTeam (subscriber, #24616) [Link] oh, i think i know what you were thinking of as 'flamewar' then. basically, the program was this: ask the kernel devs how they handle security bugs (what goes into the commits, what gets announced, etc). once that was clear (essentially, not full-disclosure but non-disclosure, or coverup), i got interested in why they decided that that was the best way for them. note i did *not* want to change their minds per se, but as having some background and experience in security, i thought maybe they based their decision on flawed assumptions (that i've seen so many times) and if explained/corrected, they may rethink their position - or i would learn something new. so i asked further about the justification for not including security info in commits/announcements/etc and got all kinds of silly reasons that were easy to explain. that it didn't have any effect and we ended up with 'we do it just because' is not my fault, nor do i consider it a success to learn about their motives. so that's about it, we'll continue to go different ways.
Handling kernel security problems Posted Jul 16, 2008 19:32 UTC (Wed) by nix (subscriber, #2304) [Link] They were accusing the kernel developers of intentionally hiding security problems from the very *start*. Despite Documentation/SecurityBugs plainly not being any kind of 'security policy'[1] and despite Linus saying as much, all the participants on the other side of this little flamewar are *still* calling it a 'security policy' and alleging dishonesty for not 'complying' with it. At this point I'm afraid I can't see any way in which the accusers could be considered to be operating rationally. They simply aren't listening to anything anyone else says, rather responding by reiterating the same damn tired points over and over: one imagines that the only thing they'd be satisfied with is complete acquiescence, and that's not the way l-k works (or any free software project I know of). davem has pointed out the additional irony that the accusing side is waving the banner of 'full disclosure' while not actually disclosing their own *names* in the majority of cases. We've got people complaining using the names of fictional characters (who in that work of fiction had adopted that name to cover up an ancient crime: not the best choice of pseudonyms). (I don't object to pseudonyms normally, but if you're using a pseudonym *and* waving a full-disclosure banner, accusing other people of hypocrisy is not very sensible.) [1] it doesn't say how all security holes discovered in the kernel will be treated, but rather how holes *which the discoverer chooses to report to a specific non-l-k list* are treated
Handling kernel security problems Posted Jul 16, 2008 21:09 UTC (Wed) by tialaramex (subscriber, #21167) [Link] The anonymous poster at the center of this doesn't like the idea that security bugs aren't a distinct and readily identifiable class, and thus all talk of "properly labelling" them proceeds from a false assumption. I normally associate this with inexperience. There's a side thread to the LKML discussion in which someone clearly makes this mistake, believing that anyone with suitable experience could quickly classify bug-fixes into "security" and "not security" buckets - and looks very foolish arguing with Linus about it. Actually the real recurring theme is "grep". Only someone who relies on "grep" to the exclusion of actual thought processes would be so obsessed with seeing phrases like "exploitable overflow" introduced into the Linux changelogs, particularly in places where the "exploit" is arcane and entirely theoretical ("first, design a custom PCI device...") or for a bug that never actually landed in a stable release. And only someone who preferred "grep" to thinking for themselves would read two words from the vague and meandering policy of the security response alias/ mailing list as a binding statement of Linus' rules for contributions to the kernel. The final thing I notice is the old politicians manoeuvre of arguing that of course the poster is a smart guy who doesn't use "grep" but won't somebody think of the I think the best policy for the stable maintainers would be to add some boilerplate that says stable kernel versions include fixes to privileged code which are therefore likely to have a security impact. This achieves nothing whatsoever, except apparently to make some people happy (or at least force them to invent a new reason to be unhappy) and if it was boilerplate the maintainers needn't do any additional work.
Handling kernel security problems Posted Jul 16, 2008 22:06 UTC (Wed) by nix (subscriber, #2304) [Link] Only someone who relies on "grep" to the exclusion of actual thought processes would be so obsessed with seeing phrases like "exploitable overflow" introduced into the Linux changelogs, particularly in places where the "exploit" is arcane and entirely theoreticalI'd say that this clearly does not describe the PaX or grsecurity hackers. They do know their stuff and are quite capable of identifying security holes without grep (even if they do jump the gun now and then and identify things as threats that aren't). I suspect that they think that this does describe random sysadmins using -stable kernels, perhaps on the mistaken assumption that most people use Linus's kernels these days (an understandable assumption for the maintainers of kernel patches: after all, they do), and so therefore the -stable descriptions must be such that the braindead can understand 'upgrade now'. (Why statements like 'upgrade now' in the -stable kernel announcements are still considered unacceptable 'coverups' I have no clue.) (I'd be surprised if there were many braindead people tracking the stable kernels, myself, but it's an understandable viewpoint.)
Handling kernel security problems Posted Jul 16, 2008 20:32 UTC (Wed) by jengelh (subscriber, #33263) [Link] >One may argue over whether this policy amounts to hiding security problems, or whether it will be effective in reducing exploits (a) clueful people will find the bugs anyway (b) clueless people should use a distro kernel that is adequately updated
Handling kernel security problems Posted Jul 16, 2008 21:19 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] Not just clueless people: people who have work to do in other areas are better off letting experts take care of the kernel for them. No one has the brain cycles to be expert on the guts of every bit of software they run.
Handling kernel security problems Posted Jul 16, 2008 21:35 UTC (Wed) by flewellyn (subscriber, #5047) [Link] It is worth noting that those distributors have not been doing a whole lot of complaining about how security fixes are handled now. Instead, the complaining has come, primarily, from the maintainers of the out-of-tree grsecurity project which, from a suitably cynical point of view, could be seen to benefit from raising the profile of Linux kernel security problems. Given the actions of those people when they posted here, I don't think that viewpoint requires any great degree of cynicism. It seems quite accurate.
Handling kernel security problems Posted Jul 16, 2008 22:38 UTC (Wed) by spender (subscriber, #23067) [Link] The PaX team certainly benefits the most from it -- given that they don't get paid a cent for any of the work they do. So in what way do they benefit again? Name recognition? Shucks, that doesn't pan out either. Sorry but this is nothing but a way to avoid what's really the problem here by trying to discredit the messenger (who btw has been doing this for free for 8 years now and is to thank for all the actually useful security improvements you're using right now that have been copied from it by everyone else). -Brad
Handling kernel security problems Posted Jul 17, 2008 11:17 UTC (Thu) by clugstj (subscriber, #4020) [Link] Obviously the benefit isn't money - everyone knows that. I don't see why fame (name recognition) can't be the reason. Yours is a straw man argument.
Handling kernel security problems Posted Jul 17, 2008 20:50 UTC (Thu) by lysse (guest, #3190) [Link] For some reason I'm reminded of this quote from "A Man for All Seasons":
Human motivations can be complex and strange little beasts...
Handling kernel security problems Posted Jul 16, 2008 22:54 UTC (Wed) by spender (subscriber, #23067) [Link] And if you want to be "suitably cynical" I suppose the reason why the distributors haven't been doing a whole lot of complaining about how security fixes are handled is because not having as many disclosed security vulnerabilities in the Linux kernel makes it look like less of a mess. Even Linus says himself that "they mostly do a crap job at it, only focusing on a small percentage (the ones that were considered to be "big issues")" -Brad
Simplistic solution? Posted Jul 16, 2008 22:27 UTC (Wed) by bojan (subscriber, #14302) [Link] > It has been argued at times that all bugs have security relevance I guess stable folks could adopt a cynical view here and just open a CVE for every new release, claiming that unknown security issues _may_ have been fixed, given that _bugs_ have been fixed. Then everybody would be happy :-)
Simplistic solution? Posted Jul 16, 2008 22:57 UTC (Wed) by nix (subscriber, #2304) [Link] Microsoft especially. They love counting these things and saying 'oh, look how insecure Linux is!'
Simplistic solution? Posted Jul 16, 2008 23:01 UTC (Wed) by pr1268 (subscriber, #24648) [Link] Oh, the FUDsters at <Software company in Redmond> would love that! Just picture it: Report of Operating System Security Vulnerabilities, January-December <year>
† A random, arbitrary number I just made up.
Simplistic solution? Posted Jul 17, 2008 0:29 UTC (Thu) by bojan (subscriber, #14302) [Link] If you look at those statistics now, Windows is already way ahead of Linux OSes in terms of security: http://blogs.technet.com/security/archive/2007/03/21/wind... http://blogs.technet.com/security/archive/2008/05/15/q1-2... So, nothing lost, I guess...
Handling kernel security problems Posted Jul 16, 2008 23:02 UTC (Wed) by PaXTeam (subscriber, #24616) [Link] > the out-of-tree grsecurity project which, from a suitably cynical point > of view, could be seen to benefit from raising the profile of Linux > kernel security problems. given that we're talking about kernel security bugs and grsecurity is implemented in the kernel, we're almost as much affected by them as anyone else is. while we do provide protection mechanisms on certain archs against a few classes of bugs and exploit techniques, they're very far from being an as comprehensive protection as say the one against remotely exploitable memory corruption bugs. so what is this benefit we're supposed to have? if it's increasing the number of grsec users then i think they're indeed better off, i don't see it as anything negative. do you? also you should have noticed that we *never* once brought grsec or PaX into the discussion, it was every single time someone else who just couldn't help it. it was a very conscious decision exactly to avoid such accusations that your cynical self threw out.
Handling kernel security problems Posted Jul 16, 2008 23:36 UTC (Wed) by zooko (subscriber, #2589) [Link] > which, from a suitably cynical point of view, could be seen to benefit from raising the profile of Linux kernel security problems. I prefer the suitably gracious point of view that the people in question are well-meaning hackers who hope to improve the world by contribution of their skills to open source projects. Unfortunately, being a well-meaning person who hopes to improve the world doesn't seem to automatically give you the skills to communicate and negotiate effectively. The same could be said of a great many well-meaning people whose names are familiar to us all because of their great contributions.
Handling flame-war problems with humour Posted Jul 17, 2008 2:50 UTC (Thu) by bignose (subscriber, #40) [Link] > One may argue over whether this policy amounts to hiding security problems, or whether it will be effective in reducing exploits (and plenty of people have shown their willingness to do such arguing) Your writing continues to be well worth the price of my subscription.
Time for a security release? Posted Jul 17, 2008 4:18 UTC (Thu) by tetromino (subscriber, #33846) [Link] To me, this flamewar serves as proof of one thing: the kernel is far less secure than many people imagine. The degree of insecurity is such that most stable updates should have multiple CVE numbers attached. Linus, apparently, has gotten annoyed by the time-density of security alerts, but instead of fixing the underlying issue (the development process that produces insecure code), decided to hide the security aspects of patches. The kernel code quality has been criticized in the recent past - but for introducing too many regressions. There are calls for more resources to be spend on regression tracking, and even for a mostly-bugfix releases to reduce the number of regressions. I believe that similar resources and propaganda efforts should also be spent on security. Maybe it's time for a security-only release - for 3 months spent not on new features, but on analyzing the security implications in the kernel, and on finally draining the morass of insecure code. The users will thank the kernel team for it.
Time for a security release? Posted Jul 17, 2008 14:25 UTC (Thu) by spender (subscriber, #23067) [Link] While I don't think a security release will really solve anything (since after that release it'd be back to business as usual), your first paragraph I think is right on regarding the real source of the problem. I'm glad somebody gets it! -Brad
is the Linux kernel becoming safer or becoming more vulnerable? Posted Jul 17, 2008 19:38 UTC (Thu) by zooko (subscriber, #2589) [Link] "To me, this flamewar serves as proof of one thing: the kernel is far less secure than many people imagine." I'm sure I agree, but this doesn't necessarily mean that the kernel ought to be made more secure. :-) Perhaps it means that people ought to have a lower expectation of its security. To make the kernel more secure would have other costs -- it might have less frequent releases, or support less new hardware, and so on. What I'm hoping for is not necessarily that the kernel development process changes to make the result more secure, but rather that it changes to make its security properties more transparent -- both users and developers. I'm not entirely sure how to do this -- it is hard to measure. But things that are hard to do are sometimes worth it -- better transparency and measurement can only help. Thanks to PaXTeam, GregKH, and Jon Corbet for their contributions to better transparency and measurement. So, my current burning question is: do we have reason to believe that the current 2.6.27 candidate has more or fewer exploitable security flaws than 2.6.26? How about 2.6.25? Do we think that 2.6.28, when it comes out is likely to have more or fewer? As rational, empirical thinkers who are faced with such an empirical question, we can take two complementary approached: measure the result, and we could look at the process and infer what we think would be the result. My humble attempt at the latter approach is here: https://zooko.com/log-2008.html#d2008-07-17-the_Linux_process_for_producing_more_and_more_rare_bugs. (I don't say so explicitly in that note, but an important consideration is that malicious actors are capable of exploiting flaws which are so rare that they never happen in the non-malicious case. Thus, if it is true that the Linux processes adds more and more rare bugs into the kernel while fixing common bugs, then this implies that it adds more and more security vulnerabilities into the kernel.)
Time for a security release? Posted Jul 17, 2008 20:01 UTC (Thu) by chromatic (guest, #26207) [Link] How would you prevent a security-only release from making life much more difficult for everyone who doesn't run an up-to-the-minute kernel? If every changeset must fix a potential security hole, you give changeset-reading miscreants dozens of new attack vectors to explore every day.
Time for a security release? Posted Jul 17, 2008 21:57 UTC (Thu) by dvdeug (subscriber, #10998) [Link] Why would it make life much more difficult? Today, "changeset-reading miscreants [have] dozens of new attack vectors to explore every day." In that case, "changeset-reading miscreants [would have] dozens of new attack vectors to explore every day." I'm not sure that it would have a serious effect on the time it takes to find a feasible attack vector and exploit it. On the other hand, for sometime after the final release, those who were behind on the latest kernel would have a less actually exploitable holes in the kernel for even the most careful source-code reading hacker to find.
Handling kernel security problems Posted Jul 17, 2008 20:33 UTC (Thu) by zooko (subscriber, #2589) [Link] You know Jon, the more I think about it the more it bothers me that you intimated that PaXTeam and company may be acting out of self-interest. The reason it bothers me is that the shoe fits better on the other foot. Granted that PaxTeam and company might have a certain amount of incentive to play up Linux security vulnerabilities, in order to increase their reputations at security researchers, but Linux core devs have an even greater incentive to play down security vulnerabilities in order to protect their reputations as kernel hackers. Likewise, companies which rely on Linux as part of their revenue stream have a very strong incentive to play down, hide, or obscure Linux's security problems. I like to assume that everyone involved is honest and of good-will. This is a good starting point. However, we have to admit that people are influenced by psychological motivations other than their sheer desire to contribute to the greater good. If you are writing up the release notes for the latest Linux kernel, it might sting your pride a little bit to write something like "The following seventeen remote root exploits have been fixed since the previous release.". (For example, the way the OpenBSD folks post prominently, at the top of their home page, the count of how many remote exploits they've shipped. -- http://openbsd.org .) If you are selling Linux to customers, then it might sting your revenue stream. But by the same token, it might be good for you to force yourself to write that down and show it to your users or customers.
Self interest Posted Jul 17, 2008 20:46 UTC (Thu) by corbet (editor, #1) [Link] You know, we're all acting out of self interest. If the motivation is purely a more secure kernel and more information about when it's not secure, that's still self interest.As for what was in the article, I said that a suitably cynical mind could see their actions as furthering the interest of their project. That is demonstrably true: that idea was raised in the discussion. To mention that is, I think, is along the same lines as covering the accusations that Linux developers are deliberately hiding security problems (out of their self interest, no doubt). Those charges, too, can be seen as insulting. Should I have covered one side and not the other? That said, maybe I should have left that sentence out. It lacks relevance to the real issues at hand. This kind of article is quite hard to write (gnarly technical stuff is much easier); I don't always get it perfectly right.
Self interest Posted Jul 17, 2008 21:02 UTC (Thu) by PaXTeam (subscriber, #24616) [Link] > As for what was in the article, I said that a suitably cynical mind > could see their actions as furthering the interest of their project. > That is demonstrably true: that idea was raised in the discussion. Ted raised it once and when i asked him for what he really meant, i got no response (i bet you too won't tell me what on earth i was supposed to gain from all this). on the other hand, i did explain, far too many times for my taste, how kernel devs covered up security bugs. i don't see how that's insulting when they even admitted it themselves. most of the discussion was all about their trying to justify that fact, not disputing it. see the difference?
Self interest Posted Jul 17, 2008 22:53 UTC (Thu) by nix (subscriber, #2304) [Link] No. You called them 'cover ups'. 'Cover up' in English implies not just intent but *malicious* intent, and you have proven no such thing, despite repeated assertions to the contrary.
Self interest Posted Jul 17, 2008 23:47 UTC (Thu) by spender (subscriber, #23067) [Link] 1 a: a device or stratagem for masking or concealing <his garrulousness is a coverup for insecurity> b: a usually concerted effort to keep an illegal or unethical act or situation from being made public 1. any action, stratagem, or other means of concealing or preventing investigation or exposure. to keep (something unpleasant) secret or hidden an attempt to prevent the public from discovering information about a serious crime or mistake to stop people discovering the truth about something bad Where did your definition come from? I doubt you pay the $295/year for a subscription to OED and that its definition differs in the way you hope. No maliciousness mentioned there in any definition I can find. Didn't we already tell you weeks ago you don't know the meaning of the words you use? Language is not private (go read some Wittgenstein). You can't just decide a certain word means something differently than the rest of the world recognizes it. When you do that, you gibber (read Clive Bell). Here you come up with your own meaning for the word, and then attack the PaX team because their claims meet up to their definition and the definition of everyone else in the world, but not to your contrived definition. Especially when we've already made clear several times in what way we mean coverup (which as you can see above, matches the accepted definition, as well as common usage of the term), your continued comments regarding it are just irresponsible and reckless. -Brad
Self interest Posted Jul 18, 2008 21:36 UTC (Fri) by man_ls (guest, #15091) [Link] On the contrary, nix has a splendid command of the English language. In this particular case he is spot-on, as has been sufficiently proved.
Self interest Posted Jul 18, 2008 21:51 UTC (Fri) by nix (subscriber, #2304) [Link] I'm trying to train myself out of responding to them. Security people tend to fall into two categories, charming and horrible, without many in the middle. tytso and Wietse Venema are examples of the charming type... Of course people can be quite different in person than on the net. I hope this is true here too.
Self interest Posted Jul 20, 2008 22:17 UTC (Sun) by PaXTeam (subscriber, #24616) [Link] while you two are celebrating i-don't-know what, let me remind the readers of this thread what these two geniuses said in the recent past. nix in http://lwn.net/Articles/286336/: 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. man_ls in http://lwn.net/Articles/286629/: Yes: do not hide bugs and do not hide security implications. "Do not hide" is the relevant part here. contrast that with what Linus and others said and think about who's played the fool here all this time ;).
Self interest Posted Jul 20, 2008 22:49 UTC (Sun) by man_ls (guest, #15091) [Link] We were celebrating that, no matter who's right, you can have a civilized discussion on the net where all parties implied learn something. Sadly this becomes very difficult as soon as some party enters the discussion calling names and behaving like teenagers.The way to adulthood usually is that first you learn how to behave and to respect your fellows, and then you can discuss whatever you like. Please do so; we don't need another De Raadt.
Self interest Posted Jul 20, 2008 23:27 UTC (Sun) by PaXTeam (subscriber, #24616) [Link] the thing is, right from the start you did not have a civilized discussion, i believe you see that yourselves now in hindsight. the lesson for you is that next time before you question the messengers, you should look at the message and do some background research yourselves before you engage them. in other words, ad hominem attacks are not conductive to your civilized discussion no matter how much you talk about adulthood and respect to your fellows later.
Self interest Posted Jul 21, 2008 6:15 UTC (Mon) by nix (subscriber, #2304) [Link] Most of your evidence was on private mailing lists: there's no way we could do that. (The word 'evidence isn't even really appropriate here.) Thus all we really have to go on is the word and character of the participants. Let's see, you or Linus. Boy, I wonder, *that's* a hard choice. After all you've been acting in a way so sure to make people believe every word you say. (Yes, the way you say things *does* matter. I dislike it too sometimes, but it's human nature.)
Self interest Posted Jul 21, 2008 7:16 UTC (Mon) by PaXTeam (subscriber, #24616) [Link] > Most of your evidence was on private mailing lists: there's no way we > could do that. (The word 'evidence isn't even really appropriate here.) actually, pretty much nothing was. we explicitly showed you commits and corresponding bugzilla/etc entries where the discrepancy should have at least raised a curious "yeah, really, what's up with that?" and resulted in your asking further questions to the devs themselves. and your reaction to that? let's see http://lwn.net/Articles/286405/ : Mostly I'm not interested enough to bother people over it. and *then* you still continued to attack the characters of people for *weeks* and even *now* you keep arguing that truth is decided by who says it, not by the supporting facts. that's as absurd and irrational as it can get. > Thus all we really have to go on is the word and character of the > participants. really, you *have* to? as if there were no alternative. you're just trying to explain your behaviour instead of apologizing for it (ah yes, that's part of adulthood too, you know, although you'll probably not find it in the dictionary that you seem to be so attached to). as a final note i'd like to make an observation in that the most or even all voracious ad hominem attacks came from anonymous posters such as yourselves. something to remind yourself next time you divide the 'security people' into black and white categories as somewhere above (i'm not into security by the way, just a web programmer).
Self interest Posted Jul 21, 2008 7:46 UTC (Mon) by nix (subscriber, #2304) [Link] I'm not saying that truth is determined by who says it, nor have I ever. What I'm saying is that *when a lot of evidence is invisible* (as was the case with yours despite your protestations), people *will* use the characters of the arguers in determining the probable truth or falsity of their statements. Fallacy or not, *this is the way people think*, and if you want to have anyone believe anything you say in future, remembering this might be wise. Right now I wouldn't believe you if you said the sky was blue, unless confirmed by independently available evidence. Your every action screams 'bias' (because all we have available is your words, and your words are every bit as rife with ad hominem attacks as they were when this mess started).
Self interest Posted Jul 21, 2008 12:36 UTC (Mon) by zooko (subscriber, #2589) [Link] From my perspective, it seems like it would be nice for someone to do the work of identifying security bugs specifically and explaining, for each one, what sort of situations expose the user to danger, how to work-around it, and what patch(es) fix it. We've already heard that GregKH and Linus aren't going to do that. Perhaps there's an opportunity for some other motivated, skilled person to offer that service? Such a service would help some users manage their risks better, and it would provide a valuable "feedback loop" to the kernel developers by documenting the issues.
Self interest Posted Jul 21, 2008 12:46 UTC (Mon) by PaXTeam (subscriber, #24616) [Link] yes, it would be the next step after the already known security issues are acknowleged at least. since such research requires full staff, the Linux vendors are in the best position to fund such a service.
Self interest Posted Jul 21, 2008 13:44 UTC (Mon) by nix (subscriber, #2304) [Link] Excellent idea. However, if the distro vendors did this, they'd probably do it for their stable enterprise kernels, as those are the kernels their paying customers use (and also kernels that change slowly enough that this sort of fine tooth-combing is possible). I wish this sort of thing was possible to fund with the raging high-speed chaos that is upstream kernels but I have a feeling that it isn't :/ still, hopefully if this were done *some* of the holes that were found in distro kernels might still be applicable upstream. (disclaimer: I have no input into funding decisions anywhere at all nor ever have had. This is purest speculation.)
Self interest Posted Jul 21, 2008 12:01 UTC (Mon) by man_ls (guest, #15091) [Link] Actually, in hindsight we (nix and others) were mostly right in our assumptions: kernel devs are not actively hiding security issues, but they are not actively researching them either, and they are not very good at that kind of research. The "kernel security policy" you waived in our collective faces is no such kernel security policy, but a policy for a certain mailing list. And so on.Unsurprisingly you did not learn anything from the discussion and had to go to lkml, where you were told essentially the same thing. Now our grumpy editor has dedicated a full article to the same issues from where (unsurprisingly) you came out as unenlighted as before. As to "questioning the messengers" it is always a healthy exercise and it would not be wise to stop doing it. If you are not up to such questioning then maybe your case is not that clear. I will not go into your accussations of ad hominem since they are completely unfounded.
|
|||||||||||||