Quoting Didier Kryn (k...@in2p3.fr): > 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 r...@linuxmafia.com McQ! (4x80) _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
