"Stable" kernel 2.6.25.7 released [LWN.net]

The core issue

Posted Jun 17, 2008 6:29 UTC (Tue) by bojan (subscriber, #14302) [Link]

For me, the main issue here is this: are these things real security problems or not?

- if yes, CVEs should be opened and logs clearly marked
- if no, then someone should should let us know that they are not

I'm really not in the position to evaluate validity of Brad's claims, but from what I saw in
other discussions, other more qualified people usually cannot refute them.

The core issue

Posted Jun 17, 2008 7:21 UTC (Tue) by wtarreau (subscriber, #51152) [Link]

> For me, the main issue here is this: are these things real security problems or not?

It's not as simple. Security means everything and nothing at the same time. There are people
who consider security only about risk of intrusion. Other people consider the risk of remote
or local DoS. Others the risk of data leak. If we want to be picky, everything which can
permit a non-privileged user to cause a malfunction resulting in a degradation of performance,
integrity, availability, confidentiality or traceability is a security issue.

As you can see, the smallest driver bug can become a security issue. If someone plugs an
usb-serial cable into a machine and makes it crash, it is a security issue if it is normally
not allowed to enter this machine.

Brad tends to be particularly picky about security issues (and it is good to have someone who
really sees a lot of risks as he does). Other people like Al Viro consider that anything which
requires root to impact the security is not a problem, because once your box is rooted, you
have lost. These differences explain why a lot of bugs are not marked as security issues and
are complained about afterwards.

Another example I reported a long time ago : make a chroot, mount /proc into it, install a
shell there, chroot overthere, then "cd /proc/1/cwd". Bingo, you're out of the chroot. Some
people say that since this "cd" already requires to be root, it's not an issue. Others
(including myself) consider it is an issue. It's just a matter of point of view unfortunately.

Overall, I think the security issues are correctly taken by the middle chain (2.4 and
2.6-stable), but the fact that information sometimes gets lost at the starting point makes it
difficult to dig for the whole thing. It depends on who reported the issue and how it was
merged into mainline in fact. Sometimes, big security fix will get immediately merged, even
before a CVE gets assigned. But those ones are not the most difficult to track.

The most difficult ones are the ones which require special knowledge in a specific area and
which are not covered as security problems by the person who initially fixes them (by lack of
knowledge too). This is often the case with drivers.

The core issue

Posted Jun 17, 2008 10:47 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]

> It's not as simple. Security means everything and nothing at the same
> time.

Willy, please do read the previous discussion before commenting. the problem isn't that people
are unable to determine whether a given bug has a security impact or not. that is a separate
issue and is not the point raised now. the problem we exposed is that of covering up security
impact information when it *is* already known to the kernel developers. you're privy to that
information yourself and in silent agreement with that policy, don't pretend you don't know
(care to explain to the rest of the world that itanium hardware bug still unfixed after 2
years?).

> There are people who consider security only about risk of intrusion.
> Other people consider the risk of remote or local DoS. Others the risk
> of data leak. If we want to be picky, everything which can permit a
> non-privileged user to cause a malfunction resulting in a degradation of
> performance, integrity, availability, confidentiality or traceability is
> a security issue.

and where's the problem? you simply include the relevant info in the commit and let the users
decide which ones they're interested in. the current problem is that by omitting or
obfuscating any such info makes it *impossible* to quickly select the interesting commits.
you're not improving linux security by making it hard for users to make decisions.

> Overall, I think the security issues are correctly taken by the middle
> chain (2.4 and 2.6-stable),

once again, to stress the point: no, they are *not* correctly handled. ask Chris Wright about
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... .

> but the fact that information sometimes gets lost at the starting point
> makes it difficult to dig for the whole thing.

it doesn't get 'lost', it gets intentionally omitted. and it's not sometimes but pretty much
every time now. case in point,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... .
knowing Ilja's past work, i can't imagine he didn't report this as a bug with security impact
(not that it's hard to figure out even if he didn't) yet there's no mention of it in the
commit, not to mention a backport to -stable.

The core issue

Posted Jun 17, 2008 19:08 UTC (Tue) by wtarreau (subscriber, #51152) [Link]


> Willy, please do read the previous discussion before commenting.

I did, and I do not agree with what was said, it is exagerated.

> the
> problem isn't that people are unable to determine whether a given bug
> has a security impact or not. that is a separate issue and is not the
> point raised now. the problem we exposed is that of covering up security
> impact information when it *is* already known to the kernel developers.

Well, I know that Linus does not like to give too much information in
the commits because he believes it will help the bad guys, reason why
he does not add the methods to reproduce the problems nor the CVE when
he does the commits himself. I don't share his opinion here, but that's
personal taste, and after all, it's *his* project.

You have to keep in mind that most often, a commit is a summary of 10-20
mail exchanges with reproducers, tests and results. You cannot put all
that in a commit. OK Linus tends to go to extremes (and believe me, it's
hard for -stable and I to follow those bugs). But I don't think there are
many more people oversimplifying the commits in such circumstances.

Both -stable and I keep the original message when backporting, and look
for any existing CVE information then add it. I have already missed CVE
numbers before committing. It happens.

What I'm really sicked about is the accusations of "general agreement to
deliberately hide security informations from commits". That's false IMHO,
really. And in fact, examples given by Brad were on public lists, so that
does not make any sense.

What we agree about is not to divulgate information when joining the list.
That's the minimalist requirement you can expect from members who you will
send sensitive information. There are times you would like to shake a bit
the tree to get something to speed up, and you cannot. Those moments are
a bit frustrating, but you agreed about the initial rules. But I have
never seen anything there such as "hey shhht! don't tell anybody, let's
fix it silently". It's more like "pfff!! needs to be root anyway, not
relevant".

> you're privy to that information yourself and in silent agreement with
> that policy, don't pretend you don't know (care to explain to the rest
> of the world that itanium hardware bug still unfixed after 2 years?).

As ruled above, I cannot explain this. However, I can paraphrase what
Brad already reported there : http://lwn.net/Articles/285928/
Basically, the fix was deemed wrong and needed some rework. Then no
time to work on it. I recently asked for news about the situation,
because I don't like a fix to remain pending, and response was
that the fix was wrong and not sufficient anyway because of the
reasons Brad already explained. If a fix cannot be developped,
game over! And please don't ask someone to publicly forward the
patch, it will only harm in helping exploitation without bringing
any value towards a possible fix.

Hint: I found the wrong fix is already present in at least one publically
downloadable distro kernel update.

> and where's the problem? you simply include the relevant info in the
> commit and let the users decide which ones they're interested in.

Believe it or not, it is already the hardest part of my work, determining
the relevant information. It is no different than any bug tracking for any
software, people ask for tests, some seem valid and point to one direction,
some seem invalid, some tracks are finally proven wrong. It's very hard to
build a relevant commit message. Sometimes when I read Linus' commits, I
think "oh he's abusing..." but when I try to do the work myself, I
sometimes wonder why I take 30 minutes to try to collect relevant
information to build a useful commit message when it could simply be
a one-liner.

> the
> current problem is that by omitting or obfuscating any such info makes
> it *impossible* to quickly select the interesting commits. you're not
> improving linux security by making it hard for users to make decisions.

I know that, believe me! And this is not limited to security impacts. I
regularly read random 2.6 commits to find if there are fixes relevant to
2.4 or stable. Sometimes I don't know. Sometimes I think I should merge
them, then someone explains me that I'm wrong because the bug cannot be
triggered in my situation.

And please, do not say "obfuscate" when speaking about commit logs,
it's more like "summarize", even if extreme summarization may lead to
obfuscation.

> > Overall, I think the security issues are correctly taken by the middle
> > chain (2.4 and 2.6-stable),
> once again, to stress the point: no, they are *not* correctly handled.
> ask Chris Wright about
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... .

Could you elaborate please ? This fix is in Linus tree, and I don't see
Chris in the sign chain. Did he report it first ? Also, I'm sorry, but
I fail to see the security implications of this patch, eventhough seeing
"ptrace_attach" catches my attention.

> it doesn't get 'lost', it gets intentionally omitted. and it's not
> sometimes but pretty much every time now. case in point,
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-...
> knowing Ilja's past work, i can't imagine he didn't report this as a bug
> with security impact (not that it's hard to figure out even if he didn't)
> yet there's no mention of it in the commit, not to mention a backport to
> -stable.

From what I have seen, this was finally judged as a non-issue since other
checks are in place, which probably explains why you don't have it in
stable. It is very often that fixes for supposedly real vulnerabilities
finally end in mostly code cleanups.

Don't get me wrong, I'm all about transparency, and we're not good enough
at this IMHO. But it is not *that* bad.

What amazes me, to be honnest, is the ability you have to spot patches in
mainline that take a lot of time to other people. I'd love to know how you
proceed, it would save me a lot of time. Or maybe you spend whole days at
this, in which case all users would benefit from your findings. Why don't
you post on LKML, to -stable or even on security lists links to the patches
you consider suspicious security-wise ? Even assuming everyone's honnest
in the chain, and the other people considered the bug inoffensive when you
think the contrary, you could educate people about your methods of
discovering this.

For instance, people are slowly getting used to CC stable when releasing
a fix for an annoying bug. It still takes a lot of efforts to get those
bugs automatically submitted, but after about 2 years, people start to
educate themselves. If you regularly prove them wrong when they claim
that a bug has no security impact, they will more often ask for a second
opinion, or try to a bit more descriptive in their commits.

But you cannot expect too much from the people who already do this on their
minuscule spare time, really.

The core issue

Posted Jun 17, 2008 22:08 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]

> Well, I know that Linus does not like to give too much information in
> the commits because he believes it will help the bad guys, reason why
> he does not add the methods to reproduce the problems nor the CVE when
> he does the commits himself.

that's obviously utter crap. the bad guys are smarter than him or any kernel contributor.
they'll spot the bugs *before* they do. they'll also spot the bugs in the commits regardless
of what the commit says. does anyone remember the collective bruhaha in the security world
when CVE-2006-2451 became public? IIRC, that was a full year after the original commit and
also a full year after at least two working private exploits for it. on a sidenote, IIRC, that
bug still isn't fixed properly, as soon as a sysadmin enables the suid coredump feature, it's
exploitable again.

but actually i don't care about his opinion. what i do care about is that his published
commitment to full disclosure matches what he actually does and that's where the problem is.
you see, withholding security impact information doesn't full disclosure make. you guys can't
have it both ways because the people relying on you expect you to hold up to that commitment
you made in Documentation/SecurityBugs and if you violate that promise, people will make wrong
decisions and innocent people may suffer as a result. so if you want to stick to withholding
security impact info from commits, say so and the world will adjust. but let me guess, that'd
also be bad PR and you don't like that part.

> You have to keep in mind that most often, a commit is a summary of 10-20
> mail exchanges with reproducers, tests and results. You cannot put all
> that in a commit.

that's a strawman Willy, noone asked for it. what we did ask for was inclusion of known
security impact details. it doesn't overflow anyone's mailbox or git repo if you include a
*single sentence* saying that this is a potentially exploitable buffer overflow or NULL deref
or whatever. people can grep for the keywords and make further judgements based on whatever
extra research they deem necessary (including asking the committer for more details). once
again, this info doesn't help the bad guys because they'll spot this regardless of how obscure
the commit message is.

> What I'm really sicked about is the accusations of "general agreement to
> deliberately hide security informations from commits". That's false IMHO,
> really. And in fact, examples given by Brad were on public lists, so that
> does not make any sense.

when you publicly commit to full disclosure, yet, by your own admission now, you don't
actually practice it, then what do you call that? i call that general (silent or otherwise)
agreement of all participants. after all, participation in handling the kernel security bugs
is voluntary, noone forces you or anyone else to do it against his better judgement. therefore
if you play ball there, you de facto accept the not-exactly-full-disclosure policy (you later
admit that regarding vendor-sec, except everyone knows that vendor-sec does not practice
full-disclosure so people don't build that expectation into their decision making processes).
do you understand the problem better now?

> What we agree about is not to divulgate information when joining the list.

that's not the whole truth. what you also agree to is full disclosure after the embargo. go
read Documentation/SecurityBugs if you don't believe me. do you admit that you don't actually
practice it? if you do, we can take the discussion further and figure out whether you want to
actually update Documentation/SecurityBugs or really adopt full-disclosure. if you don't,
we'll keep on exposing the fallacy because we have no other way to affect you and at the same
time help the world by letting them know that their security risk analysis processes are based
on false promises.

> But I have never seen anything there such as "hey shhht! don't tell
> anybody, let's fix it silently".

i quoted Paul Mackerras a few times now. what do you have to say about that quote? why would
someone practicing full disclosure even *ask* that question and then actually withhold the
more important security impact?

> [stuff about the itanium hw bug]
> If a fix cannot be developped, game over!

not true. did the FDIV or F00F bugs mean game over? i don't think so. last time i checked, the
world hadn't stopped back then. what did happen was a huge PR disaster for Intel (in part
because of the same coverup attempt they're doing again). and history is repeating itself,
except this time you guys are actively party to the coverup. you should all be ashamed and the
conscientous of you should have left the list the moment Intel first had asked you to keep
silent because they didn't feel like fixing the chips. something tells me that there's another
PR disaster in the making.

> Believe it or not, it is already the hardest part of my work, determining
> the relevant information.

this is another strawman Willy, as this should not be your work at all and noone asked for it.
what we do ask for is that if you guys learn about security impact information during the
course of bug examination, then you *do* include those details in the commit. noone is
expecting anyone to spend time on thorough bug impact analysis, most of you are not even
qualified for that, it's really hard and time consuming work (just look at this very thread
and see how i missed stuff ;). but, say, if you see a kernel stack overflow then you say so
and don't try to be creative by calling it 'copying overly long strings' and similar crap. of
course there's always the alternative of publicly admitting that you do not in fact want to
practice full disclosure. it won't look cool in PR events but you can at least sleep with
clear conscience.

> And please, do not say "obfuscate" when speaking about commit logs,
> it's more like "summarize", even if extreme summarization may lead to
> obfuscation.

sorry, but i have no better words when i see something like
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... .
do you really call that 'summary'? i hope not.

> Could you elaborate please ? This fix is in Linus tree, and I don't see
> Chris in the sign chain. Did he report it first ? Also, I'm sorry, but
> I fail to see the security implications of this patch, eventhough seeing
> "ptrace_attach" catches my attention.

don't you think there's a reason you fail to see the security impact and that i cited this
particular commit? go ask Chris about the history of it, you'll be surprised. in short, this
*is* a local DoS, the kernel devs were provided proof-of-concept code *yet* Linus deliberately
did not include any of that information. then Chris deliberately omitted it from the -stable
commit as well. wild accusations? or the unbelievable truth? it's yours to find out and you
even know how.

> From what I have seen, this was finally judged as a non-issue since other
> checks are in place, which probably explains why you don't have it in
> stable. It is very often that fixes for supposedly real vulnerabilities
> finally end in mostly code cleanups.

it would have been nice to mention this in the commit as well.

> What amazes me, to be honnest, is the ability you have to spot patches in
> mainline that take a lot of time to other people. I'd love to know how
> you proceed, it would save me a lot of time.

uhm, there's nothing magical in this. i sometimes check the kernel shortlog looking for
potential conflicts with PaX and obviously my eyes catch sometimes other 'interesting' looking
commits which i then go and look at in detail.

> Or maybe you spend whole days at this, in which case all users would
> benefit from your findings.

not at all, as i said somewhere below, i do it on my free time, always have in fact. and these
days, i'm trying to actually spend my time on other things. but as long as i can't give PaX
away to a new crew, i'll have to have a look every now and then.

> Why don't you post on LKML, to -stable or even on security lists links
> to the patches you consider suspicious security-wise ?

what would that change? more flames, more excuses for why it's not a good idea to support the
bad guys, etc. and in the end, as i said above, that's not what i care about but rather the
consistency between the promise made to the public and the actual actions. i can't fix any of
that because it's not of my making.

> Even assuming everyone's honnest in the chain, and the other people
> considered the bug inoffensive when you think the contrary, you could
> educate people about your methods of discovering this.

that's a whole separate issue of figuring out that a bug has a security impact after the
commit. i'm afraid such research requires a full staff, and i'm not in the position to fund
anything like that. heck, i'm happy when i make ends meet here ;).

Kernel bug 9416

Posted Jun 18, 2008 2:28 UTC (Wed) by vonbrand (subscriber, #4458) [Link]

What is wrong here? The commit message cites a bug report saying that the kernel might have a buffer overflow. And that is somehow "hiding" potential security implications, when it took me a few seconds to see that it could be a very serious issue?

Come on, now... a real conspiracy theory needs to hint at more secrecy than that!

Kernel bug 9416

Posted Jun 18, 2008 3:28 UTC (Wed) by spender (subscriber, #23067) [Link]

Let's get straight what you were actually commenting on here, since you were turning it into
something it wasn't.

Willy said:
"And please, do not say "obfuscate" when speaking about commit logs,
it's more like "summarize", even if extreme summarization may lead to
obfuscation."

So the PaX team gave an example, where the commit subject was "isdn: avoid copying overly-long
strings".  I agree with them that this isn't a summary but rather a strained attempt at
obfuscating the issue.  Nothing would have been wrong with just copying the description from
the bugzilla entry, it wouldn't have required the invention of clever new phrases, and
wouldn't have required that people click on a bugzilla entry to figure out what was actually
fixed.

Please read and comprehend before posting.

-Brad

Kernel bug 9416

Posted Jun 18, 2008 4:20 UTC (Wed) by vonbrand (subscriber, #4458) [Link]

"Avoid copying overlong strings" does make my (mostly untrained!) alarm bell go nuts. If that is "obfuscation"...

In all this (by now extremely tiresome) discussion I have seen not a shred of evidence of wrongdoing. Perhaps carelessness, perhaps people not seeing potential security problems. Bugs get fixed, most developers care that it is a bug and don't care much if it might be a security problem. Others try to filter "important" (by whatever measures) fixes to apply to the "-stable" (by their measure) tree. If you disagree, you are wellcome to set up the "-secure" tree and do your own filtering and applying. In doing so, you won't be able to rely blindly on the commit messages (the bug fixer might be completely incompetent at seeing security implications) or the discussions that went before (they could all very well be completely off track), so this is hard, thankless work. If you moreover succeed in recruiting a bunch of hackers to help out, more power to you. That would be a real help, flinging all sort of conspiracy theories and ill will accusations around is counterproductive. If the people here (myself included) had spent their time chasing bugs instead of flaming around, we would all be better off.

Kernel bug 9416

Posted Jun 18, 2008 12:17 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]

> In all this (by now extremely tiresome) discussion I have seen not a
> shred of evidence of wrongdoing.

would that be because you haven't actually seen/read everything? if you have, please tell me
the history of this commit/bug:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... .
if you don't see it immediately from the linked commit it's because it was intentionally
omitted. but you can always ask the committer. will you?

> Perhaps carelessness, perhaps people not seeing potential security
> problems. Bugs get fixed, most developers care that it is a bug and
> don't care much if it might be a security problem.

that shows how much of the discussion you saw. pretty much nothing. the issue is *not* with
people not realizing the security impact of bugs (noone expects people to disclose what they
don't know), but rather with intentional withholding/downplaying the same when it *is* known
to them. i gave you a lead above, try to find out what happened there and be shocked.

Kernel bug 9416

Posted Jun 18, 2008 12:10 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]

> What is wrong here? The commit message cites a bug report saying that
> the kernel might have a buffer overflow.

you just said it yourself ;). 'buffer overflow' is *the* very common and usual term to
describe this kind of bug, not 'copying overly-long strings'. mind you, it's even shorter to
type and would immediately match everyone's mental filters for security related commits (it
happened to match my 'look for funny looking commits' filter only, and i've grown one only
because i realized there was a need regarding kernel commits. pretty sad.). so, why was it
omitted/rephrased in an unusual way (a simple google fight shows that 'buffer overflow' has
over a million hits, whereas the other phrase gives a few thousand), especially since the
original bugreport said so already?

The core issue

Posted Jun 18, 2008 21:53 UTC (Wed) by wtarreau (subscriber, #51152) [Link]

Hi,

I'm replying quickly because I'm fed up with wasting my time writing in
HTML textareas, and I still have bugs to chase down in other areas.

> it doesn't overflow anyone's mailbox or git repo if you include a
> *single sentence* saying that this is a potentially exploitable buffer
> overflow or NULL deref or whatever. people can grep for the keywords and
> make further judgements based on whatever extra research they deem
> necessary (including asking the committer for more details)

Well, if what you want to see is mostly keywords, it changes things a
*lot*. As I said, building a proper commit is a tough work. Simply adding
keywords or phrases such as "maybe exploitable, costs nothing to merge
anyway" is not hard. We've been trying to work like this at least on 2.4,
noticeably with Dann Frazier from Debian who reported quite a bunch of
fixes. But in general, adding simple keywords such as "security" or "CVE"
on subject line helps a lot.

Now, about the lists' "full disclosure" after the embargo, I disagree
with your interpretation. For instance, vendor-sec charter explicitly
states :
   "...security problems first reported on vendor-sec should not be
    discussed publicly...".

Saying that an embargo is over and a bug is public does not mean you can
talk about everything with everybody. Most common examples are exploits.
So there's no "full disclosure" commitment, in fact it's pretty the
opposite. More like a confidentiality commitment.

> you should have left the list the moment Intel first had asked you to
> keep silent

You don't get it. Nobody asked anyone to keep silent. Nobody simply set
an end to the embargo. You may find this cowardly because noone is
responsible that way. But on another point of view, the guy may finally
come up with a usable fix and the risk of massive exploitation will have
remained lower than with a gratuitous disclosure without a workaround.

Also, it was not "intel". Just one individual, not authoritative of
Intel. That makes a difference too because threatening him will not
threaten intel, but he would simply stop working on the subject. But I
don't know why I'm explaining this, you seem well informed already.

Last, about "obfuscated commits", the suspicious examples you collected
concern Chris, Linus and Paul. Why not talk to them directly, showing
evidence of those bugs being actively used for years before their fix
and trying to convince them to be more verbose, instead of whining on
a forum they might never read about general kernel devs practises ?

Build up a collection of evidence, show them privately or publicly as
you like, and explain what issues you find there and why you think
it's bad to proceed that way. It will be quite more productive IMHO.

Once again, I'm all for giving enough information to users to justify
upgrades, while not giving enough to script kiddies. I'm for
"responsible disclosure" instead of "full disclosure". The real bad guys
are not dangerous, they have their targets and already know about the bug.
Dangerous ones are the script kiddies destructing systems to impress their
friends. That has happened a lot with the vmsplice bug. I've even read
public records of IRC channels where stupid kiddies compared their
performance on their respective friends' colocated systems. In that sense,
giving a link to a CVE and a minor adequate summary is the right thing to
do in my opinion. It can be left to the reader to push analysis further if
he wants to.

Also, keep in mind that most bug reports come from vendors' customers,
and at least for that reason you cannot divulgate too much of their
context, otherwise your security channel gets a bad reputation and you
quickly don't get bug reports anymore.

Last, I would say that most people interested in security updates are
already on security lists : distro vendors and stable maintainers. Rest
of the world either rely on their vendor or on mainline kernel. If you
feel like you'd need to get more information on the security issues,
you may ask to join those lists, and even participate in elaborating
more suitable commit messages. If you can respect a certain level of
confidentiality, you may finally get the information which seems to
be missing you too much, and finally notice that there is no such
common agreement about deliberate obfuscation.

Willy

The core issue

Posted Jun 19, 2008 0:47 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]

> Well, if what you want to see is mostly keywords, it changes things a
> *lot*. As I said, building a proper commit is a tough work.

it wasn't me who decided that the kernel security bug disclosure policy should be that of full
disclosure. you're free to change it if you can't live up to it for whatever reason.
alternatively, you can make the archives public after the embargo so that people can get the
whole picture. the current situation is not good as it hurts users.

> But in general, adding simple keywords such as "security" or "CVE"
> on subject line helps a lot.

indeed and this is what's missing among others in 2.6 commits (which is what we've been
complaining about, not 2.4).

