On 9/16/13 6:15 AM, Jan Lieskovsky wrote:
Hello David,

> Ahh, excellent - glad to see the addition of Fedora content!
> 
> Two quick things before I can ack this patch set:
> 
> 1) Have the OVAL checks been tested in Fedora 19? In the RHEL 6 content,
> there is a testcheck.py within /input/checks/ -- it might be worth copying
> that over.
Thank you for your reply and suggestion(s). No, the proposed content haven't been
tested via testcheck.py / verify-input-sanity.py utilities yet (have just focused
those scripts listed in Makefile to work [and tested that those OVAL definitions /
scans work properly on Fedora-19 and return 'not applicable' for other products]).

But definitely reasonable enhancement. Attached file contains current output of
its run in / against the RHEL6 directory. Those warnings cover definitions
not currently present in Fedora (not saying those shouldn't be fixed of course) =>
we should be safe wrt to these and Fedora.

Regarding the traceback I will try to find why / where it's failing, and submit
a patch to overcome it. Subsequently (when got it working) we could possibly
add verify-input-sanity.py script it to be run by default (hopefully under 
make checks', 'make validate-xml', or 'make validate' clauses), so we would
catch possible regressions / notice something changed into wrong direction
in the future.

> 
> 2) When copying XCCDF and OVAL from the RHEL 6 content, we should be careful
> to remove the test attestation that was done under RHEL, and re-add it with
> the tester's initials and date when tested under Fedora 19.
Original wanted to ask what you mean under test attestation, but Shawn clarified
already :). Sure will grep the content for its occurrences and remove particular
records for now.

Do you possibly have link to some documentation, how is that attestation created?

Is it like, SSG content is committed into the repository (after internal review).
Subsequently some 3-rd party performs independent testing of the profiles (or
even individual OVAL file definitions) and if they pass the review, grants the
attestation? What kind of organisation does this for RHEL6? And who would be
able to grant these for Fedora? IOW how this attestation testing should look like
for Fedora?
Just noticed this never was replied to. Apologies!

Much of the RHEL6 OVAL content was inherited from historic RHEL5 initiatives, and there was some RHEL6 OVAL that was rushed into the commit tree so we could have something to get the project started. Due to the inheritance of a large body of RHEL5 OVAL, there was a desire (need?) to re-test all checks on RHEL6 for proper functionality.... and the test attestation tag was born.

As patches earlier in the week indicated, testing involves creating fail & pass configurations and running the testcheck python script. An example:
https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-September/004112.html

Checks requiring testing are indicated via the table-stig-rhel6-testinfo.html (which is generated via 'make tables'). Note the differences between 'package_aide_installed' and 'enable_selinux_bootloader' here:
http://scap-securityguide.rhcloud.com/RHEL6/output/table-stig-rhel6-testinfo.html

As the Fedora OVAL content is largely net-new, having an author submit OVAL patches with testing evidence should suffice. The 2nd party ACK process should verify proper testing evidence, OVAL schema, etc.