Le 22/11/2018 à 10:27, Rick Moen a écrit :
> 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.
>
    Rick, I'm very impressed by the level of responsibility which has
been given to you. We certainly don't have the same mileage. You are a
professional while I am just a somehow educated amateur. It is clear
also that the systems we care of (have cared of) haven't the same
requirements in matter of security. In this mailing list, you rather
advocate for big server infrastructures open to the public, while I'm
rather on the side of the DIY guy, and also, sometimes, the almost
dummy. I think it is great that Devuan can match all these use cases and
I hope the discussion is usefull to others.

        Didier