Tier 3 content issue

Jeffrey Blank blank at eclipse.ncsc.mil
Mon Oct 28 01:09:15 UTC 2013


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 at 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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide


More information about the scap-security-guide mailing list