SOLVED [CPANEL-21909] Is KernelCare's Free Symlink Protection free forever?

[cPanelLauren]

What's the contents of

/etc/sysconfig/kcare/kcare.conf

(I'm on CentOS 6, this may be different in CentOS 7?)

I'm going to guess that

PATCH_TYPE = free

isn't listed there, am I correct?

Actually:

# cat /etc/sysconfig/kcare/kcare.conf
AUTO_UPDATE=True
PATCH_TYPE = extra

And the same behavior persists whether I've got extra or free present (in my case)

I think when you install Kernelcare it doesn't care what kernel you have installed. It's only when you run kcarectl that it analyzes what kernel you are using and what kernelcare patches are available for it.

Since "fully paid for Kernelcare" supports the CentOSPlus kernel. Then kcarectl --update is assuming you are wanting to install the "fully paid for Kernelcare". But since there's no valid license found for that server IP on Kernelcare/CloudLinux's licensing servers, then it's assuming you want a trial. But a trial has already been allowed for that IP address at some point.

But I really don't know. Kernelcare/CloudLinux has always been a bit wonky to me. Not saying they are bad products... but seems the way of coding things leaves a bit to be desired.

I agree with you, I don't think it cares since the full version does support CentOS Plus kernels but my issue with this in the context of our users is: if they are going to *Only* support stock CentOS 6 & 7 kernels (which it looks like is the case) then the installation needs to notify the user and/or we need to stop offering it on unsupported kernels. Which is why I'm waiting to see what comes of their case.

 

[sparek-3]

Maybe I'm missing something. Is cPanel installing Kernelcare some where?

My guess would be that if a server is not using a stock CentOS/RHEL/CloudLinux kernel, then cPanel should not recommend installing the free symlink Kernelcare patch. In the case of a CloudLinux kernel being used, then the free symlink Kernelcare patch isn't needed.

Actually, my recommendation would be that whoever has root on the server should know whether they are using a stock kernel or something else. But apparently, that's asking an awful lot.

Additionally, if someone is running a non stock CentOS/RHEL kernel, then running kcarectl --set-patch-type free --update should return an error that Kernelcare does not support the free patchset for that kernel.

Probably would be helpful if Kernelcare/CloudLinux provided someway to send them the output of uname -r and then send back what Kernelcare patchsets are available for that kernel. This way cPanel wouldn't have to keep a list of active stock CentOS/RHEL kernels. cPanel could just query Kernelcare/CloudLinux, see if a free symlink patchset is available for that kernel and recommend that the user install it if it is not already installed and/or warn users that they are using an unsupported Kernelcare kernel and have no symlink protection (unless it's a stab, OpenVZ kernel... see how all of this gets wonky when you try to play everyone's server administrator?)

 

[sparek-3]

Something maybe kind of like:

curl -s -k https://patches.kernelcare.com/`cat /proc/version | sha1sum | cut -d " " -f 1`/2/kpatch.free.info | grep kpatch-description:

which should return something about symlink protection if your current kernel supports the free symlink protection.

Edit:
Er, probably a bit more complicated than that. It looks like the 2 isn't necessarily constant.

You would have to do a:

curl -s -k https://patches.kernelcare.com/`cat /proc/version | sha1sum | cut -d " " -f 1`/latest.v2

Which should return a number (or an nginx file not found page if the kernel is not supported at all) with a number. Then use that number instead of 2 in my first command.

Course, this then begs the question, what's the significance of latest.v2 and I don't know the answer to that... A prime example of, CloudLinux has the answer.. just a convoluted way of getting it.

 

[cPanelLauren]

Maybe I'm missing something. Is cPanel installing Kernelcare some where?

The security advisor is now recommending it in favor of the previous suggestion. It's installable directly from the SA interface

My guess would be that if a server is not using a stock CentOS/RHEL/CloudLinux kernel, then cPanel should not recommend installing the free symlink Kernelcare patch. In the case of a CloudLinux kernel being used, then the free symlink Kernelcare patch isn't needed.

I opened a case this morning to just this effect - CPANEL-21909 - Security Advisor recommending KernelCare Symlink Protection on unsupported kernels

Additionally, if someone is running a non stock CentOS/RHEL kernel, then running kcarectl --set-patch-type free --update should return an error that Kernelcare does not support the free patchset for that kernel.

This is essentially why I wanted to discuss this with CloudLinux/KernelCare and was waiting for their response. The issue being that they should not be allowing the installation of the symlink protection patch on systems with unsupported kernels - there should be some indication to the user that they're running a kernel that the symlink protection will not cover.

I also believe we should not be recommending the patch on systems running an unsupported kernel. I did hear back from them on this and they confirmed that the Symlink Protection Patch ONLY supports stock CentOS 6 & 7 as assumed in this thread previously. This means if you're running anything other you're getting a trial version of KernelCare, not the Symlink protection patch.

Actually, my recommendation would be that whoever has root on the server should know whether they are using a stock kernel or something else.

I agree with this 100% - hopefully this will show others as well that this is important to know.


Thanks!

 

[sparek-3]

Perhaps something like this attached script would help, from cPanel perspective.

mv kcaresupportedpatches.txt kcaresupportedpatches.sh
bash kcaresupportedpatches.sh

Basically, I think the key is taking the sha1sum of /proc/version and seeing what is available for that hash at https://patches.kernelcare.com. This may not be the most eloquent solution, but might give your developers something to code from.

You may want to work with CloudLinux/Kernelcare on this, because I'm not sure what the significance of https://patches.kernelcare.com/${VERSIONHASH}/latest.v2 not always being present is. Or where the arbitrary latest.v# comes in at.

But something like this would allow cPanel to see what kernel is installed on a server and whether or not if the Free Patchset is available for that kernel, if it needs a full KernelCare license, or if it's an unsupported KernelCare kernel.

 

[cPanelLauren]

Hi Everyone,


I wanted to update that while this case isn't in the Change Logs as being resolved the case is noted as having the "done" status and we can see the language in the perl module for kernelcare has been updated:

 Free KC tier symlink patcheset only supports CentOS 6 and Centos 7
# Note: This check implicitly ensures the system is not running CloudLinux
sub system_supports_kernelcare_free {
    my $centos_version = Cpanel::Sys::OS::Check::get_strict_centos_version();    # checks /etc/redhat-release + boot kernel version pattern
    return undef if not defined $centos_version or ( $centos_version != 6 and $centos_version != 7 );    # deal breaker (must be CentOS 6 or CentOS 7)
    return 1;
}

With that being said kernelcare symlink protection should no longer be offered/recommended in cPanel's Security Advisor on servers NOT running stock CentOS 6/7 kernels.

Please let us know if you experience any issues or have any concerns in regard to this.


Thanks!