> Now, about the lists' "full disclosure" after the embargo, I disagree
> with your interpretation.

'full disclosure' is not subject to interpretation. if you withhold information, then it's not
'full', period. check the full-disclosure mailing list if you don't believe me (it's full of
exploit code, there's no embargo observed, etc). you're free to call yours something else and
then everyone will know what to expect.

> Saying that an embargo is over and a bug is public does not mean you can
> talk about everything with everybody. Most common examples are exploits.
> So there's no "full disclosure" commitment, in fact it's pretty the
> opposite. More like a confidentiality commitment.

i know all that Willy, that's why i said that vendor-sec was known *not* to practice full
disclosure. the kernel security list however, as of now, has a declared full disclosure
policy.

> You don't get it. Nobody asked anyone to keep silent.

not true. you stated yourself the vendor-sec list rules that you don't talk about issues in
public. this one was no different, the list rules still apply. if the list had been public, do
you think Intel would have told you about this bug?

> Nobody simply set an end to the embargo.

not true, there was an embargo set but it came and went, nothing happened except the patch got
into at least one distro afterwards, that effectively made it public and thus ended the
embargo.

> You may find this cowardly because noone is responsible that way. But on
> another point of view, the guy may finally come up with a usable fix

you know now that it's not possible because the bug can only be fixed in hw properly.

