4:09 p.m.
This is a pretty newbie question on modifying the checks within SCAP. The
rule:
<Rule id="jboss_eap_vendor_supported" severity="high">
...
<oval id="jboss_eap_vendor_supported" value="var_jboss_profile"
/>
<ref srg="SRG-APP-000456-AS-000266" disa="2605" nist=""
stigid="JBOS-AS-000680"/>
</Rule>
checks if a "version.txt" file exists with a version matching a supported
release of Red Hat JBoss Enterprise Application Platform. This can be
found at scap-security-guide/jboss_eap6/xccdf/application/eap6.xml
I read the DISA STIG requirement to talk to use of unsupported community
JBoss releases such as JBoss AS and WildFly. Use of JBoss community
software would be a CAT I finding in the STIG. I created a bash script at
the following location to correctly find and identify JBoss community
releases:
https://github.com/RedHatGov/ansible-scan-jboss/blob/master/scan-communit...
This has been tested against 110 community JBoss AS/WildFly releases and 87
enterprise releases. The repository
https://github.com/RedHatGov/ansible-scan-jboss contains the script and a
test harness. A comprehensive dataset to test against is available at:
https://people.redhat.com/rlucente/test-distros.zip
The script looks for marker files that must be present in order to run the
community application server and then examines metadata within those files
to correctly identify them.
QUESTION: How can I incorporate this into the existing SCAP checks? I'm
finding the XML schemas a bit daunting to understand and I would also need
to use the script check engine for this.
I'll keep looking at the developer's guide on the website to sort this out
but if anyone is willing to collaborate, I'd greatly appreciate it.
Rich Lucente
Principal Solution Architect
Red Hat Public Sector
<https://www.redhat.com>
rlucente(a)redhat.com M: 240-994-0562
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
4:58 p.m.
On 2/19/18 5:09 PM, Rich Lucente wrote:
This is a pretty newbie question on modifying the checks within
SCAP.
The rule:
<Rule id="jboss_eap_vendor_supported" severity="high">
...
<oval id="jboss_eap_vendor_supported" value="var_jboss_profile"
/>
<ref srg="SRG-APP-000456-AS-000266" disa="2605" nist=""
stigid="JBOS-AS-000680"/>
</Rule>
checks if a "version.txt" file exists with a version matching a
supported release of Red Hat JBoss Enterprise Application Platform.
This can be found at
scap-security-guide/jboss_eap6/xccdf/application/eap6.xml
I read the DISA STIG requirement to talk to use of unsupported
community JBoss releases such as JBoss AS and WildFly. Use of JBoss
community software would be a CAT I finding in the STIG. I created a
bash script at the following location to correctly find and identify
JBoss community releases:
https://github.com/RedHatGov/ansible-scan-jboss/blob/master/scan-communit...
This has been tested against 110 community JBoss AS/WildFly releases
and 87 enterprise releases. The repository
https://github.com/RedHatGov/ansible-scan-jboss contains the script
and a test harness. A comprehensive dataset to test against is
available at:
https://people.redhat.com/rlucente/test-distros.zip
The script looks for marker files that must be present in order to run
the community application server and then examines metadata within
those files to correctly identify them.
QUESTION: How can I incorporate this into the existing SCAP checks?
I'm finding the XML schemas a bit daunting to understand and I would
also need to use the script check engine for this.
I'll keep looking at the developer's guide on the website to sort this
out but if anyone is willing to collaborate, I'd greatly appreciate it.
The current check:
- First evaluates the JBOSS_HOME environmental variable, looks for
version.txt in that filepath, and runs a regex to ensure the Enterprise
version is installed
- Failing to find JBOSS_HOME, it looks in /etc/eap/version.txt (which is
where the JBoss Product Managers told us JBoss is installed for VMs and
container images, IIRC)
Before going into the code to much, is that approach appropriate?
By contrast, it looks like your script unzips jar files and looks in
META-INF/maven/org.jboss.modules/jboss-modules/pom.properties. I don't
have enough JBoss knowledge to know if these approaches are effectively
the same, or if one is more ideal. Can you help us understand?
5:49 p.m.
On Thu, Feb 22, 2018 at 5:58 PM, Shawn Wells <shawn(a)redhat.com> wrote:
The current check:
- First evaluates the JBOSS_HOME environmental variable, looks for
version.txt in that filepath, and runs a regex to ensure the Enterprise
version is installed
- Failing to find JBOSS_HOME, it looks in /etc/eap/version.txt (which is
where the JBoss Product Managers told us JBoss is installed for VMs and
container images, IIRC)
Before going into the code to much, is that approach appropriate?
By contrast, it looks like your script unzips jar files and looks in
META-INF/maven/org.jboss.modules/jboss-modules/pom.properties. I don't
have enough JBoss knowledge to know if these approaches are effectively the
same, or if one is more ideal. Can you help us understand?
Sure. I've run across situations where users have deleted the version.txt
file, renamed directories, and generally wreak havoc on what version is
being run. Generally, no assumptions can be made on where files are
located, whether there's a version.txt file, or what directories are named.
My goal was to have a methodology that identifies what's installed
regardless of where files were placed. Older versions of JBossAS have a
run.jar file and newer versions use a jboss-modules.jar file, where both of
those files *MUST* be present in order for JBoss AS to run. The script I
created searches for those specific files and then examines the metadata
within to determine if it's an enterprise or community release. I've
tested this against 110 community releases of JBossAS/WildFly and 87
releases of EAP with community being correctly identified and enterprise
releases being ignored. JBossAS/WildFly/EAP follow consistent nomenclature
in the metadata that makes all this possible.
It's important to note that this can only detect whether JBoss community is
on the filesystem, not that it's actually being run or used.
2262
days inactive
2265
days old
scap-security-guide@lists.fedorahosted.org
2 comments
2 participants
participants (2)
-
Rich Lucente -
Shawn Wells