Hello,
I would like to point out a concern for any content that is destined to become Tier 3 or 4 at some future point (meaning USGCB). Tier 3 content must be used for the validation of scanner tools. All scanner tools from all vendors. So, this is not a openscap problem.
The rules for validation are in NIST IR7511. There is the following requirement:
SCAP.R.1700: The product SHALL be able to process the content that is representative of content published at Tier III and the OVAL repository which is associated with the platforms for which validation is being sought.
The way that labs test this is to get the official kickstart and modify some settings. They make a VM that is subcompliant and a VM that is supercompliant. For example, if a file's permission is supposed to be 0644, the subcompliant would be 0666 and supercompliant would be 0640. Or perhaps they set the min password length to 8 for subcompliant and 16 for supercompliant.
But this is only done for everything that makes sense to change. For example, a setting may say, "IP forwarding should be enabled or disabled as appropriate." This one can be made subcompliant but you can't make it supercompliant because its a boolean test (it is or is not correct).
What is expected of scanners is that they find and report all the subcompliant changes and ignore the supercompliant changes. (That is with the exception of the rpmverify file permissions test which is likely to fail.) That means using "greater than or equal" in places where the check is currently "equal" when security can be exceeded. Or perhaps instead of expressing a test for exact file permissions, turn the test upside down and express the bits that shouldn't be present (755 becomes 022).
While I don't know of a specific problem in the SSG content, I want everyone to be aware of this so that the content can be used for scanner validation. This might even be good to create a sub/super compliant VM and check as part of the release process.
Thanks, -Steve
Yes, this is a very good point -- thanks Steve!
From other discussion, per suggestion of G2, we should be able to
remove the lines that have "true" in checks such as the one below:
opening file_permissions_boot_grub_grub_conf.xml <unix:file_state id="_boot_grub_grub_conf_state_mode_0600" version="1"> <unix:suid datatype="boolean">false</unix:suid> <unix:sgid datatype="boolean">false</unix:sgid> <unix:sticky datatype="boolean">false</unix:sticky> <unix:uread datatype="boolean">true</unix:uread> <unix:uwrite datatype="boolean">true</unix:uwrite> <unix:uexec datatype="boolean">false</unix:uexec> <unix:gread datatype="boolean">false</unix:gread> <unix:gwrite datatype="boolean">false</unix:gwrite> <unix:gexec datatype="boolean">false</unix:gexec> <unix:oread datatype="boolean">false</unix:oread> <unix:owrite datatype="boolean">false</unix:owrite> <unix:oexec datatype="boolean">false</unix:oexec>
This should still pass files if they're more restrictive for some reason. Of course who knows what kind of functional problems might result, and the systemwide RPM verification will then fail, but the compliance intent of the check would still be met.
On Wed, Oct 16, 2013 at 12:55 PM, Steve Grubb sgrubb@redhat.com wrote:
Hello,
I would like to point out a concern for any content that is destined to become Tier 3 or 4 at some future point (meaning USGCB). Tier 3 content must be used for the validation of scanner tools. All scanner tools from all vendors. So, this is not a openscap problem.
The rules for validation are in NIST IR7511. There is the following requirement:
SCAP.R.1700: The product SHALL be able to process the content that is representative of content published at Tier III and the OVAL repository which is associated with the platforms for which validation is being sought.
The way that labs test this is to get the official kickstart and modify some settings. They make a VM that is subcompliant and a VM that is supercompliant. For example, if a file's permission is supposed to be 0644, the subcompliant would be 0666 and supercompliant would be 0640. Or perhaps they set the min password length to 8 for subcompliant and 16 for supercompliant.
But this is only done for everything that makes sense to change. For example, a setting may say, "IP forwarding should be enabled or disabled as appropriate." This one can be made subcompliant but you can't make it supercompliant because its a boolean test (it is or is not correct).
What is expected of scanners is that they find and report all the subcompliant changes and ignore the supercompliant changes. (That is with the exception of the rpmverify file permissions test which is likely to fail.) That means using "greater than or equal" in places where the check is currently "equal" when security can be exceeded. Or perhaps instead of expressing a test for exact file permissions, turn the test upside down and express the bits that shouldn't be present (755 becomes 022).
While I don't know of a specific problem in the SSG content, I want everyone to be aware of this so that the content can be used for scanner validation. This might even be good to create a sub/super compliant VM and check as part of the release process.
Thanks, -Steve _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide@lists.fedorahosted.org
-
Jeffrey Blank -
Steve Grubb