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
--

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.
--

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

--

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 sending ...
[ message continues ]

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 interested p...
[ message continues ]

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
--

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
--

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 users a...
[ message continues ]

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
--

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
--

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 bug i...
[ message continues ]

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 exploita...
[ message continues ]

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

--

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.
--

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

--

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

--

what free marketing are you talking about?
--

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
--

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
--

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
--

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.
--

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 ?
--

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
--

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

--

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
--

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

--