6

This is probably more of a compliance question, so if there is a better place to ask, please let me know.

Background:

It is a long complex story, but we can't easily update our linux kernels due to sub-optimal use of 3rd party software and configuration management systems. It has been suggested that I use KernelCare to patch 30k of our servers kernels.

We have sensitive confidential data, PCI systems and much more. We are audited on a regular basis by multiple external parties.

Problem Statement:

While I can find thousands of sites clammering over the use of this tool, I can not find any sites that reference operating system vendors, upstream linux kernel maintainers, security pen test organizations, or any other authoritative sources that could suggest this is recognized as a valid method of patching kernels and that it does not introduce additional risk. I also can not find any 3rd party validation of their tool that confirms it actually fixes all the vulnerabilities and does not introduce new vulns or back doors.

Question

Aside from saying "no"; which I am perfectly capable of, has anyone gone through to exercise of validating this method of patching and specifically KernelCare? If so, what sources did you provide your customers and auditors?

1

We used KernelCare with Virtuozzo containers successfully and massively. Now I'm in another company and we use KernelCare for all our DC services as well. At least with DirtyCow it was quite helpful and worth it.

  • I can totally see where this would be handy. I just don't see references to 3rd party audits, backing by OS vendors, etc. There is a redhat blog talking about it a little bit from a technical perspective, but no mention of code audits or any official stance on this not introducing additional risk. – Aaron Nov 7 '16 at 0:58
  • Thinking about additional risk - where should it go from? – Kirillx Nov 7 '16 at 14:37
  • Sorry, posted before finished. I mean, when you patch the code - you change one function with another one. The only additional risk can come from the module itself which performs loading of the patches. – Kirillx Nov 7 '16 at 14:38
  • I suppose the risk I am looking at is more operational, legal and compliance. KC is managing patches for multiple kernels for multiple vendors that patch upstream kernels. That is no small task. Keeping track of changes and ensuring that code is deployed securely is critical. I would be interested in seeing reviews from OS vendors of their patch sets. Third party code audits would be helpful too, given the critical nature of kernels and what they have access to. I just don't know what references I would give to auditors and potentially lawyers if this comes into question. – Aaron Nov 7 '16 at 15:37
  • We fortuitously signed up for a 30-day KernelCare trial right round the time of Spectre/Meltdown. This turned out to be a good practical test of their processes and ability to manage multiple large patch sets. The results weren't favourable to KernelCare and we decided it was riskier for our purposes to use them than not. Third-party reviews/certifications/audits might have swung the decision the other way. – hillsy Apr 9 '18 at 10:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.