Hello folks, I have tried out the recommended changes for one of the rules. I updated the two extended definitions, (one for checking the run-time sysctl value and the other for the static value in the config file) and the remediation script to start using the XCCDF:value field. This seems to be working.
The OVAL checks and remediation scripts for rules based on values of sysctl kernel parameters are as of now automatically generated from a template using the "create_sysctl_checks.py" module. The input CSV file has a "<paramter>, <value>" format. The changes I made are overriding these auto-generated scripts. Of the 19 sysctl values in the input CSV file in RHEL6, 12 are affected by the current issue. So I was wondering if it made sense to add a new CSV file with a "<paramter>,<variable_name>" format along with a new template file and python module which could auto-generate content using the variable rather than a hard-coded value. Let me know if this would be a cleaner solution. Thank you! Regards, Gautam. -----Original Message----- From: Šimon Lukašík [mailto:[email protected]] Sent: Thursday, December 10, 2015 4:25 PM To: SCAP Security Guide Subject: Re: XCCDF variables associated with "sysctl_net_ipv4_conf_*" do not seem to be getting used. On 12/10/2015 07:01 AM, [email protected] wrote: > 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. You are very right in your conclusions, Gautam. I don't know why the XCCDF:value exists in the first place in this case. However, I would proceed with fixing the OVAL to respect the XCCDF:value. You need to change the sysctl_state <unix:value datatype="int" operation="equals">0</unix:value> to something like <unix:value datatype="int" operation="equals"var_ref="sysctl_net_ipv4_conf_all_accept_source_route_value" var_check="all"/> ~š. -- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected] https://github.com/OpenSCAP/scap-security-guide/ -- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected] https://github.com/OpenSCAP/scap-security-guide/
