On Tue, 15 Jul 2008, [email protected] wrote:
>
> in any case, i don't see why you can't put keywords into the commit
> that say the bug being fixed is 'security related' or 'potentially
> exploitable', etc. people can then decide how to prioritize them.
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
On 15 Jul 2008 at 13:18, Linus Torvalds wrote:
>
>
> On Tue, 15 Jul 2008, [email protected] wrote:
> >
> > in any case, i don't see why you can't put keywords into the commit
> > that say the bug being fixed is 'security related' or 'potentially
> > exploitable', etc. people can then decide how to prioritize them.
>
> 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.
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 [email protected] 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
On Tue, 15 Jul 2008, [email protected] wrote:
>
> 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
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
On 15 Jul 2008 at 13:42, Linus Torvalds wrote:
> On Tue, 15 Jul 2008, [email protected] wrote:
> >
> > 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
>
> 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.
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
On Tue, 15 Jul 2008, [email protected] wrote:
>
> and how is that different from today's situation where they aren't told
> at all?
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
On 15 Jul 2008 at 14:26, Linus Torvalds wrote:
>
>
> On Tue, 15 Jul 2008, [email protected] wrote:
> >
> > and how is that different from today's situation where they aren't told
> > at all?
>
> Umm. They are. They are told to upgrade to the stable kernel, which
> should have everything we know about.
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
fixing a security issue.
> I'm just saying that why mark things, when the marking have no meaning?
> People who believe in them are just _wrong_.
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
On Wed, 16 Jul 2008, [email protected] wrote:
>
> 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
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,
because bugs are bugs.
> in other words, it's all the more reason to have the commit say it's
> fixing a security issue.
No.
> > I'm just saying that why mark things, when the marking have no meaning?
> > People who believe in them are just _wrong_.
>
> what is wrong in particular?
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
matter.
> 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?
It's pointless and wrong because it makes people think that other bugs
aren't potential security fixes.
What was unclear about that?
Linus
Linus Torvalds wrote:
>
> On Wed, 16 Jul 2008, [email protected] wrote:
>> 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
>
> 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,
> because bugs are bugs.
>
>> in other words, it's all the more reason to have the commit say it's
>> fixing a security issue.
>
> No.
>
>>> I'm just saying that why mark things, when the marking have no meaning?
>>> People who believe in them are just _wrong_.
>> what is wrong in particular?
>
> 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
> matter.
>
>> 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?
>
> 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
On 15 Jul 2008 at 16:28, Linus Torvalds wrote:
> On Wed, 16 Jul 2008, [email protected] wrote:
> >
> > 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
>
> Umm. What part of "they are just normal bugs" did you have issues with?
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
information.
> I expressly told you that security bugs should not be marked as such,
> because bugs are bugs.
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
bugs, plain and simple.
> > > I'm just saying that why mark things, when the marking have no meaning?
> > > People who believe in them are just _wrong_.
> >
> > what is wrong in particular?
>
> 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.
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
as such are security related.
> - People don't think it matters
>
> People are right, and the marking is pointless.
you have yet to prove why it's pointless. the above attempt failed to do so.
> 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".
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 out
random kernel memory to the net (just made them up, before anyone starts
looking). you're desperately trying to ignore the importance of security
bugs but you're failing. the world has decided that security bugs *are*
important and deserve special attention. and it's not as if you had to do
any extra work, you already have the information, you should just not
*withhold* it.
> They're all fixes. They're all important. As are new features, for that
> matter.
'importance' is not a big grey goo that applies equally to all fixes. you
want to make it appear so, but that doesn't make it so.
> > 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?
>
> It's pointless and wrong because it makes people think that other bugs
> aren't potential security fixes.
why does it make people think that? did you ask them? what if you told them
as i suggested (and you conveniently skipped) what to expect? do you think
people dealing with kernel maintenance at companies, distros, etc are that
dumb?
cheers,
PaX Team
On Tue, 15 Jul 2008, Tiago Assumpcao wrote:
>
> 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.
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
weren't involved, we didn't see that, we simply _cannot_ care.
> 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.
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
On Wed, 16 Jul 2008, [email protected] wrote:
>
> 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
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
Linus Torvalds wrote:
>
> On Tue, 15 Jul 2008, Tiago Assumpcao wrote:
>> 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.
>
> Umm. That shouldn't be our worry.
Yeah, at this point, it is clear to the world. No needs for repeated
wording ;)
> If others had a long and involved (and broken) process, they should be the ones that track the fixes too. We
> weren't involved, we didn't see that, we simply _cannot_ care.
You weren't involved? Hold on, aren't you the developers, thence, those
who commit mistakes, a.k.a the bug inducing point?
>
>> 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.
>
> Umm. What was wrong with 20 years ago exactly?
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.
I apologize for assuming you hold such information, anyway.
>
> 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?
Are you trying to justify your irresponsibly indulgent act towards the
operating system that my mother is likely to use with one alone
exception? Because it rains umbrellas are a waste of time?
>
> 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
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
On Tue, 15 Jul 2008, Tiago Assumpcao wrote:
>
> You weren't involved? Hold on, aren't you the developers, thence, those who
> commit mistakes, a.k.a the bug inducing point?
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?
That's what you claimed we should do, wasn't it?
> 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.
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
On 15 Jul 2008 at 17:24, Linus Torvalds wrote:
> On Wed, 16 Jul 2008, [email protected] wrote:
> >
> > 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
>
> Actually, we disagree on one fundamental thing. We disagree on
> that single word: "relevant".
we'll see :)
> I do not think it's helpful _or_ relevant to explicitly point out how to
> tigger a bug.
nor did i say that (actually, what i said is that it didn't belong into
the commit message, see below for more).
> It's very helpful and relevant when we're trying to chase
> the bug down, but once it is fixed, it becomes irrelevant.
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
of such code is not what i've been talking about all this time.
> You think that explicitly pointing something out as a security issue is
> really important, so you think it's always "relevant".
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
the linux universe) think. with that said, let's move on:
> And I take mostly the opposite view. I think pointing it out is
> actually likely to be counter-productive.
you keep saying that, but you don't explain *why*.
> 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.
fine with me, i wasn't talking about that at all though ;).
> Should I document the exploit in the commit message? Hell no.
fully understood and agreed. never even asked for that.
> 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.
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 parties.
cheers,
PaX Team
On Wed, 16 Jul 2008, [email protected] wrote:
>
> > And I take mostly the opposite view. I think pointing it out is
> > actually likely to be counter-productive.
>
> you keep saying that, but you don't explain *why*.
>
> > 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.
>
> fine with me, i wasn't talking about that at all though ;).
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
different opinions of where the line is drawn?
> 1. simple words/phrases that one can grep for (mentally or automated)
> examples: 'security', 'exploitable', 'DoS', 'buffer overflow', etc
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.
> 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 parties.
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
On Tue, Jul 15, 2008 at 09:00:19PM -0300, Tiago Assumpcao wrote:
> 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.
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 are sophsitcated
enough not to get taken in by that kind of bogus study. :-)
The one thing which is really pointless to do is to ask kernel
developers to do all of this classification work to get CVE numbers,
etc., for free. In free software, people do what they (or their
company) deem to be valuable for them. Flaming and complaining that
the kernel git logs aren't providing free marketing for PaX/grsecurity
isn't going to do much good.
- Ted
Linus Torvalds wrote:
>
> 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?
>
> That's what you claimed we should do, wasn't it?
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
bothering, though.
>
>> 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.
>
> My responsibility is to do a good job. And not pander to the people who
> want to turn security into a media circus.
And I thank you for that. No to the "security media circus".
>
> Which is exactly what I'm doing. No media circus.
>
> Linus
>
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
On Tue, 15 Jul 2008, Tiago Assumpcao wrote:
>
> How can I expect one to treat the unknown? If you are not aware of it, you do
> nothing.
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
really irritates me.
> 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.
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
On 15 Jul 2008 at 18:08, Linus Torvalds wrote:
> On Wed, 16 Jul 2008, [email protected] wrote:
> >
> > > And I take mostly the opposite view. I think pointing it out is
> > > actually likely to be counter-productive.
> >
> > you keep saying that, but you don't explain *why*.
> >
> > > 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.
> >
> > fine with me, i wasn't talking about that at all though ;).
>
> 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
> different opinions of where the line is drawn?
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
least.
> > 1. simple words/phrases that one can grep for (mentally or automated)
> > examples: 'security', 'exploitable', 'DoS', 'buffer overflow', etc
>
> 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.
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
assumption that you don't actually do this.
> 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.
>
> > 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 parties.
>
> 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.
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
On 15 Jul 2008 at 21:08, Theodore Tso wrote:
> Flaming and complaining that the kernel git logs aren't providing free
> marketing for PaX/grsecurity isn't going to do much good.
what free marketing are you talking about?
Theodore Tso wrote:
> 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), (...)
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
the majority of the bugs.
> It will cost you money, but hey, the people who want
> this sort of thing typically are willing to pay for the service.
>
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
herein. My mother is not aware of your absurd acts.
> 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.
I don't follow what you have just said. What is the problem with
"versioning" and the strictness of its relation to bugs, security or not?
>
> 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.
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
On Tue, 15 Jul 2008, Tiago Assumpcao wrote:
>
> So, only those willing to pay have the right of respect?
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
Linus Torvalds wrote:
>
> 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
> really irritates me.
>
Again, not asking for what you can not provide. You must, however, do
your part.
> 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.
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
the end point.
>
> 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.
>
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
scenario; the one that you cultivate?
> 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!
>
Just mark it. No big deal.
>
> I would not actually be helping you. I'd be helping the people you want to
> protect against!
>
> Linus
>
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
Linus Torvalds wrote:
>
> 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.
>
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
On Tue, Jul 15, 2008 at 11:24:25PM -0300, Tiago Assumpcao wrote:
>> 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.
>
> 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
> the end point.
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
On Tue, Jul 15, 2008 at 10:10:19PM -0300, Tiago Assumpcao wrote:
>
> 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.
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.
See the 2.6.25.11 release for an example of this.
> Plus, if one bothers, to be able to know the exact location of this bug and
> its characteristics.
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
Tiago Assumpcao wrote:
> Theodore Tso wrote:
>> 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), (...)
>
> 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.
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
DNS to have a security bug, as an example.
> In most cases, they are easy to spot.
Err, no, in the kernel environment a real security flaw is likely to
be pretty subtle.
> 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 the majority of the bugs.
>
>> It will cost you money, but hey, the people who want
>> this sort of thing typically are willing to pay for the service.
>>
>
> 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
> herein. My mother is not aware of your absurd acts.
>
>> 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.
>
> I don't follow what you have just said. What is the problem with
> "versioning" and the strictness of its relation to bugs, security or not?
>
>>
>> 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.
>
> 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
>
>
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
On Tue, 15 Jul 2008, Tiago Assumpcao wrote:
>
> This is not a question of ideology or taste.
Oh, so only your opinion matters? And only _your_ "practical matters" is
what people should care about?
Yes, master.
Linus
Casey Schaufler wrote:
> 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
> DNS to have a security bug, as an example.
>
>> In most cases, they are easy to spot.
>
> Err, no, in the kernel environment a real security flaw is likely to
> be pretty subtle.
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
Linus Torvalds wrote:
> Oh, so only your opinion matters? And only _your_ "practical matters" is
> what people should care about?
>
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
On Wed, 16 Jul 2008, Tiago Assumpcao wrote:
>
> 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?
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
Linus Torvalds wrote:
> I would suggest you maintain your own kernel version, since you're so
> obviously more competent at it than we are.
Raising an honest question and following with one, not less sincere,
debate makes me all that competent? I don't understand.
> 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
>
No, thank you. I'll stick up with poetry.
--t
On Wed, 16 Jul 2008, Tiago Assumpcao wrote:
>
> Raising an honest question and following with one, not less sincere, debate
> makes me all that competent? I don't understand.
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
Tiago Assumpcao wrote:
> Casey Schaufler wrote:
>> 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
>> DNS to have a security bug, as an example.
>>
>>> In most cases, they are easy to spot.
>>
>> Err, no, in the kernel environment a real security flaw is likely to
>> be pretty subtle.
>
> You do not hesitate in categorizing yourself as something as obscure
> as... what's that term again? "Expert".
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
point of view you can't know what you're talking about.
> But then you fail on basic pragmatism when attempting to define what,
> nearly always, is a true or false question?
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
with buffer overruns gave it a bad oder.
> Jeez ;)
It's not so bad. We'll be OK. Really.
On 15 Jul 2008 at 20:13, Greg KH wrote:
> On Tue, Jul 15, 2008 at 10:10:19PM -0300, Tiago Assumpcao wrote:
> >
> > 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.
>
> 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.
>
> See the 2.6.25.11 release for an example of this.
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
On 15 Jul 2008 at 20:27, Casey Schaufler wrote:
> Tiago Assumpcao wrote:
> > Theodore Tso wrote:
> >> 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), (...)
> >
> > 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.
>
> 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
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'.
with that foreword:
> and we can't even agree on whether sockets are objects or not,
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
is, well, access control.
> much less what constitutes a security bug and even less what is likely to
> be a security bug.
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
(if Microsoft can pay people to do that, so can commercial Linux companies).
> Goodness, there are some of us who would argue
> that since DNS is itself a security bug it is just not possible for
> DNS to have a security bug, as an example.
it's all very much irrelevant to local kernel security that we're talking
about.
> > In most cases, they are easy to spot.
>
> Err, no, in the kernel environment a real security flaw is likely to
> be pretty subtle.
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
On Wed, Jul 16, 2008 at 11:01:51AM +0200, [email protected] wrote:
> 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?
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
---------------------------------------------------------
On 15 Jul 2008 at 18:41, Linus Torvalds wrote:
> On Tue, 15 Jul 2008, Tiago Assumpcao wrote:
> > 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.
>
> 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.
how do you *know*?
> 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.
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
if you do that on every single fix you commit.
> 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.
correct, but also irrelevant, see below.
> 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!
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
about before.
> 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!
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
On 16 Jul 2008 at 11:35, Gabor Gombas wrote:
> On Wed, Jul 16, 2008 at 11:01:51AM +0200, [email protected] wrote:
>
> > 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?
>
> 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.
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
'consistency' or are you 'stupid beyond hope'?
> And I see that the biggest difference between you and the kernel
> developers:
no you don't see it. you haven't even read or understood all the
discussion else you would not be making stupid claims as below:
> the kernel developers want you to _think_ whether that
> particular patch is important for you or not.
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
him.
> You on the other hand want
> to be able to mindlessly apply patches marked as "security fix"
what is mindless about applying a security fix?
> without
> any consideration about how all the other unfixed bugs can bite you.
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
From: [email protected]
Date: Wed, 16 Jul 2008 11:49:45 +0200
> 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
> if you do that on every single fix you commit.
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.
On 16 Jul 2008 at 3:08, David Miller wrote:
> From: [email protected]
> Date: Wed, 16 Jul 2008 11:49:45 +0200
>
> > 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
> > if you do that on every single fix you commit.
>
> Many people who do kernel development do exactly this for the vendor
> they work for.
i know that. but you conveniently skipped what i was replying to, here
it is for proper context:
> IOW, when we fix security issues, it's simply not even appropriate or
> relevant to you.
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
companies that can afford this kind of cost.
> 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.
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: [email protected]
Date: Wed, 16 Jul 2008 12:23:50 +0200
> On 16 Jul 2008 at 3:08, David Miller wrote:
>
> > IOW, when we fix security issues, it's simply not even appropriate or
> > relevant to you.
>
> 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)?
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.
On 16 Jul 2008 at 3:31, David Miller wrote:
> From: [email protected]
> Date: Wed, 16 Jul 2008 12:23:50 +0200
>
> > On 16 Jul 2008 at 3:08, David Miller wrote:
> >
> > > IOW, when we fix security issues, it's simply not even appropriate or
> > > relevant to you.
> >
> > 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)?
>
> Backporting any fix to older kernels is a chore, the further back you
> go, the harder and less fun it is.
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,
whatever the trigger word for you is) easier.
> 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 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: [email protected]
Date: Wed, 16 Jul 2008 12:51:31 +0200
> On 16 Jul 2008 at 3:31, David Miller wrote:
>
> > From: [email protected]
> > Date: Wed, 16 Jul 2008 12:23:50 +0200
> >
> > > On 16 Jul 2008 at 3:08, David Miller wrote:
> > >
> > > > IOW, when we fix security issues, it's simply not even appropriate or
> > > > relevant to you.
> > >
> > > 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)?
> >
> > 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 how does that imply that you should not mark security fixes as such?
You asked me why fixes are not relevant to users of older upstream
non-dist kernels. And I answered that question.
On 16 Jul 2008 at 4:04, David Miller wrote:
> From: [email protected]
> Date: Wed, 16 Jul 2008 12:51:31 +0200
>
> > On 16 Jul 2008 at 3:31, David Miller wrote:
> >
> > > From: [email protected]
> > > Date: Wed, 16 Jul 2008 12:23:50 +0200
> > >
> > > > On 16 Jul 2008 at 3:08, David Miller wrote:
> > > >
> > > > > IOW, when we fix security issues, it's simply not even appropriate or
> > > > > relevant to you.
> > > >
> > > > 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)?
> > >
> > > 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 how does that imply that you should not mark security fixes as such?
>
> 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
On Wed, Jul 16, 2008 at 11:33:12AM +0200, [email protected] wrote:
> > > 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.
> >
> > 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
>
> 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'.
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 is from a security point of
view totally irrelevant.
So to do a true security analysis about the seriousness of a bug
*always* requires some amount of context about what the capabilities
that the adversary might have (or might have acquired). Given that
most systems these days are single user systems, a local privilege
escalation attack may not be as big a of deal in this day and age.
Many people draw their trust boundary around the entire computer.
At the end of the day, it is an engineering discipline, and it is all
about tradeoffs. So while it is useful to have people who focus on
the security of a single box against adversaries who have local shell
access, it is very easy to lose perspective of the greater security
picture. And someone like Linus who is worried about the overall
system, it's even easier to lose perspective. Consider that there was
only one computer system that to my knowledge, ever managed to get
evaluated as passing the Orange Book A1 security requirements; and
that system was a commercial failure. It took too long to bring to
market, it was too slow, and was too expensive. It would be like
people assuming that you could always build a tank by putting more
armor on it, and that there is no such thing as "too much armor".
Same principle.
I have a theory which is that people who are focused on local system
security to the exclusion of all else have a high risk of becoming
unbalanced; they end up like Theo de Rant, frustrated because people
aren't paying attention to them, and that others aren't worried about
the same problems that they think are important. But, the good news
of open source is that if you *do* care about local system security to
the exclusion of all else, including high SMP scalability, and wide
hardware support, etc., you can go use OpenBSD! They may be much more
your type of people. Or, you can pay for support for an enterprise
Linux distribution, where they do have people who will help you out
for it. Hopefully their idea of security and priorities matches up
with your own, although I will note that some of the companies that
have focused exclusively on security to the exclusion of all else
(e.g. Trustix AS, Immunix) haven't necessarily done very well
commercially.
Regards,
- Ted
On Wed, Jul 16, 2008 at 11:01:51AM +0200, [email protected] wrote:
> On 15 Jul 2008 at 20:13, Greg KH wrote:
>
> > On Tue, Jul 15, 2008 at 10:10:19PM -0300, Tiago Assumpcao wrote:
> > >
> > > 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.
> >
> > 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.
> >
> > See the 2.6.25.11 release for an example of this.
>
> 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.
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
On 16 Jul 2008 at 7:43, Greg KH wrote:
> On Wed, Jul 16, 2008 at 11:01:51AM +0200, [email protected] wrote:
> > On 15 Jul 2008 at 20:13, Greg KH wrote:
> >
> > 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.
>
> 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?
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
didn't think so either.
> Take a look at the words I used, if someone can't determine if they
> should upgrade or not based on that,
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
yourself Greg, you successfully misled a whole class of users.
> 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.
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
in the past. how do you explain that?
> Bah, what a joke.
and i thought i was the one getting pissed ;).
cheer up,
PaX Team
On 16 Jul 2008 at 9:21, Theodore Tso wrote:
> On Wed, Jul 16, 2008 at 11:33:12AM +0200, [email protected] wrote:
> > 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'.
>
> As far as I am concerned, knowing how to exploit a task refcount leak
> bug is a technician's job.
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*
will have bad effects on everyone else depending on your judgement.
> 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.
what is important depends on the situation. for a pentester it's quite
important to be able to write exploits for example.
> 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?
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
up security fixes.
> 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.
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
rx/rw mappings for modules.
> 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 is from a security point of
> view totally irrelevant.
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,
the threat model is different, but it doesn't mean it's non-existent.
> So to do a true security analysis about the seriousness of a bug
> *always* requires some amount of context about what the capabilities
> that the adversary might have (or might have acquired). Given that
> most systems these days are single user systems, a local privilege
> escalation attack may not be as big a of deal in this day and age.
> Many people draw their trust boundary around the entire computer.
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 exploitation and local privilege
escalation, there's no reason to believe that the same cannot occur
on linux or elsewhere.
> At the end of the day, it is an engineering discipline, and it is all
> about tradeoffs. So while it is useful to have people who focus on
> the security of a single box against adversaries who have local shell
> access, it is very easy to lose perspective of the greater security
> picture.
i'm not sure if you're thinking of me as who's losing focus, but let
me tell you why you can't just so easily separate local from remote
bugs. in this age of networks, we do not simply have computer networks,
we also have trust networks. if you have a shell account at mit.edu,
then someone elevating to root there will be able to trigger a client
side ssh bug on your personal box (just an example, don't go looking
for one). in other words, locally exploitable bugs != single box
security.
> I have a theory which is that people who are focused on local system
> security to the exclusion of all else have a high risk of becoming
> unbalanced;
why does asking kernel developers to describe security fixes as such
risk becoming unbalanced?
cheers,
PaX Team
On Wed, Jul 16, 2008 at 05:43:15PM +0200, [email protected] wrote:
> > Take a look at the words I used, if someone can't determine if they
> > should upgrade or not based on that,
>
> your carefully chosen words are *wrong* in fact.
I do not think so, but you are free to disagree.
> 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 yourself Greg, you
> successfully misled a whole class of users.
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
would be a browser issue, and totally out of scope for a kernel issue.
> > 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.
>
> 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
> in the past. how do you explain that?
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
On 16 Jul 2008 at 9:29, Greg KH wrote:
> On Wed, Jul 16, 2008 at 05:43:15PM +0200, [email protected] wrote:
> > 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 yourself Greg, you
> > successfully misled a whole class of users.
>
> No, I do not believe this is true, for this bug, sorry.
what do you not believe in? that a task refcount leak can be exploited
for privilege elevation?
> If you disagree, please feel free to post such an exploit.
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
already write one when the bug got introduced).
> Such a problem
> would be a browser issue, and totally out of scope for a kernel issue.
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,
many others will remain vulnerable.
> > > 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.
> >
> > 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
> > in the past. how do you explain that?
>
> 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.
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
security fixes 'all the time'.
> 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.
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
On Wed, Jul 16, 2008 at 07:25:17PM +0200, [email protected] wrote:
> 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).
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
On 16 Jul 2008 at 14:08, Theodore Tso wrote:
> On Wed, Jul 16, 2008 at 07:25:17PM +0200, [email protected] wrote:
> > 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).
>
> News flash: You have no right to tell someone what to do --- or not to
> do.
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
but conditional.
> 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.
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
linux.
> 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.
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 ?
On Wed, 2008-07-16 at 19:25 +0200, [email protected] wrote:
> > 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.
>
> 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).
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.
[email protected] wrote:
> On 15 Jul 2008 at 13:42, Linus Torvalds wrote:
>
>> On Tue, 15 Jul 2008, [email protected] wrote:
>>> 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
>> 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.
>
> 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.
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
us what you consider to be a security bug. That's not clear to me at least.
> 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
On 17 Jul 2008 at 4:19, Rafael C. de Almeida wrote:
> [email protected] wrote:
> > 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.
>
> 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,
yet they already are, see below.
> 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.
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
are special cased).
> Also, you need to tell
> us what you consider to be a security bug. That's not clear to me at least.
anything that breaks the kernel's security model. privilege elevation
always does.