> and the risk of massive exploitation will have remained lower than with a
> gratuitous disclosure without a workaround.

so you're saying that the world would have been better off if the FDIV and F00F bugs had never
become public? are you seriously justifying this new Intel coverup?

> Also, it was not "intel". Just one individual, not authoritative of
> Intel. That makes a difference too because threatening him will not
> threaten intel, but he would simply stop working on the subject.

someone posting from @intel.com cannot state on his own behalf that Intel would not provide
the code sequences that trigger the bug. and holding Intel accountable is not threatening
them, except their bottom line if angry customers hold them, well, accountable for their bad
decisions.

> But I don't know why I'm explaining this, you seem well informed already.

the world isn't Willy, that's the problem. and when Intel does finally fix the bug in a future
chip, what will happen to the people running with the old ones? will you/they keep them
ignorant about their buggy chips forever?

> Last, about "obfuscated commits", the suspicious examples you collected
> concern Chris, Linus and Paul. Why not talk to them directly,

and tell them what they already know? i don't see the point...

> showing evidence of those bugs being actively used for years before
> their fix and trying to convince them to be more verbose, instead of
> whining on a forum they might never read about general kernel devs
> practises ?

we're not whining, we're telling the world that things are not exactly as one would naively
believe. although i don't expect kernel devs to read everything on lwn, i know that many of
them read this one and they got the message. question now is what they'll do with it, in
particular, will they live up to full disclosure, or will they keep downplaying security
issues.

