[PATCH 0/8] Introduce FEDORA directory skeleton and transform scripts. Include start up 'test' profile having two gpgcheck scans

Shawn Wells shawn at redhat.com
Fri Sep 20 17:00:35 UTC 2013


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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20130920/27bc943d/attachment.html>


More information about the scap-security-guide mailing list