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.
On 12/10/2015 07:01 AM, gautams@hpe.com 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"/>
~š.
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:isimluk@fedoraproject.org] 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, gautams@hpe.com 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 scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
On 12/14/2015 10:09 AM, S, Gautam wrote:
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.
Hello Gautam,
Great to hear this worked for you!
The solution you propose seems sensible to me.
The other that comes to my mind would be a sinble CSV file that would contain all the information, something like:
"<parameter>,<value-if-applicable>,<variable-if-applicable>"
Just an option.
Thanks! ~š.
Thank you!
Regards, Gautam.
-----Original Message----- From: Šimon Lukašík [mailto:isimluk@fedoraproject.org] 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, gautams@hpe.com 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 scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/ -- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
Hello Simon,
Thank you for taking a look at the solution. I will start looking at using a simple CSV file to solve this and try to make the "create_sysctl_checks.py" module capable of identifying the right template to use.
Another point that wanted to check with you was on the changes I need to make on the documentation. The rule that I modified for the sample pull request, "sysctl_net_ipv4_conf_all_accept_source_route" has a title "Disable Kernel Parameter for Accepting Source-Routed Packets for All Interfaces". When we are providing the option to enable or disable the parameter to the user, the title, description, rationale and OCIL content become inaccurate (and confusing) because they all refer to just disabling the parameter.
I changed the rule name to "Configure Kernel Parameter for Accepting Source-Routed Packets for All Interfaces" to make it slightly unambiguous leaving all the other content intact. I later realized that this is probably not a good thing to do either because there might be user tailored profiles which use the original rule name and these would now break. Should I just leave all the XCCDF content untouched and leave it at that?
Thank you.
Regards,
Gautam.
-----Original Message----- From: Šimon Lukašík [mailto:isimluk@fedoraproject.org] Sent: Tuesday, December 15, 2015 3:33 PM To: SCAP Security Guide Subject: Re: XCCDF variables associated with "sysctl_net_ipv4_conf_*" do not seem to be getting used.
Hello Gautam,
Great to hear this worked for you!
The solution you propose seems sensible to me.
The other that comes to my mind would be a sinble CSV file that would contain all the information, something like:
"<parameter>,<value-if-applicable>,<variable-if-applicable>"
Just an option.
Thanks! ~š.
On 12/15/15 4:02 AM, Šimon Lukašík wrote:
On 12/14/2015 10:09 AM, S, Gautam wrote:
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.
Hello Gautam,
Great to hear this worked for you!
The solution you propose seems sensible to me.
The other that comes to my mind would be a sinble CSV file that would contain all the information, something like:
"<parameter>,<value-if-applicable>,<variable-if-applicable>"
Just an option.
Thanks! ~š.
Perhaps not well documented, but the variables should be in the format of ${xccdf_check_name}_value.
e.g. in the RHEL6 sysctl template file, we have "net.ipv4.conf.all.accept_source_route." The build system will convert this into an OVAL file named sysctl_net_ipv4_conf_all_accept_source_route. So the variable should be sysctl_net_ipv4_conf_all_accept_source_route_value.
Hello Shawn,
I think that would greatly simplify the process!
The sysctl CSV file can just be "<parameter>,<value-if-applicable>". If the value is present, "create_sysctl_checks.py" can work as it does so currently. If there is no value, deduce the variable name from the sysctl parameter itself and use it with the new template which will contain the external variable and the var-ref within state. I hope that looks fine.
Thank you.
Regards, Gautam.
-----Original Message----- From: Shawn Wells [mailto:shawn@redhat.com] Sent: Wednesday, December 16, 2015 9:54 AM To: scap-security-guide@lists.fedorahosted.org Subject: Re: XCCDF variables associated with "sysctl_net_ipv4_conf_*" do not seem to be getting used.
Perhaps not well documented, but the variables should be in the format of ${xccdf_check_name}_value.
e.g. in the RHEL6 sysctl template file, we have "net.ipv4.conf.all.accept_source_route." The build system will convert this into an OVAL file named sysctl_net_ipv4_conf_all_accept_source_route. So the variable should be sysctl_net_ipv4_conf_all_accept_source_route_value. -- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
scap-security-guide@lists.fedorahosted.org