> Build up a collection of evidence, show them privately or publicly as
> you like, and explain what issues you find there and why you think
> it's bad to proceed that way. It will be quite more productive IMHO.

the evidence is in secret mailings lists. will you make the archives public? this is the point
we made: noone is accountable because everything is done in secret. how can *we* change that?

> I'm for "responsible disclosure" instead of "full disclosure".

i posted somewhere below what Linus had to say about 'responsible disclosure' (look for
'mental masturbation'). you're in wild disagreement, to say the least.

> Also, keep in mind that most bug reports come from vendors' customers,
> and at least for that reason you cannot divulgate too much of their
> context, otherwise your security channel gets a bad reputation and you
> quickly don't get bug reports anymore.

noone asked for that (although the kernel devs' commitment to full disclosure would imply
disclosing even such information, personally i don't care or think it's interesting or
necessary).

> Last, I would say that most people interested in security updates are
> already on security lists : distro vendors and stable maintainers.

not true at all. one must meet some definition of 'elite' to get on these lists. you know full
well how individual researchers are *not* welcome on vendor-sec for example.

> If you feel like you'd need to get more information on the security
> issues, you may ask to join those lists, and even participate in
> elaborating more suitable commit messages.

i may ask and i will get rejected. thanks, but no, thanks.

> If you can respect a certain level of confidentiality, you may finally
> get the information which seems to be missing you too much, and finally
> notice that there is no such common agreement about deliberate
> obfuscation.

i don't need to be on any list to notice when something's covered up. FWIW, i'm not the first
one to have made such an observation: http://marc.info/?l=bugtraq&m=115255401805462 - you know
who he is, right?

The core issue

Posted Jun 17, 2008 11:50 UTC (Tue) by bojan (subscriber, #14302) [Link]

> If we want to be picky, everything which can permit a non-privileged user to cause a
malfunction resulting in a degradation of performance, integrity, availability,
confidentiality or traceability is a security issue.

Kernel is done for a wide audience and, as you mentioned, different people would like to know
about different types and severity of security problems. So, the best policy is just to
describe them all and let people (including distributors) decide if they want to bump up or
not.

In other words, if things are logged in such a way that even the pickiest of them are OK with
it, then the ones that are less picky will be OK too. Provided the information about the
security impact is known, of course.

It's done exactly in this way... in a sense

Posted Jun 17, 2008 17:08 UTC (Tue) by khim (subscriber, #9252) [Link]

So, the best policy is just to describe them all and let people (including distributors) decide if they want to bump up or not.

Better for whom exactly? There are exist one potential group which will be VERY negatively affected: top-level kernel developers (and to lesser extent all other kernel developers). For them detailed list of security implications in descriptions is unneeded noise, not something important. They look and review THOUSANDS of such descriptions each and every week so OF COURSE they want to reduce this noise. If issue looks severe enough - they keep it in description.

In other words, if things are logged in such a way that even the pickiest of them are OK with it, then the ones that are less picky will be OK too.

And the pickiest users are of course kernel developers - they want to avoid clutter in various typed of reports and so demand short and concise descriptions. So they remove unimportant (for them) parts. Including detailed descriptions of possible security implications. In all cases except the most severe ones. So in fact they did what you asked them to do - but somehow you are not satisfied.

Now if you think they go overboard in some cases - you can join the system and help to prevent this. If you want totally different style of commit messages (extensive with lots and lots of details) in general - you are free to fork the project and put any kind of descriptions you want.

It's done exactly in this way... in a sense

Posted Jun 17, 2008 21:54 UTC (Tue) by bojan (subscriber, #14302) [Link]

> Better for whom exactly?

For people trying to keep their systems secure?

Security issues are not noise, especially when people producing patches for them are already
aware of their nature.

> So they remove unimportant (for them) parts.

Yeah, that's kinda the problem. Even the most trivial of security issues may be important to
someone. Removing information about it puts users that may be affected at a disadvantage.

> If you want totally different style of commit messages (extensive with lots and lots of
details) in general - you are free to fork the project and put any kind of descriptions you
want.

So, mentioning in the release notes of .7 that some security issues have been addressed, which
would take less than 100 words, requires a kernel fork? I don't understand where all this
hostility is coming from.

If issues are known, release notes should specify that. It's that simple.

The core issue

Posted Jun 18, 2008 1:07 UTC (Wed) by vonbrand (subscriber, #4458) [Link]

Or create a device for /, mount it somewhere, and cd there. Or a hundred other creative ways to escape, or to thoroughly thrash the system... As root in (traditional) Unix there is nothing that stops you. And that with SELinux you can make UID 0 powerless doesn't mean that that is common today, even where SELinux is enabled by default.

Sure, if there is a bug that could make the system crash or misbehave, it should be fixed. But if only root can exploit it, it is definitively much lower priority than the same that any user can trigger locally or (even worse) remotely.