KernelCare Patch Unknown Kernel Alerts
I know the main topic of this has been covered in several threads as shown below, but I'm still not clear of the implications of patched vs unpatched servers. This is a followup to my thread:
I understand that there is a delay between when a new CentOS kernel is released, and when the KernelCare (KC) free patches become available. As a consequence, emails get sent every 4 hours indicating that KC free cannot identify the installed kernel.
My question is: if I spend so much time without the KC patch, does that mean the server is vulnerable to the SymLink issue during that period? If I only have accounts for reasonably trusted users, might I be better off with the "stock" Apache SymLink protection, and just leaving the KC patch out?
-
does that mean the server is vulnerable to the SymLink issue during that period?
The Symlink protection provided by kernelcare in this instance is not effective if the kernel is not supported.If I only have accounts for reasonably trusted users, might I be better off with the "stock" Apache SymLink protection, and just leaving the KC patch out?
I can't answer that for you to be honest the kernelcare patch adds some protection but it's up to you if you want to use it our documentation here is informative and provides alternate solutions: Symlink Race Condition Protection - EasyApache 4 - cPanel Documentation0 -
What are the alternatives then? To use the KernelCare patches "correctly" then you must remain in control of the kernel updates I suppose? What is required to achieve that? What is the value of supporting symlinks and can they simply be disabled if the functionality is not required? 0 -
Hi @CanadaGuy The article I showed you lists every symlink protection alternative available I would suggest reading it. They can be disabled in the Apache configuration if you don't want the functionality. 0 -
Hi @CanadaGuy The article I showed you lists every symlink protection alternative available I would suggest reading it. They can be disabled in the Apache configuration if you don't want the functionality.
Thanks, I think I missed some details on my first pass through.0 -
I'm assuming this means that perhaps when the free KC patch is available for the previously unsupported installed kernel, it reports this message about trialing because an update is available. Reinstalling the patch seems to resolve the issue. Is this something I should expect each time a kernel upgrade is applied?
That is incorrect, the message about trialing occurs when the kernel is unsupported for symlink protection and KernelCare attempts to install a trial of full KernelCare, which supports more than just stock CentOS. To bypass this we are making changes to the Security Advisor to stop suggesting KernelCare to unsupported kernels through multiple cases internally, there is a report to KernelCare specifically on this as well.The user in the other thread suggested the idea of disabling kernel updates, monitoring when a new kernel is released, and only updating when the KC free patch is available. Is there any plan to provide a nicer user experience by having cPanel detect that the KC patch is installed, and ask if you want to upgrade the kernel such that it will be unsupported by the KC free patch for a while?
The changes made to the SA suggestions will include NOT suggesting kernelcare for unsupported kernels including kernels that are updated past what kernelcare supports.In the bigger picture, is this something that will be permanently resolved at kernel level at some point, thereby eliminating the need for an external patch? Or is this a special case that only applies to cPanel installations?
Meaning that is symlink protection something specific to cPanel or is it something that will be implemented in the CentOS Kernel? No this is not specific to cPanel installations only, and I can't speak for the CentOS kernel developments but I would assume that symlink race conditions will remain an issue requiring protection.0 -
To bypass this we are making changes to the Security Advisor to stop suggesting KernelCare to unsupported kernels through multiple cases internally, there is a report to KernelCare specifically on this as well.
Could control for KernelCare Free be done through other means, like a mini module which allows you to control various details about the KC patch, provide kernel support information, etc? If the KC patch is currently one of the best mitigation methods, could a switch be added to the installer that updates the kernel to the latest one supported? Thanks for providing follow-up details. This has been a great help.0 -
Hi @CanadaGuy You're most welcome! I'm sure all of those would be possible but I don't have details or insight into when or if they will be implemented as ultimately it's up to KernelCare to make those modifications. 0
Please sign in to leave a comment.
Comments
8 comments