Are the different values that Lynis found in my Kernel (expected vs. real) a result of hacker compromise, or because I am using an older kernel?
In the Kernel hardening report section of Lynis, I'm seeing the result:
Result: sysctl key kernel.kptr_restrict has a different value than expected in scan profile. Expected=2, Real=0
Doing a google search, I came across the following article:
"If kptr_restrict is set to 0, no deviation from the standard %p behavior
occurs. If kptr_restrict is set to 1, if the current user (intended to
be a reader via seq_printf(), etc.) does not have CAP_SYSLOG (which is
currently in the LSM tree), kernel pointers using %pK are printed as
0's. If kptr_restrict is set to 2, kernel pointers using %pK are
printed as 0's regardless of privileges. Replacing with 0's was chosen
over the default "(null)", which cannot be parsed by userland %p, which
v3 adds the "2" setting, cleans up documentation, removes the CONFIG,
and incorporates changes and suggestions from Andrew Morton.
v2 improves checking for inappropriate context, on suggestion by Peter
Zijlstra. Thanks to Thomas Graf for suggesting use of a centralized
Are the different values that Lynis found in my Kernel (expected vs. real) a result of hacker compromise? Or rather because I'm using an older Centos 6.5 system instead of the lastest version of Centos? From the above article, it appears that the real value of "0" is standard default behaviour (although Lynis is expecting a newer more updated value of "2").
Is there a way I can manually set/change the values for the above items identified by Lynis? For example, how could I manually change the kernel.kptr value to "2" from the current "0"? How could I set the other Kernel values? Or does this require a Centos kernel/OS upgrade to a newer version of Centos?
There are a few ways to attempt to change this value. First, you can update your Linode's existing kernel to be sure that you are using the latest available kernel for your distribution. If you are using the latest kernel and still see that this is set to "0", you can also try upgrading to a newer version of your OS as you suggested, or try switching to a different kernel.
If you are willing to invest some time and troubleshooting, you can also try your hand at building and compiling your own custom kernel.
Personally I am not very familiar with Lynis, but from what I can see I expect this is simply a notification about the status of this setting, rather than evidence that this has been maliciously modified.