Hello folks,

I am new here, so I am not sure if this was discussed and closed earlier. If 
so, I am sorry for bringing it up again.

I notice that some of the OVAL checks and remediation scripts for 
network-kernel parameters seem to ignore the XCCDF input variable. For example, 
the rule "sysctl_net_ipv4_conf_all_accept_source_route" has an associated XCCDF 
variable "sysctl_net_ipv4_conf_all_accept_source_route_value" which it seems to 
be passing to the OVAL check:

    <oval id="sysctl_net_ipv4_conf_all_accept_source_route" 
value="sysctl_net_ipv4_conf_all_accept_source_route_value" />

However, the OVAL check and remediation script seem to be ignoring it:

      <unix:sysctl_state 
id="state_runtime_net_ipv4_conf_all_accept_source_route" version="1">
        <unix:value datatype="int" operation="equals">0</unix:value>
      </unix:sysctl_state>

Fix: 
    /sbin/sysctl -q -n -w net.ipv4.conf.all.accept_source_route=0

This is a problem only when someone decides to alter the default variable value 
from "disabled" to "enabled", which I understand is not very likely. 
Nevertheless, someone using "refine-value" gets an incorrect evaluation and 
remediation result.

I would like to fix this but I am not sure what is the right way forward. Most 
of these sysctl parameters are binary valued and one of those is the 
conventional  "good" value you'd expect. So unless these XCCDF variables are 
here for a reason, the simplest solution (I would assume) is to remove these 
XCCDF variables altogether and just evaluate against the "good" value. 

The other approach would be to make OVAL and the fix use the variable. The OVAL 
sysctl_state's value field should be able to refer to an external variable if I 
am not mistaken. 

Please let me know what you think.
 
Thank you for your time. 

Best Regards,
Gautam.
--
SCAP Security Guide mailing list
[email protected]
https://lists.fedorahosted.org/admin/lists/[email protected]
https://github.com/OpenSCAP/scap-security-guide/

Reply via email to