Shared Checks/Fixes ...

Jan Lieskovsky jlieskov at redhat.com
Thu Apr 9 12:31:20 UTC 2015


Hello Trey,

----- Original Message -----
> From: "Trey Henefield" <trey.henefield at ultra-ats.com>
> To: "scap-security-guide at lists.fedorahosted.org" <scap-security-guide at lists.fedorahosted.org>
> Sent: Wednesday, April 8, 2015 11:13:48 PM
> Subject: Shared Checks/Fixes ...
> 
> Greetings,
> 
> 
> 
> I wanted to propose a change to the current structure in place for shared
> checks (shared/oval) and fixes (shared/fixes/bash). I was curious to get
> everyone’s opinion before committing.

  Thank you for opening this topic.

> 
> 
> 
> So the problem I see is with the symbolic linking of checks and fixes to the
> shared folder. I have found it problematic when working between different
> operating systems, file systems, and version control systems.

  Right from the beginning we knew the concept of symbolic links will
introduce issues when dealing with SSG content across multiple OS versions.
But so far there hasn't been urgent need to fix this (to be read as so far
there haven't been much reports current behaviour causing issues for developers).
But as the count of the SCAP content products raises it's time to fix this.

> 
> 
> 
> Rather than creating symbolic links to certain oval checks in the shared/oval
> folder, we could choose to just process all oval checks in both the
> project’s checks folder and the shared/oval folder.

The original idea behind introducing /shared directory was the following -
when trying to identify corresponding OVAL check for particular XCCDF rule
the following scheme should be applied:
* when there's is OVAL check for that product present in input/checks
  directory for that product, this OVAL check should be used with priority,
* when there isn't, use the corresponding (equally named) OVAL check from
  shared/ directory.

During the time we advanced the idea / concept even more in the sense that
shared/ version of OVAL checks doesn't necessarily need to be working for
all of the products having these checks (that's the case below mentioning
there are shared/ OVAL checks used just for RHEL-7 & Fedora systems, while
RHEL-6 version is different / RHEL-6 product specific).

> 
> 
> 
> However, not all checks in the current ‘shared/oval’ folder are shared by all
> OS. For example, there are some that only apply to RHEL7 and Fedora, and not
> RHEL6.

See the explanation above why that's the case.

> 
> 
> 
> Any thoughts?

If I should attempt to summary:
* the concept of shared/ checks has proven to be beneficial (in the sense it's
  less work to keep just one concrete copy updated than try to keep updated multiple
  identical copies),
* the mechanism of symbolic links is not the way to go (since it's known not to work
  e.g. on Microsoft Windows OS systems),

So IMHO we want to keep the shared/ OVAL checks / fixes concept, but implement it
different way. Maybe as already suggested by modificating the build process to look
not just into CWD for OVAL check / remediation fix, but also to look into particular
subdirectory of shared/ directory (OVAL checks vs fixes) simultaneously with preserving
priority (if there's OVAL check / fix present for that product, use that one. If there
isn't and there's is symlink, use the /shared version. If there isn't even symlink,
return no check / no fix available leading to 'notchecked' state).

HTH

Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team

P.S.: As the count of products we produce SCAP content for is only going to
      raise in the future, IMHO concept of /shared directory for OVAL checks &
      fixes can only save us a lot of duplicate work in the future (when compared
      to the scenario of managing multiple copies of the same file on per product
      basis).

> 
> 
> 
> Thanks!
> 
> 
> 
> Best regards,
> 
> 
> 
> 
> 
> Trey Henefield, CISSP
> 
> Senior IAVA Engineer
> 
> 
> 
> Ultra Electronics
> 
> Advanced Tactical Systems, Inc.
> 
> 4101 Smith School Road
> 
> Building IV, Suite 100
> 
> Austin, TX 78744 USA
> 
> 
> 
> Trey.Henefield at ultra-ats.com
> 
> Tel: +1 512 327 6795 ext. 647
> 
> Fax: +1 512 327 8043
> 
> Mobile: +1 512 541 6450
> 
> 
> 
> www.ultra-ats.com
> 
> 
> 
> 
> 
> 
> Disclaimer
> The information contained in this communication from
> trey.henefield at ultra-ats.com sent at 2015-04-08 17:13:55 is private and may
> be legally privileged or export controlled. It is intended solely for use by
> scap-security-guide at lists.fedorahosted.org and others authorized to receive
> it. If you are not scap-security-guide at lists.fedorahosted.org you are hereby
> notified that any disclosure, copying, distribution or taking action in
> reliance of the contents of this information is strictly prohibited and may
> be unlawful.
> 
> 
> --
> SCAP Security Guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> https://github.com/OpenSCAP/scap-security-guide/


More information about the scap-security-guide mailing list