Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for June 20, 2013
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
So what dead horse is being beaten if you can't provide me with links to this discussion Linus
is referring to?
Stable kernel 126.96.36.199
Posted Jul 15, 2008 19:08 UTC (Tue) by nix (subscriber, #2304)
The dead horse is arguing about this at all when Linus has said that he
doesn't care and gregkh has pointed out (in
commit messages don't get changed for stable unless the patch itself
Given the `don't change commit messages unless necessary' process of the
stable team (likely to stay that way unless gregkh et al acquire several
clones or the day becomes 48 hours long), the two of you are in effect
insisting that Linus and everyone else who pulls patches from anyone else
not accept those changes until they've reviewed every one for security
impact, acquired CVEs if necessary and only then allowed them on. (Nothing
else would suffice to get every commit message appropriately marked up
before it makes its way into -stable and/or the next major kernel
And that *really* isn't likely to happen as long as pretty much everyone
involved in the process who's said anything at all has said 'no way', and
if it did happen it would devastate kernel development speed. Even OpenSSH
isn't maintained *that* rigorously, and OpenSSH is a couple of orders of
magnitude smaller. (I suspect that anyone who doesn't say 'no way' to a
suggestion like that is more interested in security reviewing than coding
anyway, and so probably isn't committing anything much other than security
fixes. There certainly aren't enough of those people, but expecting
*everyone* to act like that is impractical.)
(I fully expect more groundless 'straw man' accusations now because I
dared to determine what your demands would logically imply.)
Posted Jul 15, 2008 21:46 UTC (Tue) by spender (subscriber, #23067)
Yes, nix, you've really explored the depths of the logical implications of what we're trying
to get accomplished.
I don't want to blow your mind or anything, but I'll try in a paragraph or so to catch you up
to speed with what's been going on with "computers" in the past couple decades or so.
See, some time ago, somebody thought it would be a good idea to create something called a
"text editor." An ingenious invention at the time, certainly, and you'd be surprised to know
that they're still in use today! In fact, these "text editors" have made their way into other
common applications, like those used to read electronic mail (what we nowadays call e-mail).
If you're unfamiliar with these "text editor" contraptions, they allow you to edit text, copy
and paste text, and other such advanced procedures.
An interesting fact is that these "text editors" can indeed be used to *compose* electronic
mail messages. For example, maybe a person would be writing an email which contains the
changelogs for a particular version of the Linux kernel. With these newfangled "text editors"
one can modify these changelogs quite easily to add any additional information they choose to
include! I know back in the day this may have been a long and laborious process, what with
all those punch cards and driving to the residence of the recipient to deliver them, but
surprisingly this task now takes much less time!
There are reasons certain fixes get included in the -stable tree. They are aware of these
reasons, and the only thing preventing them from informing others of these reasons is their
own will to do so. We're asking them to simply be honest about what was fixed. When they
know it's a possibly exploitable overflow, they should just say so. Now, should all these
vendors profiting off Linux and its appearance of security (which given Linus' recent
statements, I think the public should be strongly reconsidering) actually maybe form a group
of actual security professionals to handle this kind of stuff, instead of continuing to say
"hey don't be so harsh, we're just really awful at this sort of thing...but Linux is still
enterprise-grade!"? Sure, it would be nice, but one problem at a time.
Just as an obvious example to show how incredibly stupid your explanation of "logical
implications", the fact that the PaX team has been pointing out suspicious and exploitable
vulnerabilities in each of the past half-dozen -stable releases hasn't seemed to impact the
speed of kernel development one iota, let alone "devastate" it. As evidenced by several
comments on this posting already, people appreciate having this information available. I
think that view will become even more common once people read what Linus is saying (that he
doesn't think people should be informed of security issues and that the vendors, the only
people doing such informing, are doing a "crappy" job of it and only disclosing a small
percentage of vulnerabilities) and realize what Linux kernel security in particular is passing
for these days.
security holes in Linux
Posted Jul 15, 2008 22:26 UTC (Tue) by zooko (subscriber, #2589)
I hate to see angry messages on LWN.net (although I have to admit that, even while angry, the
current posters are making more useful points than I see on most other web fora).
I like the note at the top of the LWN.net comment editor page: "Please try to be polite,
respectful, and informative".
Let me point out that this isn't so much an issue of Good vs. Evil as much as a question of
different people having different needs. The Linux kernel does a fine job of evolving
quickly, supporting lots of hardware, improving the common cases of performance issues, and so
forth. There are plenty of people whose security needs can be aptly summed up as "Whatever my
distribution and the Linux core team think is best is probably good enough.". Those people
have no need for more specific information about vulnerabilities, and would not be able to use
that information if they had it. Perhaps they are using Linux exclusively on non-networked,
single-user jobs, for example.
It's not that those people *ought* to value specific security vulnerability disclosures more
than they do -- it's just that they personally have no need of such disclosures.
On the other hand there are people who do need more specific information. They may be
responsible for networked, multi-user Linux installations with great value at stake, for
example. They may need, and know how to use, vulnerability disclosures in precise detail as
to the window of vulnerability and how to fix or workaround each issue. As far as I currently
understand it, those people are not being served.
Now again, this isn't a matter of Good vs. Evil. Linus, and GregKH, and the rest of the Linux
folks have no moral obligation to provide what those folks need. If Linus and company care to
start providing it, that would be fine. If not, then perhaps someone else (such as PaXTeam
and his partners) would provide that information about Linux, or perhaps those users would be
better off if they switched from Linux to Solaris or OpenBSD or something.
But again, for the third time, those users switching from Linux to Solaris or OpenBSD or
something would not be an Evil. The world would not become a worse place. Indeed, if the
maintainers of those other operating systems were better prepared to provide the kind of
service that those users need, then the world would be a better place.
For what it is worth I have worked in computer security for a long time, and for years I
tended to assume that my peers who insisted on running only OpenBSD or FreeBSD and refused to
rely on Linux for security were just being show-offs. Nowadays I'm beginning to think that
they had justification for their choice.
P.S. Just to make sure everyone got the point, if it is true, as I just alleged, that many
open-source-loving computer security professionals refuse to trust Linux's security, then this
is not Evil. It's no big deal. They get along fine in their jobs and you get along fine in
yours, so when replying to this note, please try to be polite, respectful, and informative.
Posted Jul 15, 2008 22:53 UTC (Tue) by spender (subscriber, #23067)
I understand the point you're making, and it actually illustrates part of the problem here.
In order to make those kinds of informed decisions about which OS to use, for example, the
people providing the options have to be honest about what they're actually providing. In the
case we have now with the Linux kernel, on paper they're saying they provide full disclosure
of security bugs, and sometimes we do see CVE and other security-related information in
changelogs (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6... just taken as a
random example) but now we find out that in reality, non-disclosure seems to be their general
policy (except for the small percentage of vulnerabilities Linus says the vendors report on).
As evidenced by some of the comments in denial on previous postings, I think some are probably
surprised now at how things really are.
So as the PaX Team is asking on LKML, there are two solutions to the problem. Either of them
will help people make better decisions regarding security: revise their written policy of
full-disclosure to reflect their real policy of non-disclosure, or change their real policy to
reflect what has been their written policy since 2005.
Posted Jul 15, 2008 23:26 UTC (Tue) by nix (subscriber, #2304)
I note the absence of anything in Documentation/SecurityBugs binding the
Linux kernel hackers to *anything*. All it describes is the way that bugs
sent to the *kernel security team* are managed. I see nothing that says
that security bugs described anywhere *else* need to be handled in any
particular way, or that anyone else involved with the kernel needs to pay
the document any attention at all.
(Perhaps the file needs to say more clearly that this is not a security
policy for the kernel, just a place to which people can report security
bugs if they'd rather not get the standard Linus kill-it-now approach.)
I think this has all been a giant misreading from the start.
Posted Jul 15, 2008 23:15 UTC (Tue) by adobriyan (guest, #30858)
[lame sarcastic stuff]
> There are reasons certain fixes get included in the -stable tree. They
> are aware of these reasons, and the only thing preventing them from
> informing others of these reasons is their own will to do so. We're
> asking them to simply be honest about what was fixed. When they know
> it's a possibly exploitable overflow, they should just say so. Now,
> should all these vendors profiting off Linux and its appearance of
> security (which given Linus' recent statements, I think the public
> should be strongly reconsidering) actually maybe form a group of actual
> security professionals to handle this kind of stuff, instead of
> continuing to say "hey don't be so harsh, we're just really awful at
> this sort of thing...but Linux is still enterprise-grade!"?
Here is an exercise.
Get 2.6.25 => 2.6.26 changelogs and patches.
Write down bugs (just bugs) which make sense to apply to 2.6.25.
To apply in logical sense, not in patch(1) sense.
Scratch those which are already in -stable.
Now extract those which are security-relevant.
Do the same for, say, OpenBSD 4.2 => 4.3.
Do the same for Windows (OK, this is a joke).
Enlightment will come pretty quickly.
> Just as an obvious example to show how incredibly stupid your
> explanation of "logical implications", the fact that the PaX team has
> been pointing out suspicious and exploitable vulnerabilities in each of
> the past half-dozen -stable releases
> hasn't seemed to impact the speed
> of kernel development one iota, let alone "devastate" it. As evidenced
> by several comments on this posting already, people appreciate having
> this information available.
This is something I can't personally understand.
Do those people need word "security" or "buffer overflow" in changelog and
announcement to start kernel upgrade machinery? Given how many commits
don't even reach -stable for PaX guy to whine, they live in some rosy universe.
Not even mentioning occasional incomplete and flatly wrong information
in CVE database.
> I think that view will become even more
> common once people read what Linus is saying (that he doesn't think
> people should be informed of security issues and that the vendors, the
> only people doing such informing, are doing a "crappy" job of it and
> only disclosing a small percentage of vulnerabilities) and realize what
> Linux kernel security in particular is passing for these days.
grsecurity will save us, no worries about that.
Posted Jul 16, 2008 0:05 UTC (Wed) by spender (subscriber, #23067)
Is any distribution shipping 188.8.131.52?
When a new stable kernel is released, do they push out binaries for that new kernel, for all
You know the answer to this, so I think it's you who is living in a "rosy universe" and
pretends that Linux users are using the vanilla "stable" kernel and upgrading to each new one
for the week.
And yes, people do need those words. They're the same words everyone else uses and expects to
be used. Do you think Microsoft could get away with the ridiculous idea that security bugs
are just bugs?
I guess in your "rosy universe" if on Patch Tuesday, a list of 10 patches was presented to a
user with descriptions like "fixed bug" they'd terminate any critical processes running and
upgrade their hundreds of machines immediately.
Posted Jul 16, 2008 0:38 UTC (Wed) by adobriyan (guest, #30858)
> I guess in your "rosy universe" if on Patch Tuesday, a list of 10 patches
> was presented to a user with descriptions like "fixed bug" they'd terminate
> any critical processes running and upgrade their hundreds of machines
Kindly keep your guesses inside yourself.
Posted Jul 15, 2008 23:16 UTC (Tue) by nix (subscriber, #2304)
Nice snark. Still, it was unnecessary: oddly, I do know what text editors
However, the fact remains that editing the patch commit logs isn't done
unless necessary, and the stable tree maintainers don't think that
researching possible security implications, getting CVE info and so on is
a good use of their time. In the absence of their doing this, the only way
to enforce 'CVE info on everything' as you seem to want is the
development-speed-devastating scheme I outlined two messages up. Of
*course* this crazy scheme hasn't been adopted or even proposed, but that
is the only way to do what you suggest as long as the stable team's job
remains cherry-picking and applying patches that others write, rather than
actually modifying the commit logs, and the stable team have said that
this is what they consider their purpose to be.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds