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:
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(a)redhat.com> wrote:
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
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
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
scap-security-guide mailing list