login
Search
Because I see no point. Quite often, we don't even realize some random bug could have been a security issue. It's not worth my energy, in other words. Linus --
i understand and i think noone expects that. in fact, i know how much expertise and time it takes to determine that. but what happens when you do figure out the security relevance of a bug during bug submission (say, it goes directly to security@kernel.org with a PoC to trigger it) or while working out the fix or you see that it falls into an well-known exploitable bug class? you have the information yet you still make no mention of it. *that* at least can be fixed, if you chose so. cheers, PaX Team --
The issue is that I think it's then _misleading_ to mark that kind of commit specially, when I actually believe that it's in the minority. 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? I generally do not remove peoples changelog entries, although I _will_ do even that if I think it's just too much of an actual exploit description (of course - the patch itself can make the exploit fairly clear). So you'll find CVE entries etc in the logs if you look. But I do hope that anybody who looks for them is _aware_ that it's just a small minority of possible problems. Don't get me wrong - I'm not saying that security bugs are _common_, but especially some local DoS thing for a specific driver or filesystem or whatever can be a big security problem for _somebody_. Linus --
and how is that different from today's situation where they aren't told at all? in other words, they already learned to live with that risk. if you tell them about a security bug, they will build that knowledge into their risk assessment process (which is what security is all about in the end). anything you omit will skew their decision making process (in particular, expose them to exploits if they fail to apply a fix because they make a bad judgement call). in other words, you should not be worrying about people not learning about all security fixes, they already know it's not possible to provide such information. however sharing your knowledge that you do have will *help* them because 1. they can know for sure it's something important to apply (no need to use their limited human resources to make that judgement), 2. they can spend more of their resources on analyzing the *other* unmarked fixes. overall this can only improve everyone's security. what you're afraid of is that people will take your 'we mark security fixes we learn about' as 'we mark ALL security fixes that are such'. well, make that very clear in a public document (Documentation/SecurityBugs is a good place) and that's it, people will know you're doing a best effort disclosure and not more. cheers, PaX Team --
Umm. They are. They are told to upgrade to the stable kernel, which should have everything we know about. I'm just saying that why mark things, when the marking have no meaning? People who believe in them are just _wrong_. Linus --
you should check out the last few -stable releases then and see how the announcement doesn't ever mention the word 'security' while fixing security bugs (see my analysis at http://lwn.net/Articles/288473/). unless one digs into the actual commits and determines what's going on, it's easy to make a bad judgement call even for -stable. you know, there are places that can't just reboot into a new kernel every week for no reason (Microsoft has patch Tuesday once a month only). also what about people running older kernels, outside of -stable focus? do you determine how far back a fix should be applied? i don't think so, but people maintaining older series will do that, provided they get a hint. in other words, it's all the more reason to have the commit say it's what is wrong in particular? when you know that you're about to commit a patch that fixes a security bug, why is it wrong to say so in the commit? in what way will people reading that commit be misled? they will see it's fixing a security bug and they can prioritize it for whatever processes they have for backports, analysis, etc. if they don't see such marks, they will have to do a whole lot more work (effectively duplicating your own and even each other's efforts) to figure out the same. why not save them time and tell them directly what you already know? cheers, PaX Team --
Umm. What part of "they are just normal bugs" did you have issues with? I expressly told you that security bugs should not be marked as such, You have two cases: - people think the marking is somehow trustworthy. People are WRONG, and are misled by the partial markings, thinking that unmarked bugfixes are "less important". They aren't. - People don't think it matters People are right, and the marking is pointless. In either case it's just stupid to mark them. I don't want to do it, because I don't want to perpetuate the myth of "security fixes" as a separate thing from "plain regular bug fixes". They're all fixes. They're all important. As are new features, for that It's pointless and wrong because it makes people think that other bugs aren't potential security fixes. What was unclear about that? Linus --
For all the above: no. And this is the point of divergence. For you, as a person who "writes software", every bug is equivalent. You need to resolve problems, not classify them. However, as I previously explained [http://lkml.org/lkml/2008/7/15/654], security issues are identified and communicated through what can be a long and complicated (due to DNAs, etc.) process. If it culminates at implementation, without proper information forwarding from the development team, it will never reach the "upper layers" -- vendors, distributors, end users, et al. Therefore, yes, it is of major importance that you people, too, buy the problem and support the process as a whole. Otherwise... well, otherwise, we're back to where we started, 20 years ago. Good luck Linux users. --t --
Umm. That shouldn't be our worry. If others had a long and involved (and broken) process, they should be the ones that track the fixes too. We Umm. What was wrong with 20 years ago exactly? Are you talking about all the wonderful work that the DNS people did for that new bug, and how they are heroes for synchronizing a fix and keeping it all under wraps? And isn't that the same bug that djb talked about and fixed in djbdns from the start? Which he did about ten YEARS ago? Excuse me for not exactly being a huge fan of "security lists" and best practices. They seem to be _entirely_ be based on PR and how much you can talk up a specific bug. No thank you, Linus --
Yeah, at this point, it is clear to the world. No needs for repeated You weren't involved? Hold on, aren't you the developers, thence, those What was wrong for the computer theoretic people about 100 years ago? Lack of development? Not sure. Perhaps the same that existed for information security 20 years ago. Just perhaps. Are you trying to justify your irresponsibly indulgent act towards the operating system that my mother is likely to use with one alone Personally, I, too, have a major disgust for most crap seen in the so called info-sec world. I hand you my agreement on this one. Except, it changes in nothing your responsibilities. Take good care, --t --
Umm. And if the whole discussion it was hidden from us on some private vendor list, why should we then help track their hidden state? My responsibility is to do a good job. And not pander to the people who want to turn security into a media circus. Which is exactly what I'm doing. No media circus. Linus --
How can I expect one to treat the unknown? If you are not aware of it, you do nothing. Whenever a software organization is informed of a problem in some product of their responsibility, they act upon it. On the contrary, no, I don't expect any magic from you. Thanks for Wrong. This is not "media circus". Whoever reads this thread with the basic understanding of software development procedures, the reality of information security and with legit judgment will clearly understand what you are doing and what "pageexec" and I claim for. Further, I claim for decency from your part. All I ask for is to receive the "There are updates available." message as soon as one security problem is reported, understood and treated by your development part. And that is, the sooner possible, if you please. Plus, if one bothers, to be able to know the exact location of this bug and its characteristics. However, for these to happen, we need your collaboration. Or, with two words, your responsibility. Thanks, --t --
Well, some people keep it secret and track it on vendor-sec or similar, hidden from us. But then when they are ready to announce it, they want our help to glorify their corrupt process when they finally deign to let us know. And that Umm. You're talking to _entirely_ the wrong person. The people who want to track security issues don't run my development kernels. They usually don't even run the _stable_ kernels. They tend to run the kernels from some commercial distribution, and usually one that is more than six months old as far as I - and other kernel developers - are concerned. IOW, when we fix security issues, it's simply not even appropriate or relevant to you. More importantly, when we fix them, your vendor probably won't have the fix for at least another week or two in most cases anyway. So ask yourself - what would happen if I actually made a big deal out of every bug we find that could possibly be a security issue. HONESTLY now! We'd basically be announcing a bug that (a) may not be relevant to you, but (b) _if_ it is relevant to you, you almost certainly won't actually have fixed packages until a week or two later available to you! Do you see? I would not actually be helping you. I'd be helping the people you want to protect against! Linus --
Again, not asking for what you can not provide. You must, however, do Right *there* is where it is born! Right at your development kernels. It may or may not survive up to the big market. However, being at the source level, it is your duty to a) resolve the source-level issues; b) put affordable efforts in order to prevent one known issue to arrive at There is obviously room for suffering from this delay. It's really small, however, if you understand that this is not enough time for widely spread exploits to be in the hands of every corner kid. Not. Thus, consider the following: how many computers are likely to suffer from one bug that has been advised (marked as "security related" in your bugzilla), and, one week later, fixed? Now, how many computers are likely to suffer from one bug that has been advised and fixed 8 weeks later? A lot more, I presume. Ok. Now, imagine this scenario: one bug that has never been identified as "security relevant" is assigned and/or fixed by your people. Remember, your list is open to public. Do you have a clue of how many individuals keep watching every bug/fix, with a "security antenna" turned on, expecting for the right bug to show up and... not receive the attention it needs so they can do whatever they want, for the amount of time they please? Several. Now, tell me, how many computers are likely to suffer from the last Those who can see, and quickly exploit it, do not need your mark. They will figure it out right after it was assigned and an exploit will exist in the wild not after you fix the bug. So, let's work for the smallest pain. Right? --t --
I don't think we've ever heard any of the distro kernel engineers complain that there is a problem with how commits are documented in the upstream source. Keep in mind, the distro kernels are usually at least 6-9, to sometimes 18-24 months old. So many of the security bugs that show up in the developement kernels simply don't *apply* to the distro kernels; they security bugs simply aren't present in those older kernels. Of course, sometimes there are long-standing bugs. But I don't think the distro engineers have been complaining that they aren't finding out about them because they aren't marked <<------ SECURITY BUG HERE in big bold letters. And again, talking about something as if it were their ***duty*** is not a good way to pursuade people to do things in the open source world. The only guaranteed way to get something done in the open source is to help pay for it, or do it yourself. Sometimes you can convince others to do your work for you, but usually that requires some reciprocity in the long run. Regards, - Ted --
why? what makes you think that a bug fixed in 2.6.26 is not relevant to 2.6.20? do you or anyone else personally verify that? color me impressed why do you and others keep exaggerating of what is (well, was) expected from you? what's with this 'big deal' business? can't you image a middle ground where you simply just state what you know? say, my category 1-2 i talked your argument rests on a fallacy that we discussed already but you keep coming back with it. what makes you think that people exploiting kernel bugs *rely* on your marking security bugs as such? they do *not*. they are smarter (read: domain experts) than you or anyone else on lkml. they will most likely spot the security issue when you *introduce* it, not when you *fix* it. in other words, you are only helping the attackers by withholding security information, not your users. cheers, PaX Team --
From: pageexec@freemail.hu Many people who do kernel development do exactly this for the vendor they work for. The SCTP socket option overflow fix got into various dist releases not by chance and not because of some utterly pointless "security" tag in the commit message. --
i know that. but you conveniently skipped what i was replying to, here i'll ask again: why aren't security fixes that you fix relevant to users of older kernels (as that's what the topic was)? in other words, Linus was trying to justify with one more silly reason why security fixe aren't marked as such. the above basically said 'because they are not relevant to you' and i asked him why it is so. you're welcome to explain it as well. and no, vendors having people go through every single commit doesn't answer why you couldn't make *their* life easier as well by not withholding information. and not to mentiond a whole world of interested users beyond the commercial why do you call a security tag 'utterly pointless'? i've heard Linus's opinion and deconstructed every single one of his 'justifications' so far. what's yours gonna be? cheers, PaX Team --
From: pageexec@freemail.hu Backporting any fix to older kernels is a chore, the further back you go, the harder and less fun it is. The tipping point is really quick to where someone hacking the kernel for fun simply isn't going to do it, nor should they be expected to. That's why people who want a stable supported kernel with fixes constantly backported have grown accustomed to paying for that service. And to me that is entirely reasonable. --
it depends on the fix and the context of the code it touches. a one liner in 2.6.26 may not necessarily have to become a 100 line, multi-file fix in 2.6.16. look at 28d838cc4dfea980cb6eda0a7409cbf91889ca74 for an example, that was trivial to backport to many kernel versions before. also, if you can find a commercial distro whose kernel predates even yours (i.e., yours is between mainline and a well maintained commercial one) then you may not actually have such a big problem with backports even for more complex fixes as you can peek at what the commercial guys are doing. in any case, you're answering a different question or i'm failing to see the logical connection between 'irrelevant' and 'laborious'. basically you said now that you don't provide security info because it's labourious to backport fixes, or something like that. i'm afraid there's no such logical connection. you also didn't answer the question about why you should not make the life of people doing the actual backports (paid for, commercial, and how does that imply that you should not mark security fixes as such? remember, we're not discussing how backports are done in the world, but why you're helping them by withholding security information. because if you admit that you're not, then that's one less reason to withhold this info. cheers, PaX Team --
From: pageexec@freemail.hu You asked me why fixes are not relevant to users of older upstream non-dist kernels. And I answered that question. --
no you did not because that was not my question actually. i wasn't asking about 'older upstream non-dist kernels' but 'older kernels', regardless of their being of vanilla or distro or whatever variety. here it is again (you even quoted it above btw): "why aren't security fixes that you fix relevant to users of older kernels" it doesn't say 'distro'. in fact, i chose my words carefully as there seems to be a tendency among you guys where you simply ignore or don't care about the interests of several user groups. there's a whole world beyond Red Hat and Novell, and some of those people are very well capable of backporting fixes, so your 'it is too labourious to backport therefore we don't mark security fixes' argument is simply wrong (an in all honesty, it's not up to you guys to decide what people are capable or willing to backport, your responsibility should be to help them, no make decisions for them). if you want an inside voice, go ask the 2.4 maintainer. i quoted him already here already in fact: I don't like obfuscation at all WRT security issues, it does far more harm than good because it reduces the probability to get them picked and fixed by users, maintainers, distro packagers, etc... (http://lkml.org/lkml/2008/6/10/452) so what's the next 'justification' for covering up security bugs? cheers, PaX Team --
Do we not already do this today? I know I do this as soon as possible for any reported problem for the -stable tree, as soon as the fix is in Linus's tree. That's the extra work that you are saying we also need to do. Linus and others have already detailed why we don't do that. thanks, greg k-h --
very good example of how you actually do *not* do what you claim. find me the word 'security' in your announcement. it's not there. amazing, isn't it. despite what your fellow -stable maintainer claimed *he* would at least do (and regularly tries to do so in fact). despite what you yourself did on other occasions (remember 2.6.23.8?). what's wrong with you Greg? have you not been told and proven to cover up security bugs enough times already? cheers, PaX Team --
Huh? Have you read the announcement? If one do not understand from the
wording that this _is_ a security fix then he/she is stupid beyond hope.
And I see that the biggest difference between you and the kernel
developers: the kernel developers want you to _think_ whether that
particular patch is important for you or not. You on the other hand want
to be able to mindlessly apply patches marked as "security fix" without
any consideration about how all the other unfixed bugs can bite you.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
--
i understand what it is, i would understand it even if it said even less. what does this have to do with carefully avoiding the word 'security' on one hand and disclosing it on another? do you understand the word no you don't see it. you haven't even read or understood all the are you out of your mind? since when it is the job of users (meaning, users of commit logs) to reverse engineer what the heck the given commit was supposed to actually fix? do you think they don't have better use of their time? if there is a purpose of a commit message then it's that of informing the reader, not confusing or misleading where did i say that people should apply security fixes without considering other, unmarked fixes? i said the exact opposite which you would know if you had actually cared to read the thread in its entirety. udv, PaX Team --
No, it was a consious decision to do just to piss you off, glad to see it worked :) Come on, give me a break, Tiago asked that we do releases as soon as we know about a security problem. 2.6.25.11 was released because of this, and all users were told to upgrade. Is the fact that I add the magic word "security" in a sentance in the email some specific requirement that will make you happy? Take a look at the words I used, if someone can't determine if they should upgrade or not based on that, then they need to rely on a company to provide updates for them, and not be running their own kernels because they really have no clue about system management. Bah, what a joke. greg k-h --
it's not about making me happy Greg. i can figure these things out for myself, i do *not* need your help in that. there're many users however who rely on your providing accurate information. announcing a security fix as such is the proper thing to do, i can't imagine how you guys can dance around that simple fact for so long. just look at what your own employer does with security bugs, if they see it fit to mark them as such, how can you possibly argue that you're somehow acting in good faith when you cover them up? will you next tell your corporate bosses that they're bloody idiots that can't tell a bug from a bug and should just omit the word 'security' altogether from future announcements? i your carefully chosen words are *wrong* in fact. exploiting local bugs has nothing to do with having untrusted users in the age of client side exploits. due to your completely mischaracterized description, individual home users may very well feel that they do not need to upgrade, to the delight of the next malware owning their browser. you can congratulate you conveniently failed to respond to the rest of my mail where i showed that Chris Wright, heck, even yourself did announce security fixes as such and i thought i was the one getting pissed ;). cheer up, PaX Team --
No, I do not believe this is true, for this bug, sorry. If you disagree, please feel free to post such an exploit. Such a problem I am human and as such, word things differently at times. Based on crap like this thread, and from discussions with Linus and others, trying to classify such things as "security fixes" all the time isn't useful or helpful. Again, I still feel my original wording was sufficent. If you disagree, feel free to start releasing your own kernels with whatever wording you like. If people find them useful, perhaps they will use them instead of the ones I do at times. good luck, greg k-h --
what do you not believe in? that a task refcount leak can be exploited i never post exploits. however spender did write at least a proof-of-concept that triggers it and proves that it's potentially exploitable. writing a weaponized version takes a whole lot more effort than it's worth for us (though i bet others have been working on it ever since if they didn't what i said was *not* specific to this bug at all, any local privilege elevation bug can be used to, well, elevate privileges, regardless of how one gets into a box. the browser example was just that, to highlight that even single home user systems may very well be affected. sure, the browser bug is not your problem, but the local privilege elevation due to kernel bugs *is*. your wording was wrong, untrusted users are only *one* potential kind of threat therefore if only such systems update, why isn't it useful? i've been asking every one of you who said so and have yet to receive a reasonable justification. remember, your own employers do it 'all the time', it must be useful to someone. and what's with this 'all the time'? if you guys fix security bugs all the time, then yes, you are expected to announce them all the time. if you think that reflects badly on the quality of the kernel code, then maybe you should think over your development process that results in if you are not qualified to do this job then don't do it. noone forced you to accept this task. look at Chris Wright, he has no problems with disclosing the security issues and he actually publicly pledged to do his best to do so (and i hope he won't revert his position now). cheers, PaX Team --
News flash: You have no right to tell someone what to do --- or not to do. All you can get to make decisions on is what you choose to do yourself. If you want to compete with the very good job that Greg KH is doing, please feel free to do so. Otherwise, please go away and perhaps take some classes or do some meditating on how to work with other people in a more constructive fashion. - Ted --
but you have the right to tell me what rights i have. very smart ;) newsflash: try to parse the 'if... then' structure as not command in a sense, i've been doing that for many years now, years before -stable or even 2.6 was born. the result is in PaX, and unfortunately, it's become quite a sizable chunk of it, fixing various problems in yes, learning manners on this list is really the best advice you can give me. you mean, like this: http://lkml.org/lkml/2008/6/17/244 ? --
That world is not going to comply with your every whim should be perfectly clear by now. Please go spam some other list. P.S. You have a shift key. --
Look if you want this, pay $$$ to a distribution and get their supported distribution. It costs time and effort to classify bugs as security related (or not), and the people who care about this the most also want to freeze a kernel version to simplify their application testing, *but* get new drivers and bus support code back-ported so they can use the latest hardware (while still keeping their applications and 3rd party proprietary kernel modules from Nvidia and Vertias stable and working) *and* they want the latest security fixes (and only security fixes, since other fixes might destablize their application). People who want this can get it, today. Just pick up the phone and give a call to your favoriate enterprise Linux distribution. It will cost you money, but hey, the people who want this sort of thing typically are willing to pay for the service. I'll note that trying to classify bugs as being "security-related" at the kernel.org level often doesn't help the distro's, since many of these bugs won't even apply to whatever version of the kernel the distro's snapshotted 9-18 months ago. So if the distro snapshotted 2.6.18 in Fall 2006, and their next snapshot will be sometime two years later in the fall of this year, they will have no use for some potential local denial of service attack that was introduced by accident in 2.6.24-rc3, and fixed in 2.6.25-rc1. It just doesn't matter to them. So basically, if there are enough kernel.org users who care, they can pay someone to classify and issue CVE numbers for each and every potential "security bug" that might appear and then disappear. Or they can volunteer and do it themselves. Of course, this will provide aid and comfort to Microsoft-shills masquerading as analysts who misuse CVE numbers to generate reports "proving" that Microsoft is more secure (because they don't do their development in the open, so issues that appear and disappear in development snapshots don't get CVE numbers assigned), but hopefully most ...
That's fallacious. Assuming that you have good programmers, and you do, it's of very low cost the act of identifying what *is likely to be* a security bug. In most cases, they are easy to spot. And, hey, we are not asking for an absurd amount of care. You must not pay $200 /hour for someone to review your software. All I, personally, ask for is that the basic attention is given. With this simple act, I'm sure you would cover So, only those willing to pay have the right of respect? Because, you see, this is rather a matter of respect with those who choose to use your solution. And, no, the "free will" argument does not qualify I don't follow what you have just said. What is the problem with I think, CVE registration or the alike would be too much for what I call "act of decency". A single parenthesis note on the bug itself would be of great help and of small effort. --t --
You keep using that word. I do not think it means what you think it means. How about respecting my opinion instead? But no, you claim I must respect you, because you have some other notion of what should be done, even though I've explained why I don't agree. It cuts both ways. Linus --
This is not a question of ideology or taste. It is a practical matter that is supported by what has been, far from just "pure reasoning", argued. Sad that you can't, for whatever reason, see it and I will not push you any further. Have a good night. --t --
Oh, so only your opinion matters? And only _your_ "practical matters" is what people should care about? Yes, master. Linus --
Nah, just follow what was pointed out by "pageexec": it's the world that claims for security measures. Enough said. It's your project. Do with it whatever you find the better. Best wishes, --t --
That is based on lots and lots of assumptions that are just not true. Ted Tso, Stephen Smalley and I are all recognized as security experts and we can't even agree on whether sockets are objects or not, much less what constitutes a security bug and even less what is likely to be a security bug. Goodness, there are some of us who would argue that since DNS is itself a security bug it is just not possible for Err, no, in the kernel environment a real security flaw is likely to --
You do not hesitate in categorizing yourself as something as obscure as... what's that term again? "Expert". But then you fail on basic pragmatism when attempting to define what, nearly always, is a true or false question? Jeez ;) --t --
I would suggest you maintain your own kernel version, since you're so obviously more competent at it than we are. Then, when you inevitably show your superiority, people will start using your version of the kernel. That's the point of open source, after all. It keeps us all honest - at any point, we can be overtaken by somebody better. I've actually been waiting for this moment for over fifteen years now: finding that person who can take over so that I don't have to bother any more. I'll continue to do my own maintenance in parallel while you get up to speed, but I expect that everybody will have dropped my feeble efforts soon enough, so you can probably just ignore that. Thanks, Linus --
Raising an honest question and following with one, not less sincere, No, thank you. I'll stick up with poetry. --t --
No, you must be more competent that everybody you talk to, since you seem to always know the answers and can dismiss their concerns. That's all I tried to say, Linus --
Actually, I always hesitate before calling myself an expert, in spite of the credentials I have to back the title. Too many people seem to think that if you disagree with their HeeHeeHee. Security questions are almost never true or false, black or white, on or off. SPAM is *the* major computer security issue and it has nothing at all to do with computers or security. Is a use of strcpy() a security vulnerability? Sure it can be, but in reality it almost never is, but the hysteria associated It's not so bad. We'll be OK. Really. --
not so quick. security is a big field, noone really can claim to be a general expert. Ted knows kerberos but he would be unable to exploit the task refcount leak bug fixed in 2.6.25.10. Stephen and you know MAC systems inside out but you too would be unable to exploit that bug. different domains, different expertise, despite all being 'security'. and it's utterly irrelevant to the next hacker that will own your precious MAC by exploiting a kernel bug that you 'experts' didn't deem important enough to tell the world about. do you understand that we've been talking about *kernel* bugs here? do you understand what privilege elevation is? you surely do since you work with MAC systems all the time whose purpose privilege elevation bugs are security bugs, no ifs and buts. whether a given bug can be exploited at that level is a different question, and if you can't make that judgement you're welcome to err on the side of safety (i.e., have people upgrade/backport rather than be possibly exposed) or bring in help it's all very much irrelevant to local kernel security that we're talking i don't have stats about 'most' vs 'likely', but yes, they can indeed be subtle, that's why you should not be overly optimistic and dismiss potentially exploitable bugs as not relevant and cover them up. cheers, PaX Team --
As far as I am concerned, knowing how to exploit a task refcount leak bug is a technician's job. Sure, I can write code that given an intercepted or stolen Kerberos srvtab/ketab file, how to forge Kerberos tickets. But at the end of the day, that's perhaps the least important part of what a "Security Expert" has to do. Bruce Schneier has written about this extensively. The important thing to recognize about security is that it is all about tradeoffs. How do you protect the System (which may consist of one computers or multiple computers) given a particular threat environment, given adversaries with different levels of capability, given the consequences of a security breach, and how do you do it within a given parameters of cost and usability? What a security expert might do is laugh at someone who is spending all of their time and energy worrying about local escalation attacks, when they discover that all of the network exchanges are unprotected and on an insecure network. Or, they might point out that you are spending 10 times as much money and effort on securing a system as the cost of a security breach, and that might not make sense either. This is why there are so many arguments over security. There are disagreements over what deserves more focus and attention, and what is and isn't worthwhile trading off against other things. For example, last I looked, PaX significantly reduces the chance of buffer overrun attacks, but at the cost of cutting your address space in half and forcing you to use a custom-built kernels since modules are not supported either (which means no tools like Systemtap, as well). For some people, particularly on 32-bit systems, this is unacceptable. But some people might consider that a valid tradeoff. As another example, take for example some bug that might be able to cause a local privilege escalation. If the machine running that particular kernel is part of a computing cluster which is totally disconnected from the Internet, that ...
you can try to downplay it like that, but it doesn't make it a simple technician's job (go tell that to the NSA's red team members ;). exploit development is an art, it's an expertise that you can't acquire in formal education for example. that holds for many other aspects of computer security in fact, that's why it's not an engineering discipline in any sense that civil or mechanical engineering is. let's wait a few more decades or centuries, and it will probably become one, but not today. the reason i mentioned exploit development is actually that if you are not aware of how you can exploit a bug, you're likely to make a bad judgement call when you have to decide a bug's exploitability. *that* what is important depends on the situation. for a pentester it's quite we have a simpler description for the purpose of security: it's all about risk management. risk management is indeed about making decisions that often involve tradeoffs. the responsibility of kernel developers is, or should be, if it isn't, to help such decisions by not covering actually, if we're talking 2.6, that's not true anymore, PaX will use the hw NX bit if present, else it will fall back to the segmentation based method. also, there's been module support for years now, in fact it's better than that of vanilla in that i added proper separation of not necessarily, it depends on who has local access to that cluster and whether they separate privileges or not. say, if the admin/user roles are separate, then it's very much relevant there as well. sure, in fact, in this day and age of client side bugs (think browsers, media players, etc), it is even more relevant. not because as if acquiring normal user privileges didn't already break the given user's security, but because by elevating to root, an attacker reduces his risk of being discovered, not to mention gaining access to both the wife's and the husband's emails at once. FWIW, i'm told that there's windows malware that uses 0-day for both browser ...
oh, we're back to that. i told you that already, here it is again (just quoting myself back): when you fix a bug, the commit describes what it fixes without omitting anything relevant. when you fix a security bug, its commit doesn't say what it fixes (not even that it's a security fix, never mind actual impact information), that is, you omit relevant information (based on some ill-conceived argument that i deconstructed at the beginning). in other words, you're *not* treating security bugs as normal bugs. for all intents and purposes, you cover them up. i *wish* you did treat them as normal bugs however. we went through this and you yourself said that security bugs are *not* treated as normal bugs because you do omit relevant information from such commits whereas you do *not* omit relevant information from normal commits. for security bugs the fact that they fix a security issue is relevant repeating the same thing doesn't make the self-contradiction above go away. bugs are properly described in the commits, security bugs aren't (you said so yourself), therefore they can't be of the same category. what you're still trying to justify is why you are covering up security why would people think that unmarked bugfixes are less important? who are you to make that judgement for them anyway? the importance of bugs is *orthogonal* to their classification (security, etc). it's up to the people and their decision making processes to deal with that. all you should do is help them by not withholding relevant information. in case it wasn't clear, i'm not talking about just about any person like my grandma, but people whose work involves following kernel development, who can use all the extra information to make judgement calls about what to prioritize. they're certainly not dumb and would not think that only commits marked it's not a myth, it's called reality. a bugfix that gets my pc speaker beep again is very different from a fix that stops the tcp/ip stack ...
Actually, we disagree on one fundamental thing. We disagree on that single word: "relevant". I do not think it's helpful _or_ relevant to explicitly point out how to tigger a bug. It's very helpful and relevant when we're trying to chase the bug down, but once it is fixed, it becomes irrelevant. You think that explicitly pointing something out as a security issue is really important, so you think it's always "relevant". And I take mostly the opposite view. I think pointing it out is actually likely to be counter-productive. For example, the way I prefer to work is to have people send me and the kernel list a patch for a fix, and then in the very next email send (in private) an example exploit of the problem to the security mailing list (and that one goes to the private security list just because we don't want all the people at universities rushing in to test it). THAT is how things should work. Should I document the exploit in the commit message? Hell no. It's private for a reason, even if it's real information. It was real information for the developers to explain why a patch is needed, but once explained, it shouldn't be spread around unnecessarily. Linus --
nor did i say that (actually, what i said is that it didn't belong into you're wrong on that however. it is important for many people to able to perform the same verification that you do. just imagine the backports to versions that you don't do yourselves. but organizing the dissemination don't mistake my presence in this thread as me, an invidual arguing for his own benefit. i already know when you fix security bugs, even when you don't sometimes. so when i say something is relevant, it's not merely my opinion, it's what most people dealing with security issues (both inside and outside agreed (with the same additonal thoughts as above on the trigger code). ok, so let's make it simpler for everyone to understand what is at issue here. it seems that we agree that there're several levels of information that exist when it comes to security bugs and we don't understand each other as to what should go into a commit and what should stay out. let me propose a categorization and you tell me what you think you would be willing to put into a commit (feel free to break them up further if that's what it takes). 1. simple words/phrases that one can grep for (mentally or automated) examples: 'security', 'exploitable', 'DoS', 'buffer overflow', etc 2. simple sentence describing roughly what kind of security bug it is example: fix exploitable null function pointer dereference in foo. 3. sample code able to trigger the bug and cause an oops/crash but not privilege elevation, no effort made to be 'weapons grade' (does not support several archs, kernel versions, etc) 4. proof-of-concept exploit that triggers the bug, and demonstrates its effect (say privilege elevation) with manual tweaking (say, you look up an address in System.map and the like, but nothing automated) 5. full blown weaponized exploit i believe 3-5 are definitely not commit message material. 1 or 2 are. 5 should never be published or disseminated, 3 and 4 may be distributed to ...
Oh, so now you're suddenly fine with not doing "full disclosure"? Just a few emails ago you berated me for not doing full disclosure, but now you're saying it is fine? Can you now admit that it's a gray line, and that we just have very 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 And I believe you now at least understand the difference. I draw the line between 0 and 1, where 0 is "explain the fix" - which is something that any - and every - commit message should do. Linus --
you didn't pay attention to me very well. i said a few times in this thread already that i did *not* care what disclosure policy you choose for the kernel security bugs, that's none of my business. what i (and many others) do care about is that you follow through that choice. as it is, you supposedly practice full disclosure, whether you know what that term means or not, it does mean something very specific for people with a security background and you most certainly do *not* practice it. *that* is what i was complaining about - inconsistency between your words and actions. i even told you that you can solve it two ways: change one or the other. that is, you can begin to practice full disclosure (or as we figured it out slowly, some form of disclosure at least as what you turned out to be doing can best be described as no disclosure or less affectionately, coverup), *or* you can declare (=let the world know) that you do *not* practice any disclosure, certainly not full disclosure at fair enough, that's another way to say 'i cover them up'. at least we got that out in the clear, thank you. you would have saved a lot of time if you had declared this somewhere in the kernel docs. it's still not too late and would be the prudent thing to do, there're *many* people living under the yes, perfectly clear. as i said, the disclosure policy (whether you call it that or not) is your choice. please make it public somewhere. cheers and good night, PaX Team --
Hey, I have a crazy idea! What if they just mark all the bugs as a security bug (after all they all kinda are for some definition of security anyway)? That way people just apply all the patches and do not have to analyze anything, therefore not wasting their limited human resources at all! Linus' point is exactly that they shouldn't be treated differently, so you shouldn't allocate human resources to other bugs and just apply the security ones. If you want to convince someone you must tell us *why* those so-called security bugs are more important. Also, you need to tell --
look at what went into 2.6.25.11 for example. it's a security fix. you do treat them differently: you include them in -stable to the exclusion of many other 'less important' fixes. read Documentation/stable_kernel_rules.txt for how you not treat all fixes as equal (it's not only security ones that anything that breaks the kernel's security model. privilege elevation always does. --
