Quoting Didier Kryn (kryn@???):

>     Just out of curiosity:
>
>     Debian kernels are patched by Debian's kernel team, in
> particular for security fixes. Therefore I see 4 options (at least)
>
>     1) compile from kernel.org source with your own config
>
>     2) compile from kernel.org source with Debian's config,
> customized by you
>
>     3) compile from Debian patched kernel source with your own config
>
>     4) compile from Debian patched kernel source with Debians
> config, customized by you

A few years ago, I was the senior Operations guy (can't remeber the
exact title) for a 'merchant bank', which is a rather odd term in
e-commerce for a company or business unit whose business is handling
online credit card data, accepting transactions from Web sites (either
the company's own, or that of client firms, or both) and passing that on
to the credit card clearinghouses.

One part of that job was, every three months, proving to an auditing firm
that the merchant bank's computing infrastructure still passed PCI DSS,
the Payment Card Industry Data Security Standard. Much of this was
tedious work proving that publicly relevant software was immune to known
vulnerabilities as recorded in significant-grade CVEs. So, in turn,
this meant that I got really good at showing that particular CVEs did
not apply to our particular software and configuration because [reason
X]. When the auditors deemed my analysis compelling, my merchant bank
passed that component of PCI DSS. (There's a lot more to PCI DSS, which
you can look up if curious, but I'm citing the portion that I feel casts
some light on present discussion.)

My point relates to the frequent 'doesn't apply to our particular
software and configuration' outcome, whose frequency surprised me a bit
-- even though the scope of auditing was the entire software complement
of a complete data farm, not just a single piece of software such as an
OS kernel.

In attending to my own software on my personal systems, after I've pared
down the software included in my bespoke binary kernel and associated
modules to _only_ the software I actually want and need, and then
further lock down / trim functionality in related system configuration
files, the percentage of new Linux kernel CVEs that upon examination
turn out to be even theoretically relevant to my systems goes down to
almost none.

It remains a really good idea to follow CVE news, which is why I
subscribe to debian-security and have a subcription to LWN.net. Just in
case something really is on fire.

In addition to fixing CVEs, kernel revisions in theory also fix general
bugs, in theory not along the way introucing new bugs, and introduce new
hardware support and general alleged improvements and general alleged
improvements. At some point, one abandons that version 2.0.13 kernel
one first built in 2001, even if there aren't any relevant CVEs against
it.

Speaking in general terms, the result is that you skim-read and mumble
'Next!' a lot, and upgrade rather little. Your Mileage May Differ.[tm]

I do as mentioned use my own kernel .config file for such systems,
because IMO the alternative would be absurd. (Why bother compiling that
software without customising for one's local system?) I'm not intending
to tell you what kernel source code I use, or exactly how often this is
updated and why and how, or any other such answers that would equate to
posting the most sensitive details of security-sensitive issues to a
public mailing list. A sufficient reason should be very obvious, plus
there really is no reason for you to have that information. OTOH, I
applaud your thinking about and crafting your own locally appropriate
security policy, which is a very good idea for all *ix admins.

-- 
Cheers,                      "Overheard a hipster say 'Quinoa is kind of 2011',
Rick Moen                    so I lit his beard on fire."      -- @kellyoxford
rick@???
McQ!  (4x80)