You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
name: 1.5.1 Ensure XD/NX support is enabled
NX/XD support is currently tested with a simple grep on dmesg. NX will match on other modules (such as the string QNX4). NX/XD error comes up on some system and not on other systems with identical settings, just dependent on how long the system has been running (the ringbuffer with the messages is erased sometimes as soon as 2 days).
I found a more reliable way of doing it is by querying journalctl -k --boot | grep -E "NX (Execute Disable) protection" and then tail -1 and then test for disabled but it is not guaranteed, once the logs rotate out its gone.
One can test if the administrator has disabled noexec32 in the https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt and one can test /proc/cpuinfo for whether NX is supported by the CPU. Not sure which approach to take for making sure it is enabled in a running kernel (by default it should be unless you're running some ancient hardware).
Also doesn't take into account ARM64 (eg. Raspberry Pi), XD is not a string that will match on current kernels
dmesg | grep NX with the expected response being "NX (Execute Disable) protection: active" is now standard for both AMD and Intel platforms according to the CIS Benchmark for Debian.
To Reproduce
Run the playbook on a host recently booted and one where dmesg has been cleared
Expected behavior
Test should reflect actual settings
The text was updated successfully, but these errors were encountered:
Describe the bug
name: 1.5.1 Ensure XD/NX support is enabled
NX/XD support is currently tested with a simple grep on dmesg. NX will match on other modules (such as the string QNX4). NX/XD error comes up on some system and not on other systems with identical settings, just dependent on how long the system has been running (the ringbuffer with the messages is erased sometimes as soon as 2 days).
I found a more reliable way of doing it is by querying journalctl -k --boot | grep -E "NX (Execute Disable) protection" and then tail -1 and then test for disabled but it is not guaranteed, once the logs rotate out its gone.
One can test if the administrator has disabled noexec32 in the https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt and one can test /proc/cpuinfo for whether NX is supported by the CPU. Not sure which approach to take for making sure it is enabled in a running kernel (by default it should be unless you're running some ancient hardware).
Also doesn't take into account ARM64 (eg. Raspberry Pi), XD is not a string that will match on current kernels
dmesg | grep NX with the expected response being "NX (Execute Disable) protection: active" is now standard for both AMD and Intel platforms according to the CIS Benchmark for Debian.
To Reproduce
Run the playbook on a host recently booted and one where dmesg has been cleared
Expected behavior
Test should reflect actual settings
The text was updated successfully, but these errors were encountered: