I agree with Greg about providing more detail. I am especially curious about the multiple filesystems and version control systems.

The (shared/oval) and (shared/fixes/bash) are for checks and fixes that span multiple OS versions (App versions can be used as well if needed). Not all the checks and fixes have to apply to every OS/App that is in the SSG. Some might be for all versions and content in the SSG, and some might only apply to a few. For example, not all GDM settings apply to the same OS (i.e. 1 to many but not all). For RHEL7 and Fedora, DCONF settings apply to configure and lock GDM settings, but DCONF does not exist at all in RHEL5 or 6 as those settings are GCONF. Not all RHEL5 and 6 GCONF settings are equal either, etc. etc. etc. You could feasibly have a check that spans over RHEV, OpenStack, RHEL, Ubuntu, etc.

Synchronizing the same file over multiple locations instead seems to take wwwaayyyy more work and space than soft links and can be an entire can of worms itself.

As Shawn alluded to, XSLT magic would be the best way of handling things.

On Wed, Apr 8, 2015 at 4:20 PM, Greg Elin gregelin@gitmachines.com wrote:

Trey,

Could you please provide a bit more detail?

I am interested bc I am trying to understand best way of eventually adding Ubuntu SCAP into SSG, and have been wondering to link or not to link? That is the question. Whether tis better to suffer to link shared files and risk fragility in future or to pick up and clone rules into each distribution and battle the onslaught of synchronizing changes in multiple directories.

In any case, I thought the share folder was holding source code for oval checks that were common to more than one target platform. Then, when SSG is built the shared source is turned into actual OVAL xml SCAP.

Have I completely missed that actual shared OVAL xml SCAP is in the distributed SSG?

If the share is just in the source code, I am not following the idea of running tests in both shared and non shared folders.

If the share is in the distribution, are you suggesting that a scan just run all tests in both shared and non shared?

Greg Elin P: 917-304-3488 E: gregelin@gitmachines.com

Sent from my iPhone

On Apr 8, 2015, at 5:13 PM, Trey Henefield trey.henefield@ultra-ats.com wrote:

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.

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.

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.

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.

Any thoughts?

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@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@ultra-ats.com trey.henefield@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@lists.fedorahosted.org scap-security-guide@lists.fedorahosted.org * and others authorized to receive it. If you are not * scap-security-guide@lists.fedorahosted.org scap-security-guide@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/

-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/

----- Original Message -----

From: "Simon Lukasik" isimluk@fedoraproject.org To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Thursday, April 9, 2015 10:09:39 AM Subject: Re: Shared Checks/Fixes ...

[snip]

I propose

• to remove symlinks
• to amend build process to look into shared directory if fix/check is

missing in current directory

That should be the easiest path that enables flexibility and lower maint costs going forward.

+1

Thank you everyone for the responses!

I completely agree with the benefits of the shared directory. That really wasn't so much my concern, but rather a better way of utilizing it.

As Jan pointed out, I am using a mixed Windows/Linux environment, making it challenging to maintain the symbolic links when traversing different filesystems (NTFS -> EXT).

So far, I have looked at some minor adjustments that can be made to shared/transforms/combinechecks.py and shared/transforms/combinefixes.py.

I have tried adding an additional parameter through the Makefile to point to the $(SHARED)/oval folder and adding the following to shared/transforms/combinechecks.py:

for filename in os.listdir(sys.argv[2]): if filename.endswith(".xml"): with open(sys.argv[2] + "/" + filename, 'r') as xml_file: body = body + xml_file.read() + + for filename in os.listdir(sys.argv[3]): + if filename.endswith(".xml"): + with open(sys.argv[3] + "/" + filename, 'r') as xml_file: + body = body + xml_file.read()

This has the proper effect of adding all project-specific checks first, then adding in all shared checks. If there is a shared check with the same name as a project-specific check, the shared check will be excluded in favor of the project-specific check. Although, I personally think the identifier of each shared check should be prefaced with 'shared_' to help identify it as a shared check. This could help to prevent duplicate IDs in any case.

The downside of the above code though is that it adds all oval checks in the shared folder to the oval output of a specific project. It builds fine. But 'make validate' complains about oval checks not being included in the XCCDF profile. There should be a better way to filter xml file content added from the shared folder to just those specific to the project's supported platform.

As Shawn has hinted, this could perhaps be resolved in some XSLT magic. Are there any XSLT magicians out there? ;) This is a language I have yet to conquer.

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@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450

www.ultra-ats.com

-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Jan Lieskovsky Sent: Thursday, April 09, 2015 7:31 AM To: SCAP Security Guide Subject: Re: Shared Checks/Fixes ...

Hello Trey,

----- Original Message -----

From: "Trey Henefield" trey.henefield@ultra-ats.com To: "scap-security-guide@lists.fedorahosted.org" scap-security-guide@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@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@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@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/

-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/

Disclaimer The information contained in this communication from trey.henefield@ultra-ats.com sent at 2015-04-09 10:04:14 is confidential and may be legally privileged. It is intended solely for use by scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@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.

Hi Gabe,

I probably should have been more specific as to the Makefile change, but essentially, it just involved changing the combinechecks.py line from this:

$(SHARED)/$(TRANS)/combinechecks.py $(CONF) $(IN)/checks > $(OUT)/unlinked-$(PROD)-oval.xml

To this:

$(SHARED)/$(TRANS)/combinechecks.py $(CONF) $(IN)/checks $(SHARED)/oval > $(OUT)/unlinked-$(PROD)-oval.xml

That part seems to work great with the code I provided. But the filtering of shared checks included is where the challenge lies.

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@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450

www.ultra-ats.com

From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Gabe Alford Sent: Thursday, April 09, 2015 9:59 AM To: SCAP Security Guide Subject: Re: Shared Checks/Fixes ...

On Thu, Apr 9, 2015 at 8:04 AM, Trey Henefield <trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com> wrote:

Thank you everyone for the responses!

I completely agree with the benefits of the shared directory. That really wasn't so much my concern, but rather a better way of utilizing it.

As Jan pointed out, I am using a mixed Windows/Linux environment, making it challenging to maintain the symbolic links when traversing different filesystems (NTFS -> EXT).

So far, I have looked at some minor adjustments that can be made to shared/transforms/combinechecks.py and shared/transforms/combinefixes.py.

I have tried adding an additional parameter through the Makefile to point to the $(SHARED)/oval folder and adding the following to shared/transforms/combinechecks.py:

for filename in os.listdir(sys.argv[2]): if filename.endswith(".xml"): with open(sys.argv[2] + "/" + filename, 'r') as xml_file: body = body + xml_file.read() + + for filename in os.listdir(sys.argv[3]): + if filename.endswith(".xml"): + with open(sys.argv[3] + "/" + filename, 'r') as xml_file: + body = body + xml_file.read()

You could do it this way for combinechecks.py: + SHARED = os.environ.get('SHARED_DIR')

for filename in os.listdir(sys.argv[2]): if filename.endswith(".xml"): + local_path = sys.argv[2] + "/" + filename + if not os.path.islink(local_path): + xml_filename = local_path + else: + xml_filename = SHARED + "/oval/" + filename - with open(sys.argv[2] + "/" + filename, 'r') as xml_file: + with open(xml_filename, 'r') as xml_file:

Then add the following to the Makefile(s): export SHARED_DIR=$(SHARED)

This has the proper effect of adding all project-specific checks first, then adding in all shared checks. If there is a shared check with the same name as a project-specific check, the shared check will be excluded in favor of the project-specific check. Although, I personally think the identifier of each shared check should be prefaced with 'shared_' to help identify it as a shared check. This could help to prevent duplicate IDs in any case.

The downside of the above code though is that it adds all oval checks in the shared folder to the oval output of a specific project. It builds fine. But 'make validate' complains about oval checks not being included in the XCCDF profile. There should be a better way to filter xml file content added from the shared folder to just those specific to the project's supported platform.

As Shawn has hinted, this could perhaps be resolved in some XSLT magic. Are there any XSLT magicians out there? ;) This is a language I have yet to conquer.

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@ultra-ats.commailto:Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647tel:%2B1%20512%20327%206795%20ext.%20647 Fax: +1 512 327 8043tel:%2B1%20512%20327%208043 Mobile: +1 512 541 6450tel:%2B1%20512%20541%206450

www.ultra-ats.comhttp://www.ultra-ats.com

-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Jan Lieskovsky Sent: Thursday, April 09, 2015 7:31 AM To: SCAP Security Guide Subject: Re: Shared Checks/Fixes ... Hello Trey,

----- Original Message -----

From: "Trey Henefield" <trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com> To: "scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org" <scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@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@ultra-ats.commailto:Trey.Henefield@ultra-ats.com

Tel: +1 512 327 6795 ext. 647tel:%2B1%20512%20327%206795%20ext.%20647

Fax: +1 512 327 8043tel:%2B1%20512%20327%208043

Mobile: +1 512 541 6450tel:%2B1%20512%20541%206450

www.ultra-ats.comhttp://www.ultra-ats.com

Disclaimer The information contained in this communication from trey.henefield@ultra-ats.commailto:trey.henefield@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@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@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@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/

-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/

Disclaimer The information contained in this communication from trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com sent at 2015-04-09 10:04:14 is private and may be legally privileged or export controlled. It is intended solely for use by scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@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@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/

Hi Gabe,

I understand what you’re saying, but the goal is to get rid of symbolic links completely. If we still rely on symbolic links, then we still face the same problem.

How would one know if a particular oval check is missing?

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@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450

www.ultra-ats.com

From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Gabe Alford Sent: Thursday, April 09, 2015 12:12 PM To: SCAP Security Guide Subject: Re: Shared Checks/Fixes ...

Hey Trey, IMO rather than read all files from Dir A and then reading all files from Dir B and then processing which content to filter, it would be better to list the content from the current working directory (CWD), check if the file is valid, a symlink (just in case there is need for one), or missing. If the file is a symlink or missing, get the actual file from the shared/oval directory. The logic would seem easier to implement that way. Gabe

On Thu, Apr 9, 2015 at 10:27 AM, Trey Henefield <trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com> wrote: Hi Gabe,

I probably should have been more specific as to the Makefile change, but essentially, it just involved changing the combinechecks.py line from this:

$(SHARED)/$(TRANS)/combinechecks.py $(CONF) $(IN)/checks > $(OUT)/unlinked-$(PROD)-oval.xml

To this:

$(SHARED)/$(TRANS)/combinechecks.py $(CONF) $(IN)/checks $(SHARED)/oval > $(OUT)/unlinked-$(PROD)-oval.xml

That part seems to work great with the code I provided. But the filtering of shared checks included is where the challenge lies.

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@ultra-ats.commailto:Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647tel:%2B1%20512%20327%206795%20ext.%20647 Fax: +1 512 327 8043tel:%2B1%20512%20327%208043 Mobile: +1 512 541 6450tel:%2B1%20512%20541%206450

www.ultra-ats.comhttp://www.ultra-ats.com

From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Gabe Alford Sent: Thursday, April 09, 2015 9:59 AM

To: SCAP Security Guide Subject: Re: Shared Checks/Fixes ...

On Thu, Apr 9, 2015 at 8:04 AM, Trey Henefield <trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com> wrote:

Thank you everyone for the responses!

I completely agree with the benefits of the shared directory. That really wasn't so much my concern, but rather a better way of utilizing it.

As Jan pointed out, I am using a mixed Windows/Linux environment, making it challenging to maintain the symbolic links when traversing different filesystems (NTFS -> EXT).

So far, I have looked at some minor adjustments that can be made to shared/transforms/combinechecks.py and shared/transforms/combinefixes.py.

I have tried adding an additional parameter through the Makefile to point to the $(SHARED)/oval folder and adding the following to shared/transforms/combinechecks.py:

for filename in os.listdir(sys.argv[2]): if filename.endswith(".xml"): with open(sys.argv[2] + "/" + filename, 'r') as xml_file: body = body + xml_file.read() + + for filename in os.listdir(sys.argv[3]): + if filename.endswith(".xml"): + with open(sys.argv[3] + "/" + filename, 'r') as xml_file: + body = body + xml_file.read()

You could do it this way for combinechecks.py: + SHARED = os.environ.get('SHARED_DIR')

for filename in os.listdir(sys.argv[2]): if filename.endswith(".xml"): + local_path = sys.argv[2] + "/" + filename + if not os.path.islink(local_path): + xml_filename = local_path + else: + xml_filename = SHARED + "/oval/" + filename - with open(sys.argv[2] + "/" + filename, 'r') as xml_file: + with open(xml_filename, 'r') as xml_file:

Then add the following to the Makefile(s): export SHARED_DIR=$(SHARED)

This has the proper effect of adding all project-specific checks first, then adding in all shared checks. If there is a shared check with the same name as a project-specific check, the shared check will be excluded in favor of the project-specific check. Although, I personally think the identifier of each shared check should be prefaced with 'shared_' to help identify it as a shared check. This could help to prevent duplicate IDs in any case.

The downside of the above code though is that it adds all oval checks in the shared folder to the oval output of a specific project. It builds fine. But 'make validate' complains about oval checks not being included in the XCCDF profile. There should be a better way to filter xml file content added from the shared folder to just those specific to the project's supported platform.

As Shawn has hinted, this could perhaps be resolved in some XSLT magic. Are there any XSLT magicians out there? ;) This is a language I have yet to conquer.

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@ultra-ats.commailto:Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647tel:%2B1%20512%20327%206795%20ext.%20647 Fax: +1 512 327 8043tel:%2B1%20512%20327%208043 Mobile: +1 512 541 6450tel:%2B1%20512%20541%206450

www.ultra-ats.comhttp://www.ultra-ats.com

-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Jan Lieskovsky Sent: Thursday, April 09, 2015 7:31 AM To: SCAP Security Guide Subject: Re: Shared Checks/Fixes ... Hello Trey,

----- Original Message -----

From: "Trey Henefield" <trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com> To: "scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org" <scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@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@ultra-ats.commailto:Trey.Henefield@ultra-ats.com

Tel: +1 512 327 6795 ext. 647tel:%2B1%20512%20327%206795%20ext.%20647

Fax: +1 512 327 8043tel:%2B1%20512%20327%208043

Mobile: +1 512 541 6450tel:%2B1%20512%20541%206450

www.ultra-ats.comhttp://www.ultra-ats.com

Disclaimer The information contained in this communication from trey.henefield@ultra-ats.commailto:trey.henefield@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@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@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@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/

-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/

Disclaimer The information contained in this communication from trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com sent at 2015-04-09 10:04:14 is private and may be legally privileged or export controlled. It is intended solely for use by scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@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@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/

-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/

Hi Gabe,

There is just too much data in that file to parse through and make sense of.

But, I think I may have found a way:

Going on my previous theory, I have done this (considering a RHEL6 target):

for filename in os.listdir(sys.argv[2]): if filename.endswith(".xml"): with open(sys.argv[2] + "/" + filename, 'r') as xml_file: body = body + xml_file.read() + + for filename in os.listdir(sys.argv[3]): + if filename.endswith(".xml"): + with open(sys.argv[3] + "/" + filename, 'r') as xml_file: + filecontent = xml_file.read() + if '<platform>multi_platform_rhel</platform>' in filecontent: + body = body + filecontent + elif '<platform>Red Hat Enterprise Linux 6</platform>' in filecontent: + body = body + filecontent

The above produces much more desirable content. It still fails ‘make validate’ but for obvious reasons. There is one shared check ‘accounts_password_pam_pwquality’ that is not included in any of the RHEL6 profiles.

Of course with the above change, we would need to pull in the platform-specific (Red Hat Enterprise Linux 6) and platform-generic (multi_platform_rhel) values. This could be easily done via the method used to pull in the shared oval paths. However, such change would require all other projects to update their Makefile with the corresponding additional parameters.

The following change would allow the shared folder to be processed only if the corresponding parameters were specified in the Makefile:

for filename in os.listdir(sys.argv[2]): if filename.endswith(".xml"): with open(sys.argv[2] + "/" + filename, 'r') as xml_file: body = body + xml_file.read() + + if len(sys.argv) == 6: + for filename in os.listdir(sys.argv[3]): + if filename.endswith(".xml"): + with open(sys.argv[3] + "/" + filename, 'r') as xml_file: + filecontent = xml_file.read() + if '<platform> sys.argv[4]</platform>' in filecontent: + body = body + filecontent + elif '<platform> sys.argv[5]</platform>' in filecontent: + body = body + filecontent

Any objections to doing this?

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@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450

www.ultra-ats.com

From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Gabe Alford Sent: Thursday, April 09, 2015 12:50 PM To: SCAP Security Guide Subject: Re: Shared Checks/Fixes ...

Trey,

Might be a hack, but what about reading in what is generated in output/ssg.ini. Filter out what is not oval content and compare to the contents in input/checks/, and whatever is not in input/checks, get from shared/oval? Gabe

On Thu, Apr 9, 2015 at 11:36 AM, Trey Henefield <trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com> wrote: Hi Gabe,

I understand what you’re saying, but the goal is to get rid of symbolic links completely. If we still rely on symbolic links, then we still face the same problem.

How would one know if a particular oval check is missing?

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@ultra-ats.commailto:Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647tel:%2B1%20512%20327%206795%20ext.%20647 Fax: +1 512 327 8043tel:%2B1%20512%20327%208043 Mobile: +1 512 541 6450tel:%2B1%20512%20541%206450

www.ultra-ats.comhttp://www.ultra-ats.com

From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Gabe Alford Sent: Thursday, April 09, 2015 12:12 PM

To: SCAP Security Guide Subject: Re: Shared Checks/Fixes ...

Hey Trey, IMO rather than read all files from Dir A and then reading all files from Dir B and then processing which content to filter, it would be better to list the content from the current working directory (CWD), check if the file is valid, a symlink (just in case there is need for one), or missing. If the file is a symlink or missing, get the actual file from the shared/oval directory. The logic would seem easier to implement that way. Gabe

On Thu, Apr 9, 2015 at 10:27 AM, Trey Henefield <trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com> wrote: Hi Gabe,

I probably should have been more specific as to the Makefile change, but essentially, it just involved changing the combinechecks.py line from this:

$(SHARED)/$(TRANS)/combinechecks.py $(CONF) $(IN)/checks > $(OUT)/unlinked-$(PROD)-oval.xml

To this:

$(SHARED)/$(TRANS)/combinechecks.py $(CONF) $(IN)/checks $(SHARED)/oval > $(OUT)/unlinked-$(PROD)-oval.xml

That part seems to work great with the code I provided. But the filtering of shared checks included is where the challenge lies.

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@ultra-ats.commailto:Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647tel:%2B1%20512%20327%206795%20ext.%20647 Fax: +1 512 327 8043tel:%2B1%20512%20327%208043 Mobile: +1 512 541 6450tel:%2B1%20512%20541%206450

www.ultra-ats.comhttp://www.ultra-ats.com

From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Gabe Alford Sent: Thursday, April 09, 2015 9:59 AM

To: SCAP Security Guide Subject: Re: Shared Checks/Fixes ...

On Thu, Apr 9, 2015 at 8:04 AM, Trey Henefield <trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com> wrote:

Thank you everyone for the responses!

I completely agree with the benefits of the shared directory. That really wasn't so much my concern, but rather a better way of utilizing it.

As Jan pointed out, I am using a mixed Windows/Linux environment, making it challenging to maintain the symbolic links when traversing different filesystems (NTFS -> EXT).

So far, I have looked at some minor adjustments that can be made to shared/transforms/combinechecks.py and shared/transforms/combinefixes.py.

I have tried adding an additional parameter through the Makefile to point to the $(SHARED)/oval folder and adding the following to shared/transforms/combinechecks.py:

for filename in os.listdir(sys.argv[2]): if filename.endswith(".xml"): with open(sys.argv[2] + "/" + filename, 'r') as xml_file: body = body + xml_file.read() + + for filename in os.listdir(sys.argv[3]): + if filename.endswith(".xml"): + with open(sys.argv[3] + "/" + filename, 'r') as xml_file: + body = body + xml_file.read()

You could do it this way for combinechecks.py: + SHARED = os.environ.get('SHARED_DIR')

for filename in os.listdir(sys.argv[2]): if filename.endswith(".xml"): + local_path = sys.argv[2] + "/" + filename + if not os.path.islink(local_path): + xml_filename = local_path + else: + xml_filename = SHARED + "/oval/" + filename - with open(sys.argv[2] + "/" + filename, 'r') as xml_file: + with open(xml_filename, 'r') as xml_file:

Then add the following to the Makefile(s): export SHARED_DIR=$(SHARED)

This has the proper effect of adding all project-specific checks first, then adding in all shared checks. If there is a shared check with the same name as a project-specific check, the shared check will be excluded in favor of the project-specific check. Although, I personally think the identifier of each shared check should be prefaced with 'shared_' to help identify it as a shared check. This could help to prevent duplicate IDs in any case.

The downside of the above code though is that it adds all oval checks in the shared folder to the oval output of a specific project. It builds fine. But 'make validate' complains about oval checks not being included in the XCCDF profile. There should be a better way to filter xml file content added from the shared folder to just those specific to the project's supported platform.

As Shawn has hinted, this could perhaps be resolved in some XSLT magic. Are there any XSLT magicians out there? ;) This is a language I have yet to conquer.

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@ultra-ats.commailto:Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647tel:%2B1%20512%20327%206795%20ext.%20647 Fax: +1 512 327 8043tel:%2B1%20512%20327%208043 Mobile: +1 512 541 6450tel:%2B1%20512%20541%206450

www.ultra-ats.comhttp://www.ultra-ats.com

-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Jan Lieskovsky Sent: Thursday, April 09, 2015 7:31 AM To: SCAP Security Guide Subject: Re: Shared Checks/Fixes ... Hello Trey,

----- Original Message -----

From: "Trey Henefield" <trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com> To: "scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org" <scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@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@ultra-ats.commailto:Trey.Henefield@ultra-ats.com

Tel: +1 512 327 6795 ext. 647tel:%2B1%20512%20327%206795%20ext.%20647

Fax: +1 512 327 8043tel:%2B1%20512%20327%208043

Mobile: +1 512 541 6450tel:%2B1%20512%20541%206450

www.ultra-ats.comhttp://www.ultra-ats.com

Disclaimer The information contained in this communication from trey.henefield@ultra-ats.commailto:trey.henefield@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@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@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@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/

-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/

Disclaimer The information contained in this communication from trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com sent at 2015-04-09 10:04:14 is private and may be legally privileged or export controlled. It is intended solely for use by scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@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@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/

-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/

-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/

Hi Jan,

Thanks for your contribution!

I do most of my building on RHEL6, so building wasn't that big of a concern for me. Although, the code currently doesn't build on RHEL5, due to some python methods not being supported in the python version available on RHEL5. But I currently don't use Windows for any building. I use it more or less for producing and editing XML/Shell content. We also use our own internal repository for code changes and checkins/checkouts become a little annoying when the symbolic links don’t carry over and have to be reproduced to build properly each time.

Did you have a look at the commits I made on this issue?

https://github.com/OpenSCAP/scap-security-guide/commit/865a88f7cbac07560a8c8...

The above commit removes all dependencies for links for both checks and remediations.

The only thing left is to activate the change for each project using shared content. I have gotten a bit side tracked recently with other work and didn't have time to commit to that yet.

The activation is simply adding parameters to the combinechecks.py and combinefixes.py commands within the makefile of a project.

For example, in the Fedora project makefile, change the following two lines:

$(SHARED)/$(TRANS)/combinefixes.py $(IN)/fixes/bash/ $(OUT)/bash-remediations.xml

$(SHARED)/$(TRANS)/combinechecks.py $(CONF) $(IN)/checks > $(OUT)/unlinked-$(PROD)-oval.xml

To state the following:

$(SHARED)/$(TRANS)/combinefixes.py $(IN)/fixes/bash/ $(OUT)/bash-remediations.xml $(SHARED)/fixes/bash/

$(SHARED)/$(TRANS)/combinechecks.py $(CONF) $(IN)/checks $(SHARED)/oval 'multi_platform_fedora' 'Fedora 19' > $(OUT)/unlinked-$(PROD)-oval.xml

When the above change is done, it no longer relies on the symbolic links for checks and fixes of that project. However doing so seemed to uncover some other content issues that need to be addressed, before actually commiting. Just haven't had the time.

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@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450

www.ultra-ats.com

-----Original Message----- From: Jan Lieskovsky [mailto:jlieskov@redhat.com] Sent: Friday, May 22, 2015 9:06 AM To: Trey Henefield Cc: SCAP Security Guide Subject: Re: Shared Checks/Fixes ...

Hello Trey,

this change wrt to OVAL checks and RHEL/6, RHEL/7, and Fedora/ products have been implemented now (see my reply in the other thread. The corresponding change for remediations to come yet).

But wanted to double-check yet another point - would the decommission / replacement of symbolic links mechanism sufficient for your developer environment, or would also other changes be desired? To speak more exactly, the current Makefiles use more tools (like xmllint, xmlwf), which might be Unix specific (not available natively on other platforms).

Can you clarify which tools are you utilizing when developing SSG content on Microsoft Windows systems? Are the tools like MinGW and / or Cygwin required to be able to develop SSG content on Microsoft Windows?

Asking just to know if we should amend the Makefiles code to be platform aware - IOW it to start using solely only tools / commands available on that platform natively without the need to install additional ones.

If there would be further interest for this (hopefully) sometime in the future we could explore what could be done to make the developer's life on other platforms easier too.

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

----- Original Message -----

From: "Trey Henefield" trey.henefield@ultra-ats.com To: "scap-security-guide@lists.fedorahosted.org" scap-security-guide@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.

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.

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.

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.

Any thoughts?

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@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@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@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/

Disclaimer The information contained in this communication from trey.henefield@ultra-ats.com sent at 2015-05-27 09:40:10 is confidential and may be legally privileged. It is intended solely for use by scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@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.