[Open-scap] OpenSCAP 1.2.8

[Jan Cerny]

Hello OpenSCAPers,

We are thrilled to announce general availability of OpenSCAP 1.2.8 release.

This is the latest release from maint-1.2 maintenance branch. API/ABI is
fully compatible with 1.2.0 release. Users of 1.2.x releases are
recommended to update.

Changes:
  - Maintenance
- textfilecontent54_probe does not produce false positives on non-UTF files 
(rhbz #1285757)
- fixed oscap-docker
- small improvements in verbose mode
- oscap info module shows information about tailoring files
- fixed build with CCE (issue #264)
- fixed XCCDF score computation (issue #272)
- fixed segmentation fault in variable probe (issue #277)
- fixed broken support for OVAL directives
- fixed bash completion
- plugged memory leaks
- fixed fresh static analysis (coverity) findings
- fixed shellcheck warnings
- new tests
- refactoring in datastream module
- many small bugfixes and typo fixes

Special thanks to our new contributor Michaël Zaoui.

Download:
https://fedorahosted.org/releases/o/p/openscap/openscap-1.2.8.tar.gz

SHA512:
80ad17f26d97fb6c88c638b101fee291c16519daf9ed1e6aa62a21852422cd36dac9d0f0cd4a95696976aa2613147b1f4318b355d8bc3dad83d8d8bcc0b91c6d

Audit, Fix, And Be Merry!

-- 
Jan Černý
Security Technologies, Red Hat, Inc.
on behalf of OpenSCAP contributors

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

[Open-scap] Scanning containers using SPC

[Jan Cerny]

Hello,

I have written a short article about scanning containers for vulnerabilities
on Fedora Atomic host using a super privileged container (SPC).
See
http://www.jan-cerny.cz/2016/02/18/scanning-containers-for-vulnerabilities/

Best regards

Jan Černý
Security Technologies | Red Hat, Inc.


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Scanning containers using SPC

[Jan Cerny]

Hi,
thank you.
I believe it is possible to have SPC based on RHEL7.
However there is no such image available to download now.
Zbyněk Moravec is working on some Dockerfiles in
https://github.com/OpenSCAP/openscap-daemon/pull/63

Best regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Martin Preisler" 
> To: "Jan Cerny" 
> Cc: open-scap-list@redhat.com
> Sent: Thursday, February 18, 2016 4:51:16 PM
> Subject: Re: [Open-scap] Scanning containers using SPC
> 
> ----- Original Message -
> > From: "Jan Cerny" 
> > To: open-scap-list@redhat.com
> > Sent: Thursday, February 18, 2016 5:44:13 AM
> > Subject: [Open-scap] Scanning containers using SPC
> > 
> > Hello,
> > 
> > I have written a short article about scanning containers for
> > vulnerabilities
> > on Fedora Atomic host using a super privileged container (SPC).
> > See
> > http://www.jan-cerny.cz/2016/02/18/scanning-containers-for-vulnerabilities/
> 
> Hi,
> great article! Can the same thing be done with RHEL7 as the base OS in the
> SPC?
> 
> --
> Martin Preisler
> Security Technologies | Red Hat, Inc.
> 

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Compile issues on RHEL5+SLES11

[Jan Cerny]

Hello,

The problem is that function pthread_setname_np is not available
in older versions of glibc.
We can use autoconf to solve this issue.
We can add a check to the configure.ac - something like:
AC_CHECK_FUNCS(pthread_setname_np)
And then, in debug.c, use conditional compiling:
#ifdef HAVE_PTHREAD_SETNAME_NP

#else

#endif

I will try to fix this and I will propose a pull request with a patch.

Best regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Martin Preisler" 
> To: "Andreas Krause" 
> Cc: open-scap-list@redhat.com, "Jan Cerny" 
> Sent: Tuesday, March 1, 2016 5:42:20 PM
> Subject: Re: [Open-scap] Compile issues on RHEL5+SLES11
> 
> - Original Message -
> > From: "Andreas Krause" 
> > To: open-scap-list@redhat.com
> > Sent: Tuesday, March 1, 2016 9:59:03 AM
> > Subject: [Open-scap] Compile issues on RHEL5+SLES11
> > 
> > Hi there,
> > 
> > I'm running into difficulties when compiling openscap-1.2.8 on older
> > Linux distributions like RHEL5 or SLES11.
> > 
> > First issue:
> > 
> > /bin/sh ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
> > -I../..  -I/usr/include/libxml2 -DOSCAP_THREAD_SAFE -D_REENTRANT
> > -D_POSIX_PTHREAD_SEMANTICS -I./public -I../../src -I../../src/common
> > -I../../src/common/public -I../../src/source/public -I./adt -I./probes
> > -I./probes/public -I./probes/SEAP/public
> > -I../../src/OVAL/probes/SEAP/generic -I../../src/XCCDF_POLICY/public
> > -I../../src/XCCDF/public -I../../src/CPE/public -DSEAP_MSGID_BITS=32
> > -DSEAP_THREAD_SAFE -DOVAL_PROBE_DIR='"/usr/libexec/openscap"'   -O2 -g
> > -m64 -mtune=generic -pipe -std=c99 -W -Wall -Wnonnull -Wshadow -Wformat
> > -Wundef -Wno-unused-parameter -Wmissing-prototypes -Wno-unknown-pragmas
> > -D_GNU_SOURCE -DOSCAP_THREAD_SAFE -D_POSIX_C_SOURCE=200112L
> > -Wno-unused-function -MT oval_session.lo -MD -MP -MF
> > .deps/oval_session.Tpo -c -o oval_session.lo oval_session.c
> > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../..
> > -I/usr/include/libxml2 -DOSCAP_THREAD_SAFE -D_REENTRANT
> > -D_POSIX_PTHREAD_SEMANTICS -I./public -I../../src -I../../src/common
> > -I../../src/common/public -I../../src/source/public -I./adt -I./probes
> > -I./probes/public -I./probes/SEAP/public
> > -I../../src/OVAL/probes/SEAP/generic -I../../src/XCCDF_POLICY/public
> > -I../../src/XCCDF/public -I../../src/CPE/public -DSEAP_MSGID_BITS=32
> > -DSEAP_THREAD_SAFE -DOVAL_PROBE_DIR=\"/usr/libexec/openscap\" -O2 -g
> > -m64 -mtune=generic -pipe -std=c99 -W -Wall -Wnonnull -Wshadow -Wformat
> > -Wundef -Wno-unused-parameter -Wmissing-prototypes -Wno-unknown-pragmas
> > -D_GNU_SOURCE -DOSCAP_THREAD_SAFE -D_POSIX_C_SOURCE=200112L
> > -Wno-unused-function -MT oval_session.lo -MD -MP -MF
> > .deps/oval_session.Tpo -c oval_session.c  -fPIC -DPIC -o
> > .libs/oval_session.o
> > oval_session.c: In function 'oval_session_export':
> > oval_session.c:422: error: 'PATH_MAX' undeclared (first use in this
> > function)
> > oval_session.c:422: error: (Each undeclared identifier is reported only
> > once
> > oval_session.c:422: error: for each function it appears in.)
> > oval_session.c:422: warning: unused variable 'pwd'
> > make[4]: *** [oval_session.lo] Error 1
> > make[4]: Leaving directory `/usr/src/redhat/BUILD/openscap-1.2.8/src/OVAL'
> > make[3]: *** [all-recursive] Error 1
> > make[3]: Leaving directory `/usr/src/redhat/BUILD/openscap-1.2.8/src/OVAL'
> > make[2]: *** [all-recursive] Error 1
> > make[2]: Leaving directory `/usr/src/redhat/BUILD/openscap-1.2.8/src'
> > make[1]: *** [all-recursive] Error 1
> > make[1]: Leaving directory `/usr/src/redhat/BUILD/openscap-1.2.8'
> > make: *** [all] Error 2
> > 
> > 
> > I've managed to fix this by adding "#include " to
> > src/OVAL/oval_session.c
> > 
> > 
> > Second issue:
> > /bin/sh ../../../libtool  --tag=CC   --mode=link gcc  -O2 -g -m64
> > -mtune=generic -pipe -std=c99 -W -Wall -Wnonnull -Wshadow -Wformat
> > -Wundef -Wno-unused-parameter -Wmissing-prototypes -Wno-unknown-pragmas
> > -D_GNU_SOURCE -DOSCAP_THREAD_SAFE -D_POSIX_C_SOURCE=200112L
> > -Wno-unused-function -I/usr/include/libxml2   -DOSCAP_THREAD_SAFE
> > -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DTHREAD_SAFE -DSEAP_THREAD_SAFE
> > -I../../../src -I../../../src/common -I../../../src/common/public
> > -I../../../src/source/public -I../../../src/OVAL
> > -I../../../src/OVAL/public -I../../../src/OV

Re: [Open-scap] Further compilation issues on SLES11.

[Jan Cerny]

Hello Gautam,

Thank you very much for reporting those issues.
I am working on fixing them (at least some of them).
A fix for pthread_* functions is proposed in pull request
https://github.com/OpenSCAP/openscap/pull/337

Regarding your question, the header files are dependent on versions
of libraries in your system and should not be changed manually.
I think it would be very hard to backport the newer versions from newer systems.
The way for you is to fix the OpenSCAP code.

Best regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "S, Gautam" 
> To: open-scap-list@redhat.com
> Sent: Friday, March 4, 2016 9:44:23 AM
> Subject: [Open-scap] Further compilation issues on SLES11.
> 
> 
> 
> Hello folks,
> 
> 
> 
> I have been following the mail chain “Compile issues on RHEL5+SLES11” and I
> see a few more issues further down the compile and install process.
> 
> 
> 
> 1) Added “linux/limits.h” to src/OVAL/oval_session.c as suggested by Andreas
> Krause.
> 
> 
> 
> 2) The missing pthread API “pthread_setname_np” is used in a few other places
> apart from debug.c. Modules in src/OVAL/probes/SEAP/seap.c,
> src/OVAL/probes/probe/icache.c, input_handler.c, signal_handler.c and
> worker.c also use this API.
> 
> 
> 
> 3) The module src/OVAL/probes/unix/linux/rpmverifypackage.c uses
> ARGV_const_t. There is no definition for this in any of the header files
> present in SLES 11 SP3. On RHEL6, I see a definition in argv.h:
> 
> 
> 
> $grep ARGV_const_t /usr/include/rpm/argv.h
> 
> typedef char * const *ARGV_const_t;
> 
> 
> 
> 4) The module src/OVAL/probes/unix/linux/rpmverifyfile uses symbols
> RPMVERIFY_FILEDIGEST, VERIFY_FILEDIGEST and VERIFY_CAPS which are not
> present SLES 11 SP3. On RHEL6, the definitions are provided by
> /usr/include/rpm/rpmvf.h. I updated the /usr/include/rpm/rpmcli.h file since
> it seemed to be the right place to add these definitions.
> 
> 
> 
> I am new to Linux and building on Linux. I apologize upfront is what I am
> asking is trivial. Is there a way from me to update my system’s
> “/usr/include…” directories with the expected versions of the code?
> 
> 
> 
> Thank you.
> 
> 
> 
> Regards,
> 
> Gautam.
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Assessing multiple machines in parallel and combining assessment reports

[Jan Cerny]

Hi,

Oscap-ssh can't scan in parallel. It is only a simple script.
Scanning multiple machines in parallel can be done using Red Hat Satellite.
It will give you also overview of results for all machines.
See http://www.open-scap.org/tools/systems-management/

Best regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Pravin Goyal" 
> To: open-scap-list@redhat.com
> Sent: Wednesday, March 16, 2016 7:54:24 AM
> Subject: [Open-scap] Assessing multiple machines in parallel and combining 
> assessment reports
> 
> 
> 
> Hi,
> 
> Is there a way I can assess multiple machines in parallel using oscap-ssh and
> then combining the assessment results as one HTML report?
> 
> 
> 
> 
> Thanks and regards,
> 
> Pravin Goyal
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Run-level probes on SUSE

[Jan Cerny]

Hello,

This sounds good to me. We are looking forward to your patches.

Best regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "S, Gautam" 
> To: open-scap-list@redhat.com
> Sent: Friday, March 18, 2016 6:52:54 PM
> Subject: [Open-scap] Run-level probes on SUSE
> 
> 
> 
> Hello,
> 
> 
> 
> This is an investigation into an issue I had reported under title “Make check
> errors on SUSE”. Šimon Lukašík has suggested that openscap would be
> interested in accepting a patch for this problem.
> 
> 
> 
> The run-level probe tests on SUSE were failing as the OVAL definition
> evaluation returns error. A quick check into the code shows that the probe
> is not implemented for SUSE platform.
> https://github.com/OpenSCAP/openscap/blob/maint-1.2/src/OVAL/probes/unix/runlevel.c#L237
> 
> 
> 
> static int get_runlevel_suse (struct runlevel_req *req, struct runlevel_rep
> **rep)
> 
> {
> 
> return (-1);
> 
> }
> 
> 
> 
> From what I understand, the way init works on SUSE is slightly different from
> the sysV init model used on RHEL. On RHEL, the probe checks and finds a
> symbolic link of the init.d/ script in the rc<>.d/ directory. Based
> on whether that file starts with a ‘K’ or an ‘S’, the service state for that
> run level is determined as either disabled or enabled. Because of the
> optimizations in SUSE, on run-levels where the service is disabled, there
> won’t be a symbolic link to the init.d/ script and on run-levels
> where the service is enabled, both K and S script will be found. I do not
> know if this is a foolproof logic to determine the service states on SUSE
> but it does seem to work both with the tests in make check as well as other
> independent service based definitions. There is still a minor issue in the
> test case itself in the get_services_list() module but this has nothing to
> do with oscap, all valid service level definitions get evaluated correctly.
> 
> 
> 
> I can send the code for review if this looks alright.
> 
> 
> 
> Thank you.
> 
> 
> 
> Regards,
> 
> Gautam.
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Run-level probes on SUSE

[Jan Cerny]

Hi,

I would use the code from get_runlevel_sysv(),
re-factor the common parts to avoid repeating code
and implement only the SUSE-specific final check.

I wouldn't use chkconfig, because RHEL part doesn't use it
so I would like to avoid a platform specific solution if
it isn't really necessary.

Best Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "S, Gautam" 
> To: "Jan Cerny" 
> Cc: open-scap-list@redhat.com
> Sent: Tuesday, March 22, 2016 5:40:00 AM
> Subject: RE: [Open-scap] Run-level probes on SUSE
> 
> Hello Jan,
> 
> I had a query regarding the implementation of the probe. Currently I am
> reusing the code from the function "get_runlevel_sysv()" because apart from
> the final check, the rest of it remains the same on SUSE currently. Is this
> the right way to go about it? Or should I use something like say the
> chkconfig utility within the probe on SUSE so that the result is reliable
> even if the run-level implementation is changed later?
> 
> Thank you.
> 
> Regards,
> Gautam.
> -Original Message-
> From: Jan Cerny [mailto:jce...@redhat.com]
> Sent: Monday, March 21, 2016 1:40 PM
> To: S, Gautam 
> Cc: open-scap-list@redhat.com
> Subject: Re: [Open-scap] Run-level probes on SUSE
> 
> Hello,
> 
> This sounds good to me. We are looking forward to your patches.
> 
> Best regards
> 
> Jan Černý
> Security Technologies | Red Hat, Inc.
> 
> - Original Message -
> > From: "S, Gautam" 
> > To: open-scap-list@redhat.com
> > Sent: Friday, March 18, 2016 6:52:54 PM
> > Subject: [Open-scap] Run-level probes on SUSE
> > 
> > 
> > 
> > Hello,
> > 
> > 
> > 
> > This is an investigation into an issue I had reported under title
> > “Make check errors on SUSE”. Šimon Lukašík has suggested that openscap
> > would be interested in accepting a patch for this problem.
> > 
> > 
> > 
> > The run-level probe tests on SUSE were failing as the OVAL definition
> > evaluation returns error. A quick check into the code shows that the
> > probe is not implemented for SUSE platform.
> > https://github.com/OpenSCAP/openscap/blob/maint-1.2/src/OVAL/probes/un
> > ix/runlevel.c#L237
> > 
> > 
> > 
> > static int get_runlevel_suse (struct runlevel_req *req, struct
> > runlevel_rep
> > **rep)
> > 
> > {
> > 
> > return (-1);
> > 
> > }
> > 
> > 
> > 
> > From what I understand, the way init works on SUSE is slightly
> > different from the sysV init model used on RHEL. On RHEL, the probe
> > checks and finds a symbolic link of the init.d/ script in the
> > rc<>.d/ directory. Based on whether that file starts with a ‘K’ or an
> > ‘S’, the service state for that run level is determined as either
> > disabled or enabled. Because of the optimizations in SUSE, on
> > run-levels where the service is disabled, there won’t be a symbolic
> > link to the init.d/ script and on run-levels where the
> > service is enabled, both K and S script will be found. I do not know
> > if this is a foolproof logic to determine the service states on SUSE
> > but it does seem to work both with the tests in make check as well as
> > other independent service based definitions. There is still a minor
> > issue in the test case itself in the get_services_list() module but this
> > has nothing to do with oscap, all valid service level definitions get
> > evaluated correctly.
> > 
> > 
> > 
> > I can send the code for review if this looks alright.
> > 
> > 
> > 
> > Thank you.
> > 
> > 
> > 
> > Regards,
> > 
> > Gautam.
> > 
> > ___
> > Open-scap-list mailing list
> > Open-scap-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/open-scap-list
> 

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] OVAL rule evaluation order

[Jan Cerny]

Hello Pravin,

OpenSCAP doesn't have any option to influence the order of evaluation.

OVAL is a declarative language. Rule evaluation order should not affect results.
OVAL definitions have to be written in a way that it doesn't matter in which 
order
are they evaluated.

Moreover, OVAL definitions can be extended by other definitions usig extend_def 
element,
so OpenSCAP can actually evaluate more other definitions to get a result of 
single definition.


Best Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Pravin Goyal" 
> To: open-scap-list@redhat.com
> Sent: Tuesday, April 5, 2016 6:37:54 AM
> Subject: [Open-scap] OVAL rule evaluation order
> 
> 
> 
> Hi All,
> 
> How does OpenSCAP determine rule evaluation order?
> 
> 
> 
> 
> I have an OVAL file that contains two rules def:1 and def:2. No matter which
> one I place first, def:2 is evaluated first. Is there a way we can make it
> evaluate rules in the particular order - basically starting from def:1.
> 
> 
> 
> 
> Scenario 1:
> 
> 
> 
> 
> ...
> 
> Definitions
> 
> def:2
> 
> 
> def:1
> 
> 
> Tests
> 
> tst:2
> 
> 
> tst:1
> 
> 
> Objects
> 
> obj:2
> 
> 
> obj:1
> 
> 
> States
> 
> ste:2
> 
> 
> ste:1
> 
> 
> 
> 
> 
> 
> 
> Scenario 2:
> 
> 
> 
> 
> ...
> 
> Definitions
> 
> def:1
> 
> 
> def:2
> 
> 
> Tests
> 
> tst:1
> 
> 
> tst:2
> 
> 
> Objects
> 
> obj:1
> 
> 
> obj:2
> 
> 
> States
> 
> ste:1
> 
> 
> ste:2
> 
> 
> 
> 
> 
> 
> Please let me know.
> 
> 
> 
> 
> Thanks and regards,
> 
> Pravin Goyal
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Error in runlevel_test on oscap 1.2.5

[Jan Cerny]

Hello,

Thanks for checking this with us.
Runlevel probe for SUSE was not implemented in OpenSCAP 1.2.5.
It has been implemented recently in upstream 
https://github.com/OpenSCAP/openscap/pull/369 .
You can try to compile OpenSCAP from current source code from github.

Best Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Pravin Goyal" 
> To: open-scap-list@redhat.com
> Sent: Thursday, April 7, 2016 6:25:48 AM
> Subject: [Open-scap] Error in runlevel_test on oscap 1.2.5
> 
> 
> 
> Hi All,
> 
> Just wanted to check if this is a known issue. I have OpenSCAP 1.2.5 on SLES
> 11 SP3.
> 
> 
> 
> 
> 
>  xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#unix";
> id="oval:vrops-sles113.vmware.com:obj:17"
> version="1"
> comment="SRG-OS-37-GPOS-00015-chkconfig-runlevel-5">
> auditd
> 5
> 
> 
> 
> 
> 
> 
> 
> 
>  xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#unix";
> id="oval:vrops-sles113.vmware.com:ste:2"
> version="1"
> comment="SRG-OS-37-GPOS-00015-chkconfig-runlevel-5">
> true
> false
> 
> 
> It gives the below error:
> 
> get_runlevel failed.
> 
> 
> Any pointers?
> 
> Thanks and regards,
> Pravin Goyal
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Openscap spec file.

[Jan Cerny]

Hi Gautam,

thanks for bringing this up.

It looks to me that the user manual contains outdated information.
The spec files were removed from upstream repository,
because they are different for each operating systems
and we had to maintain them in two places: upstream repository
and downstream repository, which was a boring job.

You can use specfiles shipped in Red Hat Enterprise Linux
or you can also refer to spec file in Fedora packaging system,
for example in this source package:
https://kojipkgs.fedoraproject.org//packages/openscap/1.2.8/1.fc23/src/openscap-1.2.8-1.fc23.src.rpm

I hope this will help you.

Best regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "S, Gautam" 
> To: open-scap-list@redhat.com
> Sent: Thursday, April 7, 2016 10:28:59 AM
> Subject: [Open-scap] Openscap spec file.
> 
> 
> 
> Hi folks,
> 
> 
> 
> I am trying to build an RPM from the successful “make” output. The
> documentation in /docs/manual/manual.adoc says that the spec files are
> dist/rhel6 or dist/rhel5 folders. However I do not see spec files in these
> folders. Is there some way I can build an RPM from my build?
> 
> 
> 
> Thank you!
> 
> 
> 
> Regards,
> 
> Gautam.
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Offline scanning - SCE, probes

[Jan Cerny]

Hi Zbyněk,


- Original Message -
> From: "Zbynek Moravec" 
> To: open-scap-list@redhat.com
> Sent: Wednesday, April 13, 2016 11:47:51 PM
> Subject: [Open-scap] Offline scanning - SCE, probes
> 
> Hi
> 
> We plan to implement offline scan support for SCE scripts. I would like to
> ask
> for our opinion.

Thanks for sharing this with the community!

> 
> We have two? options how to deal with SCE offline scan support
> - 1] pass new root path to script (env variable)
>   - Script will decide how to scan new root, it can use path prefix, chroot..

This approach sounds like delegating the problem to authors of SCE checks 
scripts.
Each script will have to support offline scan in its own way.
But I suspect that somewhere in first line of those scripts chroot will be 
anyway called.

> - 2] oscap will do chroot before execute script
>   - Script don't need to know that it is in different root

I think that we want this second option, because then the SCE scipts
could be simple and universal and everybody will be able to use his old
content to scan his containers and VMs.

> 
> 
> Pros/Cons:
>  1]
>+ easy to implement in oscap
>+ script can use best way to perform offline_scan
>- old SCE scripts are not compatible
>- lot of work to deal with offline scan in every script
>- not easy way to detect offline scan support of script

That seems like breaking the simplicity and purpose of SCE.
One of purposes of SCE is to allow easy transition from old script-based
solutions to SCAP -eg. user takes some big bundle of scripts that he developed
for many years and just references them from XCCDF, and continuously replaces
one by one by OVALs.

> 
>  2]
>+ we can use old SCE scripts, easily write new one
>- potentially execute evil code(grep/... called from script) with root
>rights (but in chroot)
>- offline scan of incompatible architecture will not work (but majority
>use x86_64)
>- complicated way to execute script in new root if FS is read_only and
>script cannot be copied
>   there

I would like to know if there is a way to avoid those security implications.

> 
> Which of these two methods is better? Or do you any have better idea?
>

Does something like a ""fake chroot"" exist?
I mean that binaries will be loaded from outside == from host,
but other files will be accessed as in chroot.

> 
> 
> Similar question I have about probes which support offline scan.
> 
> Simplified phases of rpm probe life.
> 1] begin
> 2] chroot
> 3] init - rpmReadConfigFiles
> 4] collect
> 5] end
> 
> During phase 3, some of dynamic libraries are loaded from new root.
> Question is - when to load libraries?
>- before chroot
>  - We can try to force libraries to load their dynamic parts before
>  chroot,
>   but it require some effort.
> 
>- after chroot
>  - again, we will run container code with root rights in chroot
>

I think it should be done before chroot.
Does anyone have an experience / suggestion how to do that?
Is there any use case when this must be done after chroot?

> 
> Thank you for your opinion!


Best Regards


Jan Černý
Security Technologies | Red Hat, Inc.



> 
> Zbynek Moravec
> OpenSCAP
> 
> 
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
> 

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Offline scanning - SCE, probes

[Jan Cerny]

Hi Iankko,

- Original Message -
> From: "Jan Lieskovsky" 
> To: "Zbynek Moravec" 
> Cc: open-scap-list@redhat.com
> Sent: Friday, April 15, 2016 1:26:09 PM
> Subject: Re: [Open-scap] Offline scanning - SCE, probes
> 
> 
> Hello Zbynek,
> 
> - Original Message -
> > From: "Zbynek Moravec" 
> > To: open-scap-list@redhat.com
> > Sent: Wednesday, April 13, 2016 11:47:51 PM
> > Subject: [Open-scap] Offline scanning - SCE, probes
> > 
> > Hi
> > 
> > We plan to implement offline scan support for SCE scripts. I would like to
> > ask
> > for our opinion.
> > 
> > We have two? options how to deal with SCE offline scan support
> > - 1] pass new root path to script (env variable)
> >   - Script will decide how to scan new root, it can use path prefix,
> >   chroot..
> > - 2] oscap will do chroot before execute script
> >   - Script don't need to know that it is in different root
> > 
> > 
> > Pros/Cons:
> >  1]
> >+ easy to implement in oscap
> >+ script can use best way to perform offline_scan
> >- old SCE scripts are not compatible
> >- lot of work to deal with offline scan in every script
> 
> IMHO the purpose of well-written software should be to hide all
> the underlying complexity from the user. This approach seems
> to contradict to that (be opposite to that).

+1 Indeed.

> 
> >- not easy way to detect offline scan support of script
> > 
> >  2]
> >+ we can use old SCE scripts, easily write new one
> >- potentially execute evil code(grep/... called from script) with root
> >rights (but in chroot)
> 
> If you are worried about possible security implications of such invocation,
> have a look at isolation / resource restriction possibilities. Besides

I think that main woe is about possible "escaping from chroot jail"

> chroot it's possible to use e.g. ptrace / (lib)seccomp to filter system
> calls,
> (lib)cgroup to limit resources used by the script, SELinux rules for proper
> labeling (least privilege)

oscap and probes are now unconfined_t.
If I undestand it well, the child process inherits SELinux context from parent 
process.
Lukáš said yesterday that changing the context from inside the application code
is a nasty hack and that a special SELinux policy should be written for this.


> , separate namespaces for the SCE process.
>
> Shouldn't this all be sufficient, it's even possible to create new LXC
> container
> for each such a SCE script and run it there (but IMHO this would be pretty
> big overload).

> Some recommended reading you might find useful:
> * https://archive.fosdem.org/2015/schedule/event/openconnect_vpn/
> *
> http://openalt.cz/2015/data/Jan%20Lieskovsky%20-%20the_methods_of_sandboxing_and_isolation.pdf
> *
> https://www.berrange.com/posts/2012/01/17/building-application-sandboxes-with-libvirt-lxc-kvm/
> 
> >- offline scan of incompatible architecture will not work (but majority
> >use x86_64)
> 
> Can you be more specific? You mean "cross offline scan" (e.g. x86_64 vs
> s390[x] won't work?)
> 
> >- complicated way to execute script in new root if FS is read_only and
> >script cannot be copied
> >   there
> 
> Might the approach to create own minimal root FS e.g. with busybox
> (https://www.berrange.com/posts/2011/09/27/getting-started-with-lxc-using-libvirt/
> )
> help here?
> 
> > 
> > Which of these two methods is better?
> 
> I like the second one more (since it doesn't bring additional complexity
> to the way users are accustomed to define SCE scripts today).
> 
> > Or do you any have better idea?
> > 
> 
> A way to setup / establish a safe playground for execution of SCE scripts
> seems to be the way. But your second proposal is already proposing it.
> 
> > 
> > 
> > Similar question I have about probes which support offline scan.
> > 
> > Simplified phases of rpm probe life.
> > 1] begin
> > 2] chroot
> > 3] init - rpmReadConfigFiles
> > 4] collect
> > 5] end
> > 
> > During phase 3, some of dynamic libraries are loaded from new root.
> 
> Is the reason for this behaviour the fact the necessary *.so files
> aren't present in original root => thus linker can't load them sooner?
> Or doesn't need to load them yet because they weren't referenced yet?
> Or something else? Are we able to tell?
> 
> > Question is - when to load libraries?
> >- before chroot
> >  - We can try to force libraries to load their dynamic parts before
> >  chroot,
> >   but it require some effort.
> 
> Obviously (IMHO at least) we would want to load them as soon as possible
> (thus yet even before chroot). If that's not possible we should investigate,
> why that's the case.
> 
> > 
> >- after chroot
> >  - again, we will run container code with root rights in chroot
> 
> Maybe here we could again use seccomp to filter out dlopen() system call,
> so it wouldn't actually load anything (but this assumes all symbols are
> loaded before chroot() yet).

I think we have to load all necessary libraries from the host 
and then bl

[Open-scap] OpenSCAP 1.2.9

[Jan Cerny]

Hello OpenSCAPers,

We are thrilled to announce general availability of OpenSCAP 1.2.9 release.

This is the latest release from maint-1.2 maintenance branch. API/ABI is
fully compatible with 1.2.0 release. Users of 1.2.x releases are
recommended to update.

Changes:
  - New features
- oscap-chroot - a tool for offline scanning of filesystems mounted at 
arbitrary paths
- enabled offline scanning in many probes
- support for SCE in data streams
- many improvements of verbose mode
- verbose messages can be written on stderr
- runlevel probe supports SUSE systems
- new upstream tests
  - Maintenance
- a lot of refactoring
- fixes in various tests
- OCILs are correctly placed in datastreams (issue #364)
- oscap-vm can work with fusermount when guestunmount is not available
- fixed oscap-docker HTTP communication issues (issue #304)
- fixed oscap-docker tracebacks (issue #303, #317)
- fixed container mounting in oscap-docker (issue #329)
- added Fedora 25 CPE
- only non-empty profiles are built (rhbz#1256879, rhbz#1302230)
- fixed compiler errors on RHEL5 and SLES11
- fixed sorting of groups in HTML report (issue #342)
- fixed version/@time and version/@update in XCCDF Benchmark
- fixed CPE definitions to work also in offline mode
- fixed sysctl probe (issue #258)
- fixed manual page for oscap-ssh (rhbz#1299969)
- updated user manuals and manual pages
- updated .gitignore

Special thanks to our new contributors Gautam Satish, Marek Haicman,
Mooli Tayer and Quey-Liang Kao.

Download:
https://github.com/OpenSCAP/openscap/releases/download/1.2.9/openscap-1.2.9.tar.gz

SHA512:
1a55b466c3acdea9423bff8d2662ff236b7edcbb88c04de23cb40ff7ba9536847aaed9495ab8b3904b9eac981c8a018d0f253769a848e7ccfd8ecb2aedc99e0f

Audit, Fix, And Be Merry!

-- 
Jan Černý
Security Technologies, Red Hat, Inc.
on behalf of OpenSCAP contributors


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Found a nasty but cool bug in OpenSCAP 1.2.5

[Jan Cerny]

Hi,

thank you very much for reporting this bug. It is really weird issue.

I confirm that this happens also with the latest OpenSCAP 1.2.9.
In my opinion this behavior should not be allowed.

The issue in content was not discovered by standard validation which is 
performed
by OpenSCAP before each scan.
But OpenSCAP offers also extended validation using XSLT-based schematron.
I have tried to run it on your content:

$ oscap oval validate --schematron oval.xml 

oval:test-bug.test.com:tst:205 - the object child element of a sysctl_test must 
reference a sysctl_object

So it seems to me that we should check whether the test is of same type as 
object,
and if not, display at least an error message.

I will file an upstream ticket against OpenSCAP.

Best regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Pravin Goyal" 
> To: open-scap-list@redhat.com
> Sent: Thursday, April 21, 2016 10:42:59 AM
> Subject: [Open-scap] Found a nasty but cool bug in OpenSCAP 1.2.5
> 
> 
> 
> Hi All,
> 
> Found a nasty but cool bug. Tested on OpenSCAP 1.2.5 on SLES 11 SP3.
> 
> 
> 
> 
> Here it is.
> 
> 
> 
> 
> ===
> 
> ===
> 
> 
> 
> 
> 
> 
> http://oval.mitre.org/XMLSchema/oval-definitions-5";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:oval="http://oval.mitre.org/XMLSchema/oval-common-5";
> xmlns:oval-def="http://oval.mitre.org/XMLSchema/oval-definitions-5";
> xmlns:linux-def="http://oval.mitre.org/XMLSchema/oval-definitions-5#linux";
> xmlns:unix-def="http://oval.mitre.org/XMLSchema/oval-definitions-5#unix";
> xmlns:independent-def="http://oval.mitre.org/XMLSchema/oval-definitions-5#independent";
> xsi:schemaLocation="http://oval.mitre.org/XMLSchema/oval-definitions-5
> oval-definitions-schema.xsd http://oval.mitre.org/XMLSchema/oval-common-5
> oval-common-schema.xsd
> http://oval.mitre.org/XMLSchema/oval-definitions-5#independent
> independent-definitions-schema.xsd
> http://oval.mitre.org/XMLSchema/oval-definitions-5#linux
> linux-definitions-schema.xsd
> http://oval.mitre.org/XMLSchema/oval-definitions-5#unix
> unix-definitions-schema.xsd">
> 
> None
> None
> 5.11
> 2016-04-04T01:31:55
> 
> 
> 
> 
>  version="1"
> class="compliance">
> 
> SRG-OS-000458-GPOS-00203 - Audit sudoers file
> 
> cpe:/o:sles11:linux
> 
> This rule verifies that audit entry exists
> /etc/audit/audit.rules file for for /etc/sudoers file.
> 
>  negate="false"
> comment="SRG-OS-000458-GPOS-00203">
>  test_ref="oval:test-bug.test.com:tst:205" />
> 
> 
> 
> 
> 
> 
> 
> 
>  xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#independent";
> id="oval:test-bug.test.com:tst:205"
> version="1"
> check="all"
> comment="SRG-OS-000458-GPOS-00203"
> check_existence="at_least_one_exists">
> 
> 
> 
> 
> 
> 
> 
>  xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#independent";
> id="oval:test-bug.test.com:obj:165"
> version="1"
> comment="SRG-OS-000458-GPOS-00203">
>  operation="equals">/etc/audit/audit.rules
> ^\-w\s+/etc/sudoers\s+\-p\s+wa
> 1
> 
> 
> 
> 
> 
> 
> 
> ===
> 
> ===
> 
> Running the above works perfectly.
> Now, here is the bug. Change the textfilecontent54_test tag with sysctl_test
> without changing anything else (except namespace of course from independent
> to unix).
> 
> So, the new test block should look like below:
> 
> =
> =
> http://oval.mitre.org/XMLSchema/oval-definitions-5#unix";
> id="oval:test-bug.test.com:tst:205"
> version="1"
> check="all"
> comment="SRG-OS-000458-GPOS-00203"
> check_existence="at_least_one_exists">
> 
> 
> 
> =
> =
> 
> This runs as well without any qualms and evaluates both pass and fail
> condition perfectly. So, the bug is that it does not enforce that test and
> object are SAME oval probes. The test could be a sysctl test but object it
> tests could be textfilecontent54. Does OVAL schema allow this? Is this
> known?
> 
> Nevertheless, I like this bug and ok to live with it. It is COOL!
> 
> Thanks and regards,
> Pravin Goyal
> 
> 
> 
> 
> 
> 
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Open-scap-list Digest, Vol 85, Issue 24

[Jan Cerny]

Hello,

I uploaded the tarball there today.

Best regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Pravin Goyal" 
> To: open-scap-list@redhat.com
> Sent: Tuesday, April 26, 2016 12:18:50 AM
> Subject: Re: [Open-scap] Open-scap-list Digest, Vol 85, Issue 24
> 
> When will OpenSCAP 1.2.9 be available here?
> https://fedorahosted.org/releases/o/p/openscap/
> 
> 
> From: open-scap-list-boun...@redhat.com 
> on behalf of open-scap-list-requ...@redhat.com
> 
> Sent: Friday, April 22, 2016 9:31 PM
> To: open-scap-list@redhat.com
> Subject: Open-scap-list Digest, Vol 85, Issue 24
> 
> Send Open-scap-list mailing list submissions to
> open-scap-list@redhat.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.redhat.com/mailman/listinfo/open-scap-list
> or, via email, send a message with subject or body 'help' to
> open-scap-list-requ...@redhat.com
> 
> You can reach the person managing the list at
> open-scap-list-ow...@redhat.com
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Open-scap-list digest..."
> 
> 
> Today's Topics:
> 
>1. oscap-ssh based remediation killing remote server (Fen Labalme)
>2. OpenSCAP 1.2.9 (Jan Cerny)
> 
> 
> --
> 
> Message: 1
> Date: Thu, 21 Apr 2016 18:14:04 -0400
> From: Fen Labalme 
> To: open-scap-list 
> Subject: [Open-scap] oscap-ssh based remediation killing remote server
> Message-ID:
> 
> Content-Type: text/plain; charset="utf-8"
> 
> Hi,
> 
> I'm running oscap-ssh on CentOS 7 using oscap-user and the `sudo` option.
> Running a scan on a remote server works great (thank you!):
> 
> oscap-ssh sudo oscap-user@192.168.56.102 22 xccdf eval --profile
> > xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream
> > --results-arf scans/results-arf.xml --results scans/results.xml --report
> > scans/results.html scap/ssg-centos7-ds.xml
> 
> 
> Then I run a remediation with the line:
> 
> oscap-ssh sudo oscap-user@192.168.56.102 22 xccdf eval --remediate
> > --profile xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream
> > --results scans/remediation-results.xml --fetch-remote-resources
> > scap/ssg-centos7-ds.xml
> 
> 
> This completely kills access to the server at 192.168.56.102 (via host or
> dashboard).
> 
> Am I calling remediation incorrectly? Has anyone else seen anything like
> this? No obvious errors are reported.
> 
> Suggestions on how to debug what step might be killing the server are
> welcome. Note that it doesn't die until the SSJ connection is closed, e.g.
> after:
> 
> Shared connection to 192.168.56.102 closed.
> > oscap exit code: 2
> > Copying back requested files...
> > results.xml   100%
> > 1889KB   1.9MB/s   00:00
> > Removing remote temporary directory...
> > Disconnecting ssh and removing master ssh socket directory...
> > Exit request sent.
> 
> 
> The exact steps I'm using are captured in a completely self-contained
> ansible role test setup (that uses vagrant) documented - shpuld you want to
> recreate my process - at
> https://github.com/openprivacy/ansible-role-govready/blob/master/tests/README.md
> 
> Thanks,
> =Fen
> 
> --
> Fen Labalme, CISO at CivicActions.com
> Security | Quality | DevOps
> mobile: 412-996-4113
> github/skype/twitter: openprivacy
> -- next part --
> An HTML attachment was scrubbed...
> URL:
> <https://www.redhat.com/archives/open-scap-list/attachments/20160421/df8331a3/attachment.html>
> 
> --
> 
> Message: 2
> Date: Fri, 22 Apr 2016 09:31:48 -0400 (EDT)
> From: Jan Cerny 
> To: open-scap-list@redhat.com
> Subject: [Open-scap] OpenSCAP 1.2.9
> Message-ID:
> <580106189.81407851.1461331908677.javamail.zim...@redhat.com>
> Content-Type: text/plain; charset=utf-8
> 
> Hello OpenSCAPers,
> 
> We are thrilled to announce general availability of OpenSCAP 1.2.9 release.
> 
> This is the latest release from maint-1.2 maintenance branch. API/ABI is
> fully compatible with 1.2.0 release. Users of 1.2.x releases are
> recommended to update.
> 
> Changes:
>   - New features
> - oscap-chroot - a tool for offline scanning of filesystems mounted at
> arbitrary paths
> - enabled offline scanning in many probes
> - support for SCE in data

Re: [Open-scap] oscap-ssh based remediation killing remote server

[Jan Cerny]

Hi Fen,

The RHEL7 STIG profile contains some rules that check configuration of
the SSH server. For some of them there are remediation script provided.
There are quite a lot of them:
- Allow Only SSH Protocol 2
- Set SSH Idle Timeout Interval
- Set SSH Client Alive Count
- Disable SSH Support for .rhosts Files
- Disable Host-Based Authentication
- Disable SSH Root Login
- Disable SSH Access via Empty Passwords
- Enable SSH Warning Banner
- Do Not Allow SSH Environment Options
- Use Only Approved Ciphers
- Use Only FIPS Approved MACs
(Hopefully I haven't forgotten any other.)

Maybe you have discovered a bug in some of the remediation scripts
for some of these rules. To identify the problem, we have to check
the scan results and find which rules your system didn't pass.
The we can go trough each of them, find why they didn't pass and compare this
with the remediation scripts. It is possible that your system was in 
configuration
that the remediation scripts does not cover.

Please, could you provide your scan results?
It would greatly help us to investigate your problem.
Have you done any customization of the profile?

If you find any possible reason, please share it with us.
Thank you

Best Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Fen Labalme" 
> To: "open-scap-list" 
> Sent: Friday, April 22, 2016 12:14:04 AM
> Subject: [Open-scap] oscap-ssh based remediation killing remote server
> 
> Hi,
> 
> I'm running oscap-ssh on CentOS 7 using oscap-user and the `sudo` option.
> Running a scan on a remote server works great (thank you!):
> 
> 
> 
> oscap-ssh sudo oscap-user@192.168.56.102 22 xccdf eval --profile
> xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream
> --results-arf scans/results-arf.xml --results scans/results.xml --report
> scans/results.html scap/ssg-centos7-ds.xml
> 
> Then I run a remediation with the line:
> 
> 
> 
> oscap-ssh sudo oscap-user@192.168.56.102 22 xccdf eval --remediate --profile
> xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream --results
> scans/remediation-results.xml --fetch-remote-resources
> scap/ssg-centos7-ds.xml
> 
> This completely kills access to the server at 192.168.56.102 (via host or
> dashboard).
> 
> Am I calling remediation incorrectly? Has anyone else seen anything like
> this? No obvious errors are reported.
> 
> Suggestions on how to debug what step might be killing the server are
> welcome. Note that it doesn't die until the SSJ connection is closed, e.g.
> after:
> 
> 
> 
> Shared connection to 192.168.56.102 closed.
> oscap exit code: 2
> Copying back requested files...
> results.xml 100% 1889KB 1.9MB/s 00:00
> Removing remote temporary directory...
> Disconnecting ssh and removing master ssh socket directory...
> Exit request sent.
> 
> The exact steps I'm using are captured in a completely self-contained ansible
> role test setup (that uses vagrant) documented - shpuld you want to recreate
> my process - at
> https://github.com/openprivacy/ansible-role-govready/blob/master/tests/README.md
> 
> Thanks,
> =Fen
> 
> --
> Fen Labalme, CISO at CivicActions.com
> Security | Quality | DevOps
> mobile: 412-996-4113
> github/skype/twitter: openprivacy
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] openscap does not collect the uuid property

[Jan Cerny]

Hello Dragos,

Is the UUID of your loop device reported by blkid tool?
Or is it missing as well?

Best regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Dragos Prisaca" 
> To: open-scap-list@redhat.com
> Sent: Thursday, May 5, 2016 10:45:56 PM
> Subject: [Open-scap] openscap does not collect the uuid property
> 
> 
> 
> Hello,
> 
> 
> 
> The OpenSCAP 1.2.10 does not collect the uuid property:
> 
> 
> 
> 
>  /mnt/my_loop_device 
>  /dev/loop2 
> 
>  ext3 
>  rw 
>  seclabel 
>  relatime 
>  errors=continue 
>  barrier=1 
>  data=ordered 
>  bind 
>  244385 
>  4407 
>  239978 
> 
> 
> 
> 
> 
> Thanks,
> 
> _Dragos.
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] openscap does not collect the uuid property

[Jan Cerny]

Hi Dragos,

I'm sorry but unfortunately I can't reproduce your issue.
I created a loop device and the UUID is reported correctly for me.
The only case when UUID wasn't collected was when I run oscap
as a normal user, then oscap got data from old libblkid cache.
But when run as root, everything works OK to me.
Do you run oscap as root?
If yes, I would need more information from you (e.g. OVAL definition)
to be able to help you.

Thank you

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Dragos Prisaca" 
> To: "Jan Cerny" 
> Cc: open-scap-list@redhat.com
> Sent: Monday, May 9, 2016 10:42:27 PM
> Subject: RE: [Open-scap] openscap does not collect the uuid property
> 
> Hello Jan,
> 
> The UUID is reported by blkid tool on both RHEL6 and 7:
> # blkid
> ...
> /dev/loop2: UUID="----" TYPE="ext3"
> 
> Thanks,
> _Dragos.
> 
> 
> -Original Message-
> From: Jan Cerny [mailto:jce...@redhat.com]
> Sent: Monday, May 09, 2016 11:42 AM
> To: Dragos Prisaca
> Cc: open-scap-list@redhat.com
> Subject: Re: [Open-scap] openscap does not collect the uuid property
> 
> Hello Dragos,
> 
> Is the UUID of your loop device reported by blkid tool?
> Or is it missing as well?
> 
> Best regards
> 
> Jan Černý
> Security Technologies | Red Hat, Inc.
> 
> - Original Message -
> > From: "Dragos Prisaca" 
> > To: open-scap-list@redhat.com
> > Sent: Thursday, May 5, 2016 10:45:56 PM
> > Subject: [Open-scap] openscap does not collect the uuid property
> >
> >
> >
> > Hello,
> >
> >
> >
> > The OpenSCAP 1.2.10 does not collect the uuid property:
> >
> >
> >
> > 
> >  /mnt/my_loop_device 
> >  /dev/loop2   > "not collected" />  ext3 
> >  rw 
> >  seclabel 
> >  relatime 
> >  errors=continue 
> >  barrier=1 
> >  data=ordered 
> >  bind 
> >  244385 
> >  4407 
> >  239978 
> > 
> >
> >
> >
> >
> > Thanks,
> >
> > _Dragos.
> >
> > ___
> > Open-scap-list mailing list
> > Open-scap-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/open-scap-list
> 

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] process58_object is not supported

[Jan Cerny]

Hi Dragos,

You are missing sys/capability.h header file.
Install libcap-devel package.

I have noticed that you also miss other packages for other probes
(GConf2-devel, openldap-devel)

Build dependencies are listed in:
https://github.com/OpenSCAP/openscap/blob/maint-1.2/README.md

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Dragos Prisaca" 
> To: "Martin Preisler" 
> Cc: open-scap-list@redhat.com
> Sent: Friday, May 13, 2016 3:31:14 AM
> Subject: Re: [Open-scap] process58_object is not supported
> 
> Hello Martin,
> 
> Please find the output from `./configure` attached.
> 
> Thanks,
> _Dragos.
> 
> 
> -Original Message-
> From: Martin Preisler [mailto:mprei...@redhat.com]
> Sent: Thursday, May 12, 2016 3:49 PM
> To: Dragos Prisaca
> Cc: open-scap-list@redhat.com
> Subject: Re: [Open-scap] process58_object is not supported
> 
> - Original Message -
> > From: "Dragos Prisaca" 
> > To: open-scap-list@redhat.com
> > Sent: Thursday, May 12, 2016 3:30:27 PM
> > Subject: [Open-scap] process58_object is not supported
> >
> >
> >
> > Hello,
> >
> >
> >
> > Do you have an ETA when this process58_test will be supported?
> >
> > Currently, I am getting: “  OVAL object
> > not supported  ”
> 
> Hi Dragos,
> 
> process and process58 tests are both fully supported.
> 
> Could you paste your `./configure` output? Maybe some dependencies are
> missing or were not detected properly.
> 
> --
> Martin Preisler
> Identity Management and Platform Security | Red Hat, Inc.
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

[Open-scap] OpenSCAP 1.2.10

[Jan Cerny]

Hello OpenSCAPers,

We are thrilled to announce general availability of OpenSCAP 1.2.10 release.

This is the latest release from maint-1.2 maintenance branch. API/ABI is
fully compatible with 1.2.0 release. Users of 1.2.x releases are
recommended to update.

Changes:
  - New features
- support --benchmark-id when running `oscap xccdf generate guide`
- added CPE support for OpenSUSE 42.1
  - Maintenance
- oscap-docker fixed to be source compatible with both Python 2 and 3
- fixed offline mode in rpmverifypackage probe
- fixed scanning of non-RHEL containers in oscap-docker (issue #427)
- fixed regression in loading a datastream session (RHBZ #1250072)
- fixed missing SCE results in XCCDF reports (issue #394)
- fixed a segmentation fault (issue #370)
- fix error message when OVAL generator element is missing (issue #345)
- fixed failing rpminfo probe
- fixed compilation on RHEL5 (issue #393)
- new tests in upstream test suite
- test suite is able to run on Fedora 24
- fixed remediation scripts appearance in HTML guides (issue #460)
- fixed autoconf build
- small fixes, refactoring, small documentation improvements


Special thanks to our new contributor Jason Newton.

Download:
https://github.com/OpenSCAP/openscap/releases/download/1.2.10/openscap-1.2.10.tar.gz

SHA512:
a74a9bcadacdb78f735d83fe5558748fe9a7524bb30e728d881f4f8757509398a4e60ccd3b991de2a352ab0c275393aa28dfa133d0b21af5fc42912f68f68e4b

Audit, Fix, And Be Merry!

-- 
Jan Černý
Security Technologies, Red Hat, Inc.
on behalf of OpenSCAP contributors

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Informational value

[Jan Cerny]

Hi Rocio,

Yes, the result of an XCCDF check can be "informational".
The XCCDF specification [1] says that:

The  was checked, but the output from the checking engine is simply
information for auditors or administrators; it is not a compliance category. 
This status value is
designed for  elements whose main purpose is to extract information 
from the
target rather than test the target.

>From what I understand, this value is used for rules that are evaluated, but 
>not going to be
counted into the result score (do not affect the score). That happens if you 
have an XCCDF rule
with attribute "role" set to "unscored". 
However I am sorry I haven't found any check in OpenSCAP that is using this.

Regarding your second question, OpenSCAP >= 1.2.2 can display OVAL results
in the HTML report if you run it with "--oval-results", eg.:

# oscap xccdf eval --results results.xml --oval-results --report report.html 
my_benchmark.xml

The HTML report will look like in [2].

[1] http://csrc.nist.gov/publications/nistir/ir7275-rev4/NISTIR-7275r4.pdf 
(page 43)
[2] 
https://www.open-scap.org/wp-content/uploads/2015/09/ssg-rhel7-ds-xccdf.report.html

I hope this helps.

Best regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Rocio Romero" 
> To: open-scap-list@redhat.com
> Sent: Thursday, June 30, 2016 9:50:34 PM
> Subject: [Open-scap] Informational value
> 
> Hi everyone,
> 
> I was taking a look to the possibles values we can get from a check in this
> webpage
> https://sadocs.emc.com/0_en-us/089_105InfCtr/215_SysAdm/ConfigurSTIG/30_OpenSCAPRpt
> .
> 
> I saw that “Informational” is a valid value. Could you please give me an
> example of this?
> 
> Also, I was wondering if there is any way to return some output from a check
> and put this output in the report (a friend ask me about that and I’m not
> sure 100%).
> 
> Thank you so much,
> 
> Rocio
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Informational value

[Jan Cerny]

Hi Rocio,

It should work always when using OVAL definitions.
This looks like a bug. Could you provide details, please?

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Rocio Romero" 
> To: "Jan Cerny" 
> Cc: open-scap-list@redhat.com
> Sent: Friday, July 1, 2016 7:56:08 PM
> Subject: Re: [Open-scap] Informational value
> 
> Hi Jan,
> 
> Thank you so much for your answer! It was really helpful :)
> 
> I have one more question with the -oval-results option…. For some reason, it
> did’t show the details with a benchmark I have. I tried with other personal
> benchmark and that one worked. There is something needed in the xccdf or
> oval file to make it works? I reviewed both and I don’t know what is exactly
> happening :/
> 
> Thank you!
> 
> Rocio
> 
> 
> 
> 
> > On Jul 1, 2016, at 12:38 AM, Jan Cerny  wrote:
> > 
> > Hi Rocio,
> > 
> > Yes, the result of an XCCDF check can be "informational".
> > The XCCDF specification [1] says that:
> > 
> > The  was checked, but the output from the checking engine is
> > simply
> > information for auditors or administrators; it is not a compliance
> > category. This status value is
> > designed for  elements whose main purpose is to extract
> > information from the
> > target rather than test the target.
> > 
> > From what I understand, this value is used for rules that are evaluated,
> > but not going to be
> > counted into the result score (do not affect the score). That happens if
> > you have an XCCDF rule
> > with attribute "role" set to "unscored".
> > However I am sorry I haven't found any check in OpenSCAP that is using
> > this.
> > 
> > Regarding your second question, OpenSCAP >= 1.2.2 can display OVAL results
> > in the HTML report if you run it with "--oval-results", eg.:
> > 
> > # oscap xccdf eval --results results.xml --oval-results --report
> > report.html my_benchmark.xml
> > 
> > The HTML report will look like in [2].
> > 
> > [1] http://csrc.nist.gov/publications/nistir/ir7275-rev4/NISTIR-7275r4.pdf
> > (page 43)
> > [2]
> > https://www.open-scap.org/wp-content/uploads/2015/09/ssg-rhel7-ds-xccdf.report.html
> > 
> > I hope this helps.
> > 
> > Best regards
> > 
> > Jan Černý
> > Security Technologies | Red Hat, Inc.
> > 
> > - Original Message -
> >> From: "Rocio Romero" 
> >> To: open-scap-list@redhat.com
> >> Sent: Thursday, June 30, 2016 9:50:34 PM
> >> Subject: [Open-scap] Informational value
> >> 
> >> Hi everyone,
> >> 
> >> I was taking a look to the possibles values we can get from a check in
> >> this
> >> webpage
> >> https://sadocs.emc.com/0_en-us/089_105InfCtr/215_SysAdm/ConfigurSTIG/30_OpenSCAPRpt
> >> .
> >> 
> >> I saw that “Informational” is a valid value. Could you please give me an
> >> example of this?
> >> 
> >> Also, I was wondering if there is any way to return some output from a
> >> check
> >> and put this output in the report (a friend ask me about that and I’m not
> >> sure 100%).
> >> 
> >> Thank you so much,
> >> 
> >> Rocio
> >> 
> >> ___
> >> Open-scap-list mailing list
> >> Open-scap-list@redhat.com
> >> https://www.redhat.com/mailman/listinfo/open-scap-list
> 
> 

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Systemdunitproperty issue

[Jan Cerny]

Hi Rocio,

The output you provided suggests that the systemd probes didn't compile.

That happens usually when your system is missing some of the required header 
files.
I think it can be dbus.h, located in /usr/include/dbus-1.0/dbus/dbus.h, 
provided by
dbus-devel package. Try to install dbus-devel using "yum install dbus-devel" 
and then run 
"./configure && make && make install" again.

I can see the dbus-devel package is not included in our README in the build 
dependencies list,
I will add it there soon.

You should be able to identify the missing header files in output produced by 
./configure, eg:

 * Checking presence of required headers for the systemdunitproperty probe
 811 checking for dbus/dbus.h... yes
 812 checking for string.h... (cached) yes


Best regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Rocio Romero" 
> To: open-scap-list@redhat.com
> Sent: Friday, July 8, 2016 9:16:24 PM
> Subject: [Open-scap] Systemdunitproperty issue
> 
> Hi everyone,
> 
> I’m still working on a benchmark for Oracle Linux.
> 
> I realized that systemdunitproperty is supported by oscap, but in the oscap
> version I have installed is not. I installed it through
> https://github.com/OpenSCAP/openscap .
> 
> Do I need to do something specific to activate it on my machine? I saw that
> oscap has probes file for it… so it should work in some way.
> 
> For more information:
> 
> OpenSCAP command line tool (oscap) 1.2.10
> Copyright 2009--2016 Red Hat Inc., Durham, North Carolina.
> 
>  Supported specifications 
> XCCDF Version: 1.2
> OVAL Version: 5.11.1
> CPE Version: 2.3
> CVSS Version: 2.0
> CVE Version: 2.0
> Asset Identification Version: 1.1
> Asset Reporting Format Version: 1.1
> 
>  Capabilities added by auto-loaded plugins 
> SCE Version: 1.0 (from libopenscap_sce.so.8)
> 
>  Paths 
> Schema files: /usr/local/share/openscap/schemas
> Default CPE files: /usr/local/share/openscap/cpe
> Probes: /usr/local/libexec/openscap
> 
>  Inbuilt CPE names 
> Red Hat Enterprise Linux - cpe:/o:redhat:enterprise_linux
> Red Hat Enterprise Linux 5 - cpe:/o:redhat:enterprise_linux:5
> Red Hat Enterprise Linux 6 - cpe:/o:redhat:enterprise_linux:6
> Red Hat Enterprise Linux 7 - cpe:/o:redhat:enterprise_linux:7
> Community Enterprise Operating System 5 - cpe:/o:centos:centos:5
> Community Enterprise Operating System 6 - cpe:/o:centos:centos:6
> Community Enterprise Operating System 7 - cpe:/o:centos:centos:7
> Scientific Linux 5 - cpe:/o:scientificlinux:scientificlinux:5
> Scientific Linux 6 - cpe:/o:scientificlinux:scientificlinux:6
> Scientific Linux 7 - cpe:/o:scientificlinux:scientificlinux:7
> Fedora 16 - cpe:/o:fedoraproject:fedora:16
> Fedora 17 - cpe:/o:fedoraproject:fedora:17
> Fedora 18 - cpe:/o:fedoraproject:fedora:18
> Fedora 19 - cpe:/o:fedoraproject:fedora:19
> Fedora 20 - cpe:/o:fedoraproject:fedora:20
> Fedora 21 - cpe:/o:fedoraproject:fedora:21
> Fedora 22 - cpe:/o:fedoraproject:fedora:22
> Fedora 23 - cpe:/o:fedoraproject:fedora:23
> Fedora 24 - cpe:/o:fedoraproject:fedora:24
> Fedora 25 - cpe:/o:fedoraproject:fedora:25
> SUSE Linux Enterprise all versions - cpe:/o:suse:sle
> SUSE Linux Enterprise Server 10 - cpe:/o:suse:sles:10
> SUSE Linux Enterprise Desktop 10 - cpe:/o:suse:sled:10
> SUSE Linux Enterprise Server 11 - cpe:/o:suse:sles:11
> SUSE Linux Enterprise Desktop 11 - cpe:/o:suse:sled:11
> SUSE Linux Enterprise Server 12 - cpe:/o:suse:sles:12
> SUSE Linux Enterprise Desktop 12 - cpe:/o:suse:sled:12
> openSUSE 11.4 - cpe:/o:opensuse:opensuse:11.4
> openSUSE 13.1 - cpe:/o:opensuse:opensuse:13.1
> openSUSE 13.2 - cpe:/o:opensuse:opensuse:13.2
> openSUSE 42.1 - cpe:/o:novell:leap:42.1
> openSUSE All Versions - cpe:/o:opensuse:opensuse
> Red Hat Enterprise Linux Optional Productivity Applications -
> cpe:/a:redhat:rhel_productivity
> Red Hat Enterprise Linux Optional Productivity Applications 5 -
> cpe:/a:redhat:rhel_productivity:5
> 
>  Supported OVAL objects and associated OpenSCAP probes 
> system_info probe_system_info
> family probe_family
> filehash probe_filehash
> environmentvariable probe_environmentvariable
> textfilecontent54 probe_textfilecontent54
> textfilecontent probe_textfilecontent
> variable probe_variable
> xmlfilecontent probe_xmlfilecontent
> environmentvariable58 probe_environmentvariable58
> filehash58 probe_filehash58
> inetlisteningservers probe_inetlisteningservers
> rpminfo probe_rpminfo
> partition probe_partition
> iflisteners probe_iflisteners
> rpmverify probe_rpmverify
> rpmverifyfile probe_rpmverifyfile
> rpmverifypackage probe_rpmverifypackage
> selinuxboolean probe_selinuxboolean
> selinuxsecuritycontext probe_selinuxsecuritycontext
> file probe_file
> interface probe_interface
> password probe_password
> process probe_process
> runlevel probe_runlevel
> shadow probe_shadow
> uname probe_uname
> xinetd probe_xinetd
> sysctl probe_sysctl
> process58 probe_process58
> fileextendedattribute p

Re: [Open-scap] Informational value

[Jan Cerny]

Hi Rocio,

IMHO it should work always, this must be a very weird bug.
I haven't managed to reproduce the issue with the command you provided.
Please ensure that you have OpenSCAP newer that 1.2.2.
To be able to reproduce it and investigate it I would need your benchmark.

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Rocio Romero" 
> To: "Jan Cerny" 
> Sent: Tuesday, July 5, 2016 8:51:09 PM
> Subject: Re: [Open-scap] Informational value
> 
> HI Jan,
> 
> I reviewed the process again.
> 
> When I executed the command,
> 
> $oscap xccdf eval --profile my_profile --results results.xml --oval-results
> --report report.html my_benchmark-ds.xml
> 
> This time I realized that the option creates the
> my_benchmark-oval.xml.results.xml file, where is the oval results
> information. But this information is not showed on the html file.
> 
> The command doesn't give errors.
> 
> What could be happening here?
> 
> 
> 
> *Rocio Romero *
> 
> *IT Security Engineer*
> [image: http://www.wazuh.com/] <http://www.wazuh.com/>
> 
> On Mon, Jul 4, 2016 at 4:25 AM, Jan Cerny  wrote:
> 
> > Hi Rocio,
> >
> > It should work always when using OVAL definitions.
> > This looks like a bug. Could you provide details, please?
> >
> > Regards
> >
> > Jan Černý
> > Security Technologies | Red Hat, Inc.
> >
> > - Original Message -
> > > From: "Rocio Romero" 
> > > To: "Jan Cerny" 
> > > Cc: open-scap-list@redhat.com
> > > Sent: Friday, July 1, 2016 7:56:08 PM
> > > Subject: Re: [Open-scap] Informational value
> > >
> > > Hi Jan,
> > >
> > > Thank you so much for your answer! It was really helpful :)
> > >
> > > I have one more question with the -oval-results option…. For some
> > reason, it
> > > did’t show the details with a benchmark I have. I tried with other
> > personal
> > > benchmark and that one worked. There is something needed in the xccdf or
> > > oval file to make it works? I reviewed both and I don’t know what is
> > exactly
> > > happening :/
> > >
> > > Thank you!
> > >
> > > Rocio
> > >
> > >
> > >
> > >
> > > > On Jul 1, 2016, at 12:38 AM, Jan Cerny  wrote:
> > > >
> > > > Hi Rocio,
> > > >
> > > > Yes, the result of an XCCDF check can be "informational".
> > > > The XCCDF specification [1] says that:
> > > >
> > > > The  was checked, but the output from the checking engine
> > is
> > > > simply
> > > > information for auditors or administrators; it is not a compliance
> > > > category. This status value is
> > > > designed for  elements whose main purpose is to extract
> > > > information from the
> > > > target rather than test the target.
> > > >
> > > > From what I understand, this value is used for rules that are
> > evaluated,
> > > > but not going to be
> > > > counted into the result score (do not affect the score). That happens
> > if
> > > > you have an XCCDF rule
> > > > with attribute "role" set to "unscored".
> > > > However I am sorry I haven't found any check in OpenSCAP that is using
> > > > this.
> > > >
> > > > Regarding your second question, OpenSCAP >= 1.2.2 can display OVAL
> > results
> > > > in the HTML report if you run it with "--oval-results", eg.:
> > > >
> > > > # oscap xccdf eval --results results.xml --oval-results --report
> > > > report.html my_benchmark.xml
> > > >
> > > > The HTML report will look like in [2].
> > > >
> > > > [1]
> > http://csrc.nist.gov/publications/nistir/ir7275-rev4/NISTIR-7275r4.pdf
> > > > (page 43)
> > > > [2]
> > > >
> > https://www.open-scap.org/wp-content/uploads/2015/09/ssg-rhel7-ds-xccdf.report.html
> > > >
> > > > I hope this helps.
> > > >
> > > > Best regards
> > > >
> > > > Jan Černý
> > > > Security Technologies | Red Hat, Inc.
> > > >
> > > > - Original Message -
> > > >> From: "Rocio Romero" 
> > > >> To: open-scap-list@redhat.com
> > > >> Sent: Thursday, June 30, 2016 9:50:34 PM
> > > >> Subject: [Open-scap] Informational value
> > > >>
> > > >> Hi everyone,
> > > >>
> > > >> I was taking a look to the possibles values we can get from a check in
> > > >> this
> > > >> webpage
> > > >>
> > https://sadocs.emc.com/0_en-us/089_105InfCtr/215_SysAdm/ConfigurSTIG/30_OpenSCAPRpt
> > > >> .
> > > >>
> > > >> I saw that “Informational” is a valid value. Could you please give me
> > an
> > > >> example of this?
> > > >>
> > > >> Also, I was wondering if there is any way to return some output from a
> > > >> check
> > > >> and put this output in the report (a friend ask me about that and I’m
> > not
> > > >> sure 100%).
> > > >>
> > > >> Thank you so much,
> > > >>
> > > >> Rocio
> > > >>
> > > >> ___
> > > >> Open-scap-list mailing list
> > > >> Open-scap-list@redhat.com
> > > >> https://www.redhat.com/mailman/listinfo/open-scap-list
> > >
> > >
> >
> 

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Informational value

[Jan Cerny]

Hi Shawn, Hi all,

- Original Message -
> From: "Shawn Wells" 
> To: open-scap-list@redhat.com
> Sent: Tuesday, July 5, 2016 3:46:44 PM
> Subject: Re: [Open-scap] Informational value
> 
> 
> 
> On 7/1/16 3:38 AM, Jan Cerny wrote:
> 
> 
> 
> Regarding your second question, OpenSCAP >= 1.2.2 can display OVAL results
> in the HTML report if you run it with "--oval-results", eg.:
> 
> # oscap xccdf eval --results results.xml --oval-results --report report.html
> my_benchmark.xml
> 
> The HTML report will look like in [2].
> 
> [1] http://csrc.nist.gov/publications/nistir/ir7275-rev4/NISTIR-7275r4.pdf
> (page 43)
> [2]
> https://www.open-scap.org/wp-content/uploads/2015/09/ssg-rhel7-ds-xccdf.report.html
> 
> Can we have the findings showup in the default reports, e.g. those without
> --oval-results? Why burden the users with another CLI argument?

The report is generated from both the XCCDF results and OVAL results documents
using XSLT templates and transformations. The XSLT just parses the XML document
and converts it into a nicely formated document.

I think we can have OVAL details by default when report is created.
On the other hand, the --oval-results option has a side effect - it generates 
an OVAL results XML document.
Does it matter that there will be always an additional file? Or should we 
create a temporary file?
Could we prefer using ARFs?

> 
> Also, some of the OVAL result summaries are very confusing. Compare "Set Last
> Logon/Access Notification" with the various object and type expressions
> listed in "Set Deny For Failed Password Attempts" it's not clear what
> all that means. "Last Logon" shows the text of the passing file, whereas
> "Failed Password Attempts" lists subexpressions instead.
> 
> Does this depend on how the OVAL rules are written, or OpenSCAP reporting?
> Reports would be easier to interpret if we showed the offending text, vs a
> "subexpression" value.

I agree that it is often confusing. It depends on the way how the OVAL checks 
are written.

These problems are all caused by the fact that the report is created after from 
the
OVAL and XCCDF results documents. We have to follow the SCAP standards in those 
documents.
Adding another information to the report that cannot be represented in OVAL 
results is a problem.
We could "hack" the  elements and use them for storing the values for 
the report.

> 
> E.g.: current report from "failed password attempts":
> 
> 
> 
> 
> Items not found violating Check pam_faillock.so preauth silent present in
> /etc/pam.d/system-auth :
> Object oval:ssg:obj:870 of type textfilecontent54_object
> Behaviors Filepath Pattern Instance
>   no value/etc/pam.d/system-auth
>   
> [\n][\s]*auth[\s]+required[\s]+pam_faillock\.so[\s]+preauth[\s]+silent[\s]+[^\n]*deny=([0-9]+)[\s]*[^\n]*[\n][\s]*auth[\s]+sufficient[\s]+pam_unix\.so[^\n]*[\n]
>   1 State oval:ssg:ste:871 of type textfilecontent54_state
> Subexpression
>   6
> 
> 
> Could be changed to:
> 
> 
> Items not found violating Check pam_faillock.so preauth silent present in
> /etc/pam.d/system-auth :
> Object oval:ssg:obj:870 of type textfilecontent54_object
> Behaviors Filepath Pattern Instance
>   no value/etc/pam.d/system-auth
>   
> [\n][\s]*auth[\s]+required[\s]+pam_faillock\.so[\s]+preauth[\s]+silent[\s]+[^\n]*deny=([0-9]+)[\s]*[^\n]*[\n][\s]*auth[\s]+sufficient[\s]+pam_unix\.so[^\n]*[\n]
>   1 State of /etc/pam.d/system-auth
> Subexpression
>   FAIL: No lines match regex in /etc/pam.d/system-auth

Great idea. Implementing such a thing in XSLT will be very challenging :-)
but your suggestion would greatly improve the user experience.


> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

Best Regards

Jan Černý
Security Technologies | Red Hat, Inc.


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Informational value

[Jan Cerny]

Hi Martin,

> > The report is generated from both the XCCDF results and OVAL results
> > documents
> > using XSLT templates and transformations. The XSLT just parses the XML
> > document
> > and converts it into a nicely formated document.
> 
> This is a long standing issue. We recommend using ARF (--results-arf) to
> mitigate it. OVAL details are always generated if the user is using ARF
> results instead of the plain XCCDF results.

I'm afraid it doesn't work like that now. With ARF you also must add 
--oval-results
to show the details in the HTML report.

Try e.g.
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_common 
--results-arf arf.xml --report report1.html 
/usr/share/xml/scap/ssg/content/ssg-fedora-ds.xml
vs.
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_common 
--results-arf arf.xml --report report2.html --oval-results 
/usr/share/xml/scap/ssg/content/ssg-fedora-ds.xml
And you will see that report1.html doesn't contain the details because 
--oval-results was not specified.

But I also expected that it works always. I think it should be changed in a way 
you suggested.
Then we could recommend users to use ARFs always and simplify a lot of commands
in our user manual and tutorials.


Best regards

Jan Černý
Security Technologies | Red Hat, Inc.

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Systemdunitproperty issue

[Jan Cerny]

- Original Message -
> From: "Steve Grubb" 
> To: open-scap-list@redhat.com
> Cc: "Jan Cerny" , "Rocio Romero" 
> Sent: Monday, July 11, 2016 7:08:49 PM
> Subject: Re: [Open-scap] Systemdunitproperty issue
> 
> On Monday, July 11, 2016 3:13:55 AM EDT Jan Cerny wrote:
> > That happens usually when your system is missing some of the required
> > header
> > files. I think it can be dbus.h, located in
> > /usr/include/dbus-1.0/dbus/dbus.h, provided by dbus-devel package. Try to
> > install dbus-devel using "yum install dbus-devel" and then run "./configure
> > && make && make install" again.
> > 
> > I can see the dbus-devel package is not included in our README in the build
> > dependencies list, I will add it there soon.
> > 
> > You should be able to identify the missing header files in output produced
> > by ./configure, eg:
> > 
> >  * Checking presence of required headers for the systemdunitproperty probe
> >  811 checking for dbus/dbus.h... yes
> >  812 checking for string.h... (cached) yes
> 
> MIssing headers should error out the configure script if the passed configure
> script options requires them.

Yes, but this does not affect the probes. If some header required for a probe
is missing, then that particular probe is not compiled, but others are built 
successfully. 
We need this behavior because this way we don't compile e.g. systemd probes on 
RHEL6
or rpm probes on Debian.

Jan Černý
Security Technologies | Red Hat, Inc.
> -Steve
> 
> 

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

[Open-scap] New COPR repository for OpenSCAP

[Jan Cerny]

Hi all,

We have created a new COPR repository that provides unofficial builds
of latest versions of openscap, scap-security-guide, scap-workbench
and openscap-daemon packages. The packages are suitable for use
on Red Hat Enterprise Linux 5, 6 and 7 and CentOS 5, 6 and 7.
The COPR repository is located on:
https://copr.fedorainfracloud.org/coprs/openscapmaint/openscap-latest/

The repo enables you to test the latest greatest OpenSCAP bits on RHEL and 
CentOS.

The former repository isimluk/OpenSCAP will not be maintained anymore.
Sorry for inconvenience.

Best regards

Jan Černý
Security Technologies | Red Hat, Inc.


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Compilation of Openscap: how to turn off the build dependency via configure

[Jan Cerny]

Hi Steve, Hi all,

in that case, we should implement ability to turn on and off each probe 
specifically
by ./configure options.
For example, if somebody will want to compile openscap without the rpminfo 
probe, the he should be able to run
./configure --disable-probe-rpminfo && make
and that will do the job for him

Unfortunately it is not possible now, although  it would be beneficial for 
developers and packagers.
Now people are only able to disable groups of probes, eg. --disable-probes-linux
We should also specify which of the probes will be turned on by default.

Also not forget to ensure that during the CI tests we build all of them,
because it is exciting to have a test which is never executed :)

Does that proposal makes sense to you?

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Steve Grubb" 
> To: open-scap-list@redhat.com
> Cc: "Rongli Shi" 
> Sent: Tuesday, August 2, 2016 1:47:37 AM
> Subject: Re: [Open-scap] Compilation of Openscap: how to turn off the build   
> dependency via configure
> 
> On Monday, August 1, 2016 2:47:13 PM EDT Martin Preisler wrote:
> > - Original Message -
> > 
> > > From: "Rongli Shi" 
> > > To: open-scap-list@redhat.com
> > > Sent: Friday, June 24, 2016 2:54:38 AM
> > > Subject: [Open-scap] Compilation of Openscap: how to turn off the build
> > > dependency via configure
> > > 
> > > Hi guys,
> > > 
> > > How could I turn off the build dependency via configure as mentioned by
> > > the
> > 
> > > doc:
> > You don't have to turn any of these off per se. If these dependencies
> > aren't
> > detected openscap will disable the functionality that requires those deps.
> 
> Most configure scripts that I've seen error out so that you don't silently
> get
> missing functionality. For example, if you make a packaging mistake and don't
> get all the dependencies, you have a build that works but openscap wouldn't
> work as intended.
> 
> -Steve
> 
> > I have changed the README to avoid this confusion in the future. Thanks
> > for checking with us!
> > 
> > https://github.com/OpenSCAP/openscap/commit/c3fd0fb6adbc8856993f8f1c9ce62ecc
> > 1ac1a520
> 
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
> 

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Issue with "official" RHEL-7 definitions

[Jan Cerny]

Hi,

New version of SCAP Security guide usually appears with a new release of RHEL).
(but not necessarily always)
I haven't looked exactly into firewall rules, but in general SCAP Security Guide
is evolving very quickly, so it is very likely that they were not present at 
all in 0.1.25.

OpenSCAP COPR repo for RHEL7 provides the latest releases, however keep in mind 
that
it is not officially supported by Red Hat. On the other hand, there is usually 
only a little
difference between packages in COPR and packages in RHEL for the same version.

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Dan White" 
> To: open-scap-list@redhat.com
> Sent: Monday, August 22, 2016 2:27:56 PM
> Subject: [Open-scap] Issue with "official" RHEL-7 definitions
> 
> Working from /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml which is part
> of scap-security-guide-0.1.25-3.el7.noarch, I find a complete lack of any
> firewall definitions.
> 
> scap-security-guide-0.1.30-2.el7.centos.noarch.rpm, from
> openscapmaint-openscap-latest-epel-7.repo, however, has lots of good
> firewall checks and specs.
> 
> How soon might these newer definitions find their way into the Red Hat repos
> ?
> Dan White | d_e_wh...@icloud.com
> 
> “Sometimes I think the surest sign that intelligent life exists elsewhere in
> the universe is that none of it has tried to contact us.”  (Bill Waterson:
> Calvin & Hobbes)
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] OpenSCAP Error: OVAL object not correctly defined

[Jan Cerny]

Hi Rocio,

I am sorry for a late reply, but most of the OpenSCAP team is not present right 
now.

Your issue seems to me like a regular bug, but I don't use Oracle,
so I am afraid I can't help so much.

AFAIK the code path leading to the message you described should be run
on every evaluation of any benchmark.

Since OpenSCAP 1.2.9 the verbose mode can bring some light, eg.
# oscap xccdf eval --verbose INFO your_bechmark.xml
Problems with installation should be fixed by reinstalling the packages, but I 
expect
you already tried that. 
If this doesn't help, we will need to run oscap in debugger and try what's 
going on there.

Which version of OpenSCAP do you use? Is it from official Oracle repo?
It would be nice if you provide a reproducer scenario.

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Rocio Romero" 
> To: open-scap-list@redhat.com
> Sent: Tuesday, August 16, 2016 8:19:18 PM
> Subject: [Open-scap] OpenSCAP Error: OVAL object not correctly defined
> 
> HI guys,
> 
> I’m testing the benchmark I created on a new machine and I’m getting an error
> that I don’t know how to solve. It is a machine with Oracle Linux 6.8
> 
> I think that is something related with the OSCAP installation…
> 
> This is the error:
> 
> OpenSCAP Error: OVAL object not correctly defined [oval_probe.c:318]
> Failed to create new OVAL agent session for:
> 'Oracle_Linux_6_Benchmark-oval.xml'. [xccdf_session.c:794]
> 
> And I’m not getting this error only with this file, all the files that I try
> on this machine get the same error. I assume that it is not something
> included on the file (The file works in all the machines I tested it except
> this one)
> 
> Is there anyway to get more information about this error to know what is
> going on here?
> 
> Any ideas?
> 
> Thank you all
> 
> Rocio
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Really nice tool

[Jan Cerny]

Hello David,

- Original Message -
> From: "david oliva" 
> To: Open-scap-list@redhat.com
> Sent: Tuesday, September 27, 2016 3:09:35 AM
> Subject: [Open-scap] Really nice tool
> 
> 
> 
> Dear Red Hat /OpenSCAP team:
> 
> 
> 
> 
> Today 26 Sep 2016 Ihad the opportunity to run OpenSCAP on RHEL 7 for the
> first time, andI am very pleased.

Nice to hear that!

> 
> Installing OpenSCAP,and the SCAP Workbench was very straight forward with the
> yum installcommand.
> 
> 
> 
> - The content thatcame with the package was easy to run. I used the Workbench
> to run the XCCDF content, created an XML report and looked at the report in
> another browser.

You can also generate a nice HTML report using "Show report" button.

> 
> 
> 
> 
> - It was very niceto see a good use of the CCE specification. The first
> questioncoming to mind is, do you maintain a CCE dictionary that you can
> makeavailable? A second question is, if a user wants to identify
> aconfigurable parameter and no CCE is available, can the user (verylikely a
> developer) request a CCE number?

We don't maintain a CCE dictionary, the CCE numbers have been requested from 
NIST.

> 
> 
> 
> - Analyzing theoutput XML reveals that the findings are mapped to the
> securitycontrols of SP 800-53 Rev 4. What a nice feature!.
> 
> 
> 
> 
> - One of the videoson your site (
> https://www.open-scap.org/security-policies/scap-security-guide/#documentation
> )indicates that you are engaging a remediation mechanism and not
> justdiscovering vulnerabilities. Are you using a remediation protocolor
> specification in particular?

Remediation is done by remediation scripts. The scripts are written in Bash.
Those scripts are included in the SCAP content.
The remediation can be run directly while scanning from SCAP Workbench or oscap 
command line tool.

Currently we are working on adding remediation in a from of Ansible playbooks.
See https://blog-zbynek.rhcloud.com/2016/09/12/ssg-openscap-and-ansible/


> 
> 
> 
> 
> - The output XMLshows a very nice use of the CPE specification.
> 
> 
> 
> - The use of XCCDFis also very good. Can you please, point me to a Red Hat
> XCCDFrepository? Are you planning your content in the
> NationalVulnerabilities Database?

I suppose you mean that XCCDF that SCAP Workbench used for scanning your RHEL 
machine.
That XCCDF comes from the SCAP Security Guide project. SCAP Security guide is 
an open-source
set of security policies written in SCAP format.
The source code is available at Github:
https://github.com/OpenSCAP/scap-security-guide
Latest release is here:
https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.30/scap-security-guide-0.1.30.zip
We plan to submit the USGCB profile of SCAP Security Guide to NVD.

> 
> 
> 
> 
> - I am interested inrunning a vulnerability scan (I would like to see how
> OpenSCAP usesCVEs and CVSS)

Yes, it is possible, and it's one of the most common use-cases of OpenSCAP.
Red Hat provides a CVE streams for all the CVEs discovered in RHEL as a part of 
Red Hat Security Advisories.
See 
https://www.open-scap.org/resources/documentation/perform-vulnerability-scan-of-rhel-6-machine/
(It's for RHEL6, but in RHEL7 it's very similar)

> 
> 
> 
> 
> 
> 
> 
> - I did not see anyindication of using the Asset Identification (AI)
> specification.

OpenSCAP doesn't support this.

> 
> 
> 
> 
> - I did not see anyindication of using the Asset Reporting Format (ARF)
> specification.

We fully support the ARF format, both in SCAP Workbench and oscap tool.
In SCAP Workbench, it's possible to save results as ARF using Save results 
button.
Actually we recommend ARF as a best format for reporting :-)

> 
> - I did not see anyindication of using the Common Configuration Scoring
> System (CCSS)specification.
> - I did not see anyindication of using the TMSAD specification.
> - I did not see anyindication of using the Open Checklist Interactive
> Language (OCIL)specification. I am interested in your use of this
> specificationbecause many security functions are not “automatable” (can not
> bechecked with security automation tools).


We don't support these three specifications.

> 
> 
> 
> - Are you planningto implement the Software Identification (SWID)
> specification of SCAP1.3?

SWID is on our radar, but I can't promise anything now.

> 
> 
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

I hope I have answered your questions.

If you have any other questions or need more information,
we'll be excited to help you.

Best regards

Jan Černý
Security Technologies | Red Hat, Inc.

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

[Open-scap] OpenSCAP 1.2.11

[Jan Cerny]

Hello OpenSCAPers,

We are thrilled to announce general availability of OpenSCAP 1.2.11 release.

This is the latest release from maint-1.2 maintenance branch. API/ABI is
fully compatible with 1.2.0 release. Users of 1.2.x releases are
recommended to update.

Changes:
  - New features
- huge speed-up of generating HTML reports and guides
- support remote datastream components (issue #526)
- support tailoring of external datastreams
- various attributes of remediation scripts are now shown in HTML report 
(issue #541)
- new option generating OVAL results without system characteristics
- remediation scripts in HTML report are now collapsed
- support for extracting Ansible playbooks
- enabled fetching remote resources in OVAL module
- added Wind River Linux CPE
  - Maintenance
- updated jQuery and bootstrap libraries in HTML reports
- extended, improved and updated user manual
- fixed issues with proxy in oscap-docker (RHBZ #1351952)
- fixed a bug in OVAL arithmetic function
- fixed a segmentation fault (issue #529)
- fixed results of XCCDF rules with @role="unscored" (issue #525)
- fixed invalid characters in OVAL results (issue #468)
- fixed a segmentation fault in tailoring (RHBZ #1367896)
- updated SUSE 11 CPE
- fixed many memory issues
- large refactoring of datastream module
- new tests in upstream test suite
- various small fixes and improvements

Special thanks to our new contributors Raphael Sanchez Prudencio, Watson Sato
and Radzy Radzykewycz.

Download:
https://github.com/OpenSCAP/openscap/releases/download/1.2.11/openscap-1.2.11.tar.gz

SHA512:
fbdc0fada6dc17d52cadc4cd219811bde4d8f09b1bd95260ea59ec78e1fb3d7775e04e85b87f504f4ff35f7b9a746bcf970ec34c3b350a3c839055077aefc50d

Audit, Fix, And Be Merry!


Jan Černý
Security Technologies, Red Hat, Inc.
on behalf of OpenSCAP contributors

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

[Open-scap] OpenSCAP 1.2.12

[Jan Cerny]

Hello OpenSCAPers,

We are thrilled to announce general availability of OpenSCAP 1.2.12 release.

This is the latest release from maint-1.2 maintenance branch. API/ABI is
fully compatible with 1.2.0 release. Users of 1.2.x releases are
recommended to update.

Changes:
  - New features
- separated stdout and stderr in SCE results and HTML report
- HTML reports contain [ref] links for rules and groups
  - Maintenance
- fixed ARF errors reported by the SCAPval tool
- fixed CVE parsing (issue #550)
- fixed namespace of ARF vocabulary according to NIST SP800-126 errata
- fixed exporting OVAL Windows namespaces
- fixed injecting xccdf:check-content-ref references in ARF results
- fixed oscap-docker incompliance reporting (issue #475, RHBZ #1387248)
- fixed oscap-docker man page (RHBZ #1387166)
- fixed memory leaks and resource leaks
- small fixes and refactoring, test suite fixes

Special thanks to our new contributor V. Vinay.

Download:
https://github.com/OpenSCAP/openscap/releases/download/1.2.12/openscap-1.2.12.tar.gz

SHA512:
1b0cf34e6e394c8a4914a264d5e50559277027743882fe0553d01b44745551f81da75c9d43b49e8096e37c26f928aa915e07bb456d5689581a90eae673b990aa

Audit, Fix, And Be Merry!


Jan Černý
Security Technologies, Red Hat, Inc.
on behalf of OpenSCAP contributors

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] oscap-docker: OVAL vs XCCDF eval

[Jan Cerny]

Hi Shawn,

In first case you have a mistake, you are using OVAL content instead of XCCDF 
in oscap xccdf evel.

In second case there is a known bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1387248
https://github.com/OpenSCAP/openscap/issues/475
When oscap returns exit code 2 the system isn't compliant with the given 
profile.
However oscap-docker didn't handle the exit code correctly and reports an error.
The bug is fixed in OpenSCAP 1.2.12.

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Shawn Wells" 
> To: "open-scap-list" 
> Sent: Thursday, November 17, 2016 1:00:14 AM
> Subject: [Open-scap] oscap-docker: OVAL vs XCCDF eval
> 
> Attempting to use oscap-docker on RHEL7 host, scanning RHEL7 containers.
> I can use the OVAL scanner but not XCCDF eval. Is this a known issue?
> 
> e.g.
> 
> > # oscap-docker container rhel7.0 oval eval \
> > --results oval-results.xml \
> > --report report.html\
> > /usr/share/xml/scap/ssg/content/ssg-rhel7-oval.xml
> > ..
> > Definition oval:ssg-xwindows_runlevel_setting:def:1: true
> > Definition oval:ssg-wireless_disable_interfaces:def:1: true
> > Definition oval:ssg-var_umask_for_daemons_as_number:def:1: true
> > Definition oval:ssg-var_removable_partition_is_cd_dvd_drive:def:1: unknown
> > Definition oval:ssg-var_accounts_user_umask_as_number:def:1: true
> > Definition oval:ssg-userowner_shadow_file:def:1: true
> > ..
> 
> 
> But if using an actual profile:
> > # oscap-docker container rhel7.0 xccdf eval \
> > --profile
> > xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream \
> > --results xccdf-results.xml \
> > --report report.html\
> > /usr/share/xml/scap/ssg/content/ssg-rhel7-oval.xml
> >
> > OpenSCAP Error: Session input file was determined but it isn't an
> > XCCDF file, a source datastream or an XCCDF tailoring file.
> > [xccdf_session.c:135]
> >
> > Command: oscap xccdf eval --profile
> > xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream
> > --results oval-results.xml --report report.html
> > /usr/share/xml/scap/ssg/content/ssg-rhel7-oval.xml failed!
> >
> > Error was:
> >
> > Command '['oscap', 'xccdf', 'eval', '--profile',
> > 'xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream',
> > '--results', 'oval-results.xml', '--report', 'report.html',
> > '/usr/share/xml/scap/ssg/content/ssg-rhel7-oval.xml']' returned
> > non-zero exit status 1
> 
> Also tried with XCCDF file, vs datastream:
> 
> > # oscap-docker container rhel7.0 xccdf eval \
> > > --profile stig-rhel7-server-upstream \
> > > --results xccdf-results.xml \
> > > --report report.html \
> > > /usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml
> > WARNING: Skipping
> > http://www.redhat.com/security/data/oval/com.redhat.rhsa-RHEL7.xml.bz2
> > file which is referenced from XCCDF content
> >
> > Command: oscap xccdf eval --profile stig-rhel7-server-upstream
> > --results xccdf-results.xml --report report.html
> > /usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml failed!
> >
> > Error was:
> >
> > Command '['oscap', 'xccdf', 'eval', '--profile',
> > 'stig-rhel7-server-upstream', '--results', 'xccdf-results.xml',
> > '--report', 'report.html',
> > '/usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml']' returned
> > non-zero exit status 2
> 
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
> 

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] oscap xccdf generate fix --template urn:xccdf:fix:script:ansible working?

[Jan Cerny]

Hi,

thank you very much for reaching us.

Your problem can have multiple reasons:

1. Ansible playbooks are a new feature in SCAP Security Guide 0.1.31, released 
recently.
If you use older version, you can download the latest release on 
https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.31/scap-security-guide-0.1.31.zip

2. OpenSCAP older than 1.2.13 used to filter out the playbooks that are not 
applicable on the system where
OpenSCAP runs. If you run OpenSCAP to generate playbook on a different system 
than RHEL7,
the playbooks got filtered out because they are not applicable.
You can solve this by upgrading to 1.2.13, where this "feature" (bug) was 
removed.
You can also bypass this problem by removing the following lines from the 
ssg-rhel7-ds.xml
manually using a text editor:





3. OpenSCAP older than 1.2.11 generated incorrect playbooks.

I suggest using all the software in the latest versions. This command is working
for me with SCAP Security guide 0.1.31 and OpenSCAP 1.2.13 :

oscap xccdf generate fix --template urn:xccdf:fix:script:ansible --profile 
xccdf_org.ssgproject.content_profile_C2S --output playbook.yml ssg-rhel7-ds.xml

Also please note that playbooks in SCAP Security Guide are not complete, it's 
mostly a technical preview.
Contributions are welcome!

Best regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Eric Martin" 
> To: open-scap-list@redhat.com
> Sent: Monday, January 23, 2017 4:57:03 PM
> Subject: [Open-scap] oscap xccdf generate fix --template  
> urn:xccdf:fix:script:ansible working?
> 
> 
> 
> Hello,
> 
> 
> 
> I’m new to OpenSCAP and I’m using ansible so I’m trying to generate an
> ansible playbook using:
> 
> 
> 
> # oscap xccdf generate fix --template urn:xccdf:fix:script:ansible --profile
> xccdf_org.ssgproject.content_profile_C2S --output ./playbook.yml
> /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml
> 
> # ll playbook.yml*
> 
> -rwx--. 1 root root 0 Jan 23 16:38 playbook.yml
> 
> #
> 
> The generated file is empty.
> 
> 
> 
> If I’m trying:
> 
> # oscap xccdf generate fix --template urn:xccdf:fix:script:sh --profile
> xccdf_org.ssgproject.content_profile_C2S --output ./playbook.sh
> /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml
> 
> # ll playbook.sh*
> 
> -rwx--. 1 root root 426157 Jan 23 16:38 playbook.sh
> 
> #
> 
> Then the shell script is generated.
> 
> 
> 
> My question is:
> 
> Does the urn:xccdf:fix:script:ansible option working?
> 
> I did see that someone managed to get it working:
> https://blog-zbynek.rhcloud.com/2016/09/12/ssg-openscap-and-ansible/
> 
> 
> 
> Thanks,
> 
> 
> 
> Eric Martin
> 
> 
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] inconsistent reporting on auditd

[Jan Cerny]

Hi,

It might be a bug, but also there can be another reason why this rule failed.

First thing that I would try is to add "--oval-results" to your command
and run the scan again. This option adds more details into the HTML report,
which hopefully could help you with identifying the problem.

Best Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Luke Hinds" 
> To: open-scap-list@redhat.com
> Sent: Tuesday, January 24, 2017 11:40:19 PM
> Subject: [Open-scap] inconsistent reporting on auditd
> 
> Hi,
> 
> When performing a xccdf scan of Centos 7 I am finding the report of auditd
> rule entries inconsistent with how the file is configured.
> 
> The following is reported as a fail, yet its an exact match for the scap
> report entry:
> 
> https://i.imgur.com/m1q7CLf.png
> 
> The following is a pass:
> 
> https://i.imgur.com/LqDiRPO.png
> 
> My command:
> 
> # oscap xccdf eval --profile common --report ~/report-xccdf.html --results
> ~/results.xml --cpe
> /usr/share/xml/scap/ssg/content/ssg-rhel7-cpe-dictionary.xml
> /usr/share/xml/scap/ssg/content/ssg-centos7-xccdf.xml
> 
> Should I raise this as a bug?
> 
> Regards,
> 
> Luke
> 
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] oscap-docker on Ubuntu 14.04

[Jan Cerny]

Hi,

which Python version is used by your /usr/bin/oscap-docker ?
There might be a collision between Python2 and Python3.
The script should run on both versions of Python, but most likely
you have necessary modules only for Python 2.

Also notice that oscap-docker needs Atomic [1] installed
as a dependency, to mount the container images.
I'm not sure whether atomic is available on Ubuntu.

Regards

[1] https://github.com/projectatomic/atomic

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Pravin Goyal" 
> To: open-scap-list@redhat.com
> Sent: Sunday, February 5, 2017 3:53:15 PM
> Subject: Re: [Open-scap] oscap-docker on Ubuntu 14.04
> 
> 
> 
> However, on the machine I do see openscap-python is present:
> 
> 
> 
> 
> 
> ubuntu@ip-172-31-5-56:/usr/lib/python2.7/site-packages/oscap_docker_python$
> ls
> get_cve_input.py get_cve_input.pyo __init__.pyc oscap_docker_util.py
> oscap_docker_util.pyo
> get_cve_input.pyc __init__.py __init__.pyo oscap_docker_util.pyc
> 
> 
> 
> 
> 
> 
> From: Pravin Goyal 
> Sent: Sunday, February 5, 2017 8:10:57 PM
> To: open-scap-list@redhat.com
> Subject: oscap-docker on Ubuntu 14.04
> 
> 
> Hi All,
> 
> I could successfully compile OpenSCAP 1.2.13 on Ubuntu 14.04. But,
> oscap-docker does not seem to work.
> 
> 
> 
> 
> 
> Traceback (most recent call last):
> File "/usr/bin/oscap-docker", line 23, in 
> from oscap_docker_python.oscap_docker_util import OscapScan
> ImportError: No module named oscap_docker_python.oscap_docker_util
> 
> 
> 
> 
> 
> 
> What could be the issue?
> 
> 
> 
> 
> Here is the output of oscap -V.
> 
> 
> 
> 
> Please let me know.
> 
> 
> 
> 
> Thanks and regards,
> 
> Pravin Goyal
> 
> 
> 
> 
> 
> ubuntu@ip-172-31-5-56:/$ oscap -V
> OpenSCAP command line tool (oscap) 1.2.13
> Copyright 2009--2016 Red Hat Inc., Durham, North Carolina.
> 
>  Supported specifications 
> XCCDF Version: 1.2
> OVAL Version: 5.11.1
> CPE Version: 2.3
> CVSS Version: 2.0
> CVE Version: 2.0
> Asset Identification Version: 1.1
> Asset Reporting Format Version: 1.1
> 
>  Capabilities added by auto-loaded plugins 
> No plugins have been auto-loaded...
> 
>  Paths 
> Schema files: /usr/share/openscap/schemas
> Default CPE files: /usr/share/openscap/cpe
> Probes: /usr/libexec/openscap
> 
>  Inbuilt CPE names 
> Red Hat Enterprise Linux - cpe:/o:redhat:enterprise_linux
> Red Hat Enterprise Linux 5 - cpe:/o:redhat:enterprise_linux:5
> Red Hat Enterprise Linux 6 - cpe:/o:redhat:enterprise_linux:6
> Red Hat Enterprise Linux 7 - cpe:/o:redhat:enterprise_linux:7
> Community Enterprise Operating System 5 - cpe:/o:centos:centos:5
> Community Enterprise Operating System 6 - cpe:/o:centos:centos:6
> Community Enterprise Operating System 7 - cpe:/o:centos:centos:7
> Scientific Linux 5 - cpe:/o:scientificlinux:scientificlinux:5
> Scientific Linux 6 - cpe:/o:scientificlinux:scientificlinux:6
> Scientific Linux 7 - cpe:/o:scientificlinux:scientificlinux:7
> Fedora 16 - cpe:/o:fedoraproject:fedora:16
> Fedora 17 - cpe:/o:fedoraproject:fedora:17
> Fedora 18 - cpe:/o:fedoraproject:fedora:18
> Fedora 19 - cpe:/o:fedoraproject:fedora:19
> Fedora 20 - cpe:/o:fedoraproject:fedora:20
> Fedora 21 - cpe:/o:fedoraproject:fedora:21
> Fedora 22 - cpe:/o:fedoraproject:fedora:22
> Fedora 23 - cpe:/o:fedoraproject:fedora:23
> Fedora 24 - cpe:/o:fedoraproject:fedora:24
> Fedora 25 - cpe:/o:fedoraproject:fedora:25
> SUSE Linux Enterprise all versions - cpe:/o:suse:sle
> SUSE Linux Enterprise Server 10 - cpe:/o:suse:sles:10
> SUSE Linux Enterprise Desktop 10 - cpe:/o:suse:sled:10
> SUSE Linux Enterprise Server 11 - cpe:/o:suse:linux_enterprise_server:11
> SUSE Linux Enterprise Desktop 11 - cpe:/o:suse:linux_enterprise_desktop:11
> SUSE Linux Enterprise Server 12 - cpe:/o:suse:sles:12
> SUSE Linux Enterprise Desktop 12 - cpe:/o:suse:sled:12
> openSUSE 11.4 - cpe:/o:opensuse:opensuse:11.4
> openSUSE 13.1 - cpe:/o:opensuse:opensuse:13.1
> openSUSE 13.2 - cpe:/o:opensuse:opensuse:13.2
> openSUSE 42.1 - cpe:/o:novell:leap:42.1
> openSUSE All Versions - cpe:/o:opensuse:opensuse
> Red Hat Enterprise Linux Optional Productivity Applications -
> cpe:/a:redhat:rhel_productivity
> Red Hat Enterprise Linux Optional Productivity Applications 5 -
> cpe:/a:redhat:rhel_productivity:5
> Wind River Linux all versions - cpe:/o:windriver:wrlinux
> Wind River Linux 8 - cpe:/o:windriver:wrlinux:8
> 
>  Supported OVAL objects and associated OpenSCAP probes 
> system_info probe_system_info
> family probe_family
> filehash probe_filehash
> environmentvariable probe_environmentvariable
> textfilecontent54 probe_textfilecontent54
> textfilecontent probe_textfilecontent
> variable probe_variable
> xmlfilecontent probe_xmlfilecontent
> environmentvariable58 probe_environmentvariable58
> filehash58 probe_filehash58
> dpkginfo probe_dpkginfo
> inetlisteningservers probe_inetlisteningservers
> rpminfo probe_rpminfo
> partition probe_partition
> iflisteners probe_iflisten

Re: [Open-scap] oscap-docker on Ubuntu 14.04

[Jan Cerny]

Hi,

- Original Message -
> From: "Pravin Goyal" 
> To: "Jan Cerny" 
> Sent: Monday, February 6, 2017 3:55:10 PM
> Subject: Re: [Open-scap] oscap-docker on Ubuntu 14.04
> 
> Thanks, Jan. I don't have atomic installed. So, it means I cannot use
> oscap-docker on Ubuntu 14.04?

Atomic is an important dependency, without it oscap-docker is not able
to mount images and containers, therefore it does not scan :(

I haven't found atomic in Ubuntu packages. You might try to install atomic
from sources from Github. However, I have no experience with that.
If you happen to make it working on Ubuntu, sharing your experience will be 
welcome.
I have been googling for a while, but it seems that nobody has used atomic on
Ubuntu so far.

What possibly could help you is a small utility called oscap-chroot,
that can scan arbitrary filesystems. You can mount the docker image's filesystem
into a directory and then use oscap-chroot on that directory.
See man oscap-chroot.

> 
> I tried working with https://github.com/OpenSCAP/container-compliance. It
> does work but gives random results. Is there a way we can make it better? To
> me, it is not working with variables correctly and there are other errors
> that I get when working with the CVE content.
> 
> 

https://github.com/OpenSCAP/container-compliance is an obsolete repository.
The code is no longer maintained. It was replaced by oscap-docker utility
in our main repository. I think it is not worth trying to use this repository.
Before merging it into main OpenSCAP repository the code was completely 
rewritten,
it has been tested and many bugs have already been fixed.

I'm sorry that my answer is not helpful, so I include the mailing list again
hoping that someone else will have a better insight.

Regards

Jan Černý
Security Technologies | Red Hat, Inc.


> 
> From: Jan Cerny 
> Sent: Monday, February 6, 2017 8:21:02 PM
> To: Pravin Goyal
> Cc: open-scap-list@redhat.com
> Subject: Re: [Open-scap] oscap-docker on Ubuntu 14.04
> 
> Hi,
> 
> which Python version is used by your /usr/bin/oscap-docker ?
> There might be a collision between Python2 and Python3.
> The script should run on both versions of Python, but most likely
> you have necessary modules only for Python 2.
> 
> Also notice that oscap-docker needs Atomic [1] installed
> as a dependency, to mount the container images.
> I'm not sure whether atomic is available on Ubuntu.
> 
> Regards
> 
> [1] https://github.com/projectatomic/atomic
> 
> Jan Černý
> Security Technologies | Red Hat, Inc.
> 
> - Original Message -
> > From: "Pravin Goyal" 
> > To: open-scap-list@redhat.com
> > Sent: Sunday, February 5, 2017 3:53:15 PM
> > Subject: Re: [Open-scap] oscap-docker on Ubuntu 14.04
> >
> >
> >
> > However, on the machine I do see openscap-python is present:
> >
> >
> >
> >
> >
> > ubuntu@ip-172-31-5-56:/usr/lib/python2.7/site-packages/oscap_docker_python$
> > ls
> > get_cve_input.py get_cve_input.pyo __init__.pyc oscap_docker_util.py
> > oscap_docker_util.pyo
> > get_cve_input.pyc __init__.py __init__.pyo oscap_docker_util.pyc
> >
> >
> >
> >
> >
> >
> > From: Pravin Goyal 
> > Sent: Sunday, February 5, 2017 8:10:57 PM
> > To: open-scap-list@redhat.com
> > Subject: oscap-docker on Ubuntu 14.04
> >
> >
> > Hi All,
> >
> > I could successfully compile OpenSCAP 1.2.13 on Ubuntu 14.04. But,
> > oscap-docker does not seem to work.
> >
> >
> >
> >
> >
> > Traceback (most recent call last):
> > File "/usr/bin/oscap-docker", line 23, in 
> > from oscap_docker_python.oscap_docker_util import OscapScan
> > ImportError: No module named oscap_docker_python.oscap_docker_util
> >
> >
> >
> >
> >
> >
> > What could be the issue?
> >
> >
> >
> >
> > Here is the output of oscap -V.
> >
> >
> >
> >
> > Please let me know.
> >
> >
> >
> >
> > Thanks and regards,
> >
> > Pravin Goyal
> >
> >
> >
> >
> >
> > ubuntu@ip-172-31-5-56:/$ oscap -V
> > OpenSCAP command line tool (oscap) 1.2.13
> > Copyright 2009--2016 Red Hat Inc., Durham, North Carolina.
> >
> >  Supported specifications 
> > XCCDF Version: 1.2
> > OVAL Version: 5.11.1
> > CPE Version: 2.3
> > CVSS Version: 2.0
> > CVE Version: 2.0
> > Asset Identification Version: 1.1
> > Asset Reporting Format Version: 1.1
> >
> >  Capabilities a

Re: [Open-scap] Windows Support

[Jan Cerny]

Hi,

- Original Message -
> From: "Raphael Sanchez Prudencio" 
> To: open-scap-list@redhat.com
> Sent: Friday, February 3, 2017 5:28:17 PM
> Subject: [Open-scap] Windows Support
> 
> Hello,
> 
> I'm planning some effort towards Windows support for OpenSCAP and I'd
> like to discuss a few topics so we can have an architecture that pleases
> both users and developers.

That's great. I think Windows support will be highly appreciated, because
we often receive requests for this on mailing lists and issues on GitHub 
reporting
that "SCAP Workbench cannot scan my Windows machine" etc.
Idea of Windows support is here for a long time, just nobody was brave enough
to start working on it :-)
It is even a topic for a diploma thesis with Red Hat
see 
https://diplomky.redhat.com/topic/show/267/ms-windows-support-for-openscap-project

I would like to help you with this effort on "upstream Fridays" if you want.

> 
> 1) Change probe architecture:
> 
> Currently our probe system have individual binaries for each OVAL
> object, making it more complex and harder to maintain/debug due to IPC,
> the historical reasons to this is to be able to use tailored SELinux
> policies for each probe, which makes sense but sadly we never
> implemented those policies. 

Actually, we used to have SELinux policy in upstream, and there was a package 
called
openscap-selinux in RHEL, but we decided to remove them, because OpenSCAP needs
to access a lot of paths in the operating system and therefore SELinux policy
would be a huge pain and therefore oscap and probes run as unconfined processes.
See discussion in https://bugzilla.redhat.com/show_bug.cgi?id=1209969 and
https://github.com/OpenSCAP/openscap/commit/a827637ecbb661d1767236b413c1678d13184df6
My opinion is that SELinux is no longer a reason to have probes separately.

I think that another reason for separate processes for probes was a future
possiblity of parallelism, in order to scan faster. To be honest, I think that
it's almost impossible to start implementing parallel scanning, because there
will be too much synchronization problems and we would end in hell of memory 
issues.
Notice that oscap and probes are separate processes and each probe consists of 
multiple threads.

TLDR I don't see any reason now to have the probes as separate processes.


> My proposal is to avoid having multiple
> binaries for Windows environments and make object collecting easier with
> a single probe which handles all objects.
> * Extra: Changing Linux to a single-probe would be interesting too, feel
> free to comment on this topic too!

I think this is a good idea. Actually I would start with Linux probes first.
Firstly, I suggest removing the multi-process architecture in master branch.
This way we could get rid of SEXPs, caches, pipes and all those things
that are the biggest pain for me as a developer.
While removing be able to test that we don't break anything.
I think we will be able to remove and refactor a huge part of the code.

After we have a single-process system, it should be easier to start
implementing support for new Windows OVAL objects.

I would like to avoid having a mixed architecture, where some OVAL objects
will evaluated by oscap process and some other objects will be evaluated
by separate processes. That would be harder to maintain and harder
to orient for other contributors.

Moreover, some probes are defined as independent in the OVAL specification,
so it should be possible to implement them in a portable way. I would
like to avoid having duplicate code for Linux and Windows.

I think if we make it easy for people to add new probes,
we can have more contributors, and not only for Windows,
but also for Android and other operating systems.

> 
> 
> 2) Make it possible to implement/extend object collecting with Lua
> 
> My idea here is to make it easier to implement new (custom) objects or
> to extend/modify existing ones using Lua, interfacing it with all needed
> underlying API for Windows probes like WMI-related objects. Also would
> enable remote scan features such as making extended probes that would
> report only Pass/Fail like Thin Results, which would be really
> interesting for a remote scan in a big infrastructure.
> Lua Virtual Machine is around 100-200kb, it would be really light and
> easy to send it through the network along with Lua probes for remote
> scanning with dissolvable agents which is another plus, not needing
> openscap installed on target machines and deleting the agent after scan.

On the other hand, Lua would be another dependency. We try to have
as least dependencies as possible. That could be a problem for downstream
packagers, and QE of Linux distributions.

Maybe C++ could be also a possible way, and we already have some C++ code
in our codebase, specifically in dpkg_probe.

> 
> 
> I think these are huge and audacious changes that would be more
> interesting than just simply implementing Windows probes in the current
> probe system as is. I'

Re: [Open-scap] Open SCAP for Windows

[Jan Cerny]

Hi Bharath,

We're very pleased that you're interested in OpenSCAP project.

Indeed, OpenSCAP is a great tool for evaluating compliance with a given
security policy for bare-metal machines, virtual machines and also containers.

Actually, OpenSCAP was designed to be able to integrate with other products,
and it already is integrated with system management solutions like ManageIQ,
Red Hat Satellite, and Project Atomic.

I will try to answer your questions.

ad 1) Define a security policy (SCAP Content):

First of all, I'd like to mention that our project "SCAP Security Guide" [1]
provides tested and verified SCAP Content for various systems.
It implements popular security benchmarks like PCI-DSS, STIG or USGCB.
Windows is not currently supported by SCAP Security Guide, but that's
just because nobody started implementing it. It's an open-source project,
so any contributions are welcome :-)

Secondly, if the content provided by "SCAP Security Guide" doesn't exactly
fit user's needs, it can be easily customized by a GUI tool called
SCAP Workbench.

Also, we in OpenSCAP strongly focus on compliance with SCAP standards
as defined by specification. That means OpenSCAP is able to evaluate any
SCAP content that you can obtain from third-party sources (there are many
available) our create yourself.

Unfortunately, we don't provide any "SCAP editor" that would enable
to create security policies from scratch for people with any knowledge
of respective SCAP standards. That's mainly because of complexity of 
the standards, so people rather prefer to have SCAP content written
by security experts than spending weeks by struggling with SCAP languages.


ad 2) Scan a Windows machine:

We can't scan Windows machines now, because we don't have implemented
Windows checks yet.

Fortunately, our developer Raphael Sanchez Prudencio started to work
on Windows scanning last week. He is in design phase now, and he has
started a discussion on the mailing list recently [2].
If you have any comments or if you are able to help him somehow,
please don't hesitate to contact him.


ad 3) Get the results from Open SCAP on whether the Windows machine is compliant

This requirement obviously needs to have Windows scanning implemented
first :-) as I mentioned above.

On Linux, it is possible to get the results either in machine-readable form
of XML documents or as a very nice detailed HTML report that user can display
in his web browser. If Windows will be supported in future, reporting should
work in the same way as on Linux.



[1] https://www.open-scap.org/security-policies/scap-security-guide/
[2] https://www.redhat.com/archives/open-scap-list/2017-February/msg1.html


I hope that I helped you a little and I'm looking forward to hear from you 
again.

Best regards

Jan Černý
Security Technologies | Red Hat, Inc.



- Original Message -
> From: "Bharath Mohanraj" 
> To: open-scap-list@redhat.com
> Sent: Wednesday, February 8, 2017 7:34:19 AM
> Subject: [Open-scap] Open SCAP for Windows
> 
> 
> 
> Hi Team,
> 
> 
> 
> I work for a client management product, and I see Open SCAP to be a promising
> solution for validating compliance of machines based on a defined policy.
> 
> 
> 
> I’m more interested in making use of Open SCAP in the product I work for, but
> however I need some assistance from you.
> 
> 
> 
> Please let me know if this can be achieved,
> 
> - Define a security policy (SCAP Content)
> 
> - Scan a Windows machine
> 
> - Get the results from Open SCAP on whether the Windows machine is compliant
> 
> 
> 
> Please let me know if this can be achieved.
> 
> 
> 
> Regards,
> 
> Bharath M
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] OpenScap Scanner on Windows

[Jan Cerny]

Hi,

I agree that it would be beneficial for OpenSCAP if we could scan containers
on Debian hosts as well.

Unfortunately, oscap-docker can run now only on RHEL7 and Fedora hosts,
because it depends on Project Atomic. Atomic handles mounting of container's
filesystem to the host's filesystem so that OpenSCAP can access the container.
AFAIK Atomic is not available on Debian.

However there is a kind of hack that enables to bypass it.
It should be possible to mount the filesystem of the container's image
to an arbitrary directory using the standard `mount` command and then use
the `oscap-chroot` utility that can scan arbitrary filesystems.

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Brandon Westover" 
> To: rspruden...@redhat.com, open-scap-list@redhat.com
> Sent: Thursday, February 16, 2017 4:24:18 PM
> Subject: Re: [Open-scap] OpenScap Scanner on Windows
> 
> Great!
> 
> I forgot to ask, but is there any support for oscap-docker under anything
> other than RHEL?
> https://www.open-scap.org/resources/documentation/security-compliance-of-rhel7-docker-containers/
> 
> I tried to search but couldn't really find anything, but was hoping that I
> could pull up Ubuntu or similar with Docker to scan containers/images.  I
> think we are using Debian in prod as our container host, so running the
> scans from that would be very beneficial.
> 
> Thanks in advance.
> 
> -Original Message-
> From: Raphael Sanchez Prudencio [mailto:rspruden...@redhat.com]
> Sent: Thursday, February 16, 2017 9:33 AM
> To: Westover, Brandon ;
> open-scap-list@redhat.com
> Subject: Re: [Open-scap] OpenScap Scanner on Windows
> 
> Hello Brandon,
> 
> We are starting some efforts to make it work properly on Windows, it will be
> probably tracked here
> https://github.com/OpenSCAP/openscap/projects/1
> 
> Kind Regads
> 
> On 02/15/2017 06:35 PM, Westover, Brandon wrote:
> > Are there any plans to have Openscap scanner on Windows?  I would
> > prefer a command line option for Windows versus the GUI Workbench app
> > as we're looking to automate this.
> > 
> >  
> > 
> > 
> > 
> > ___
> > Open-scap-list mailing list
> > Open-scap-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/open-scap-list
> > 
> 
> --
> Raphael Sanchez Prudencio
> Security Technologies | Red Hat, Inc.
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
> 

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Git clone build fails in autogen.sh

[Jan Cerny]

Hi,

That's a weird issue, I'm also using Fedora 24 and build works for me.

Please ensure that you have installed all the packages listed in the README.
The trick is to run this:
$ sudo dnf builddep openscap

Maybe the previous unsuccessful build has left your repository
in some sort of an inconsistent state. Try to clean everything using:
$ make clean
$ git clean -xf 
And then build it again following the instructions in README.

We use swig to generate Python bindings for the OpenSCAP library. Probably
you don't need them (unless you are a developer of the Anaconda project). :-)
You can disable the Python bindings using ./configure --disable-python 
--disable-python3

You might also want to check the Developer's section of OpenSCAP User's manual.
https://github.com/OpenSCAP/openscap/blob/maint-1.2/docs/manual/manual.adoc#devs

I hope this helps a little.

Best regards


Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Brooke Wallace" 
> To: open-scap-list@redhat.com
> Sent: Wednesday, February 15, 2017 9:57:48 PM
> Subject: Re: [Open-scap] Git clone build fails in autogen.sh
> 
> Ok, so I fixed that issue by installing libtool.
> 
> But now my build fails looking for SWIG and installing swig does not resolve
> the issue:
> 
> Making all in python2
> make[3]: Entering directory '/mypath/openscap/swig/python2'
> echo "Error: SWIG is not installed. You should look at http://www.swig.org"; ;
> false -o openscap_py_wrap.c -python -module openscap_py ./../src/openscap.i
> Error: SWIG is not installed. You should look at http://www.swig.org
> Makefile:1363: recipe for target 'openscap_py_wrap.c' failed
> make[3]: *** [openscap_py_wrap.c] Error 1
> make[3]: Leaving directory '/mypath/openscap/swig/python2'
> Makefile:995: recipe for target 'all-recursive' failed
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory '/mypath/openscap/openscap/swig'
> Makefile:1283: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/mypath/openscap/openscap'
> Makefile:1092: recipe for target 'all' failed
> make: *** [all] Error 2
> 
> $ sudo dnf install swig
> Last metadata expiration check: 0:03:18 ago on Wed Feb 15 12:47:37 2017.
> Package swig-3.0.8-7.fc24.x86_64 is already installed, skipping.
> Dependencies resolved.
> Nothing to do.
> Complete!
> 
> 
> From: Brooke Wallace
> Sent: Wednesday, February 15, 2017 11:43 AM
> To: open-scap-list@redhat.com
> Subject: Git clone build fails in autogen.sh
> 
> Hi,
> 
> I just pulled the latest git vresion of openscap from github and following
> the instructions I get the following error:
> 
> $ ./autogen.sh
> configure.ac:27: warning: macro 'AM_PROG_LIBTOOL' not found in library
> configure.ac:18: error: possibly undefined macro: AC_DISABLE_STATIC
> If this token and others are legitimate, please use m4_pattern_allow.
> See the Autoconf documentation.
> configure.ac:20: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
> configure.ac:27: error: possibly undefined macro: AM_PROG_LIBTOOL
> configure.ac:33: error: possibly undefined macro: AC_PROG_LIBTOOL
> autoreconf: /usr/bin/autoconf failed with exit status: 1
> 
> Not sure what this is refering to. Perhaps I need to install some packages?
> 
> My system is Fedora24:
> $ uname -a
> Linux myhost.mydomain.com 4.8.8-myuser #2 SMP Mon Nov 21 13:49:15 PST 2016
> x86_64 x86_64 x86_64 GNU/Linux
> 
> $ cat /etc/*release
> Fedora release 24 (Twenty Four)
> NAME=Fedora
> VERSION="24 (Workstation Edition)"
> ID=fedora
> VERSION_ID=24
> PRETTY_NAME="Fedora 24 (Workstation Edition)"
> ANSI_COLOR="0;34"
> CPE_NAME="cpe:/o:fedoraproject:fedora:24"
> HOME_URL="https://fedoraproject.org/";
> BUG_REPORT_URL="https://bugzilla.redhat.com/";
> REDHAT_BUGZILLA_PRODUCT="Fedora"
> REDHAT_BUGZILLA_PRODUCT_VERSION=24
> REDHAT_SUPPORT_PRODUCT="Fedora"
> REDHAT_SUPPORT_PRODUCT_VERSION=24
> PRIVACY_POLICY_URL=https://fedoraproject.org/wiki/Legal:PrivacyPolicy
> VARIANT="Workstation Edition"
> VARIANT_ID=workstation
> Fedora release 24 (Twenty Four)
> Fedora release 24 (Twenty Four)
> 
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Possible OpenSCAP bug

[Jan Cerny]

Hi Dragos,

Thank you very much for reporting this and sorry for the delay.

I had a look into your issue. Let me explain my findings.

According to OVAL 5.11.1 specification and XML schema,
recurse="none" is deprecated value and it was deprecated in OVAL 5.5.
In XML schema schemas/oval/5.11.1/unix-definitions-schema.xsd I found this:
The values 'files', 'files and directories',and 'none' are being removed 
because it is not possible to recurse files and the value 'none' was intended 
to mean no recursion, however, this is already covered by the recurse_direction 
attribute.

I think that you should not use that value.
Which version of OVAL is your content?
Do you think that we should support this deprecated value?


Thank you.

Best regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Dragos Prisaca" 
> To: open-scap-list@redhat.com
> Sent: Thursday, March 2, 2017 8:04:56 PM
> Subject: [Open-scap] Possible OpenSCAP bug
> 
> Hello,
> 
> It looks like OpenSCAP 1.2.10 does not process correctly the following
> object which uses @recurse="none":
>  xmlns:unix="http://oval.mitre.org/XMLSchema/oval-definitions-5#unix";
> comment="@recurse='none'" version="1">
>recurse="none" recurse_direction="down"/>
>datatype="string">/scapVal/File-Test-Level2/Level3-Folder010
>   .+
> 
> 
> Since there is a file
> (/scapVal/File-Test-Level2/Level3-Folder010/Level3-File010.txt), the
> expectation is to collect the following item:
> 
> 
> /scapVal/File-Test-Level2/Level3-Folder010/Level3-File010.txt
> /scapVal/File-Test-Level2/Level3-Folder010
> Level3-File010.txt
> regular
> ...
> 
> 
> Please let me know if you have any questions.
> 
> Respectfully,
> _Dragos.
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
> 

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Issues with the recurse_direction="up"

[Jan Cerny]

Hi,
Thank you for contacting me.
See my replies inline below.

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Dragos Prisaca" 
> To: open-scap-list@redhat.com
> Sent: Monday, March 6, 2017 10:00:40 PM
> Subject: [Open-scap] Issues with the recurse_direction="up"
> 
> Hello,
> 
> Here are few more issues related the file_test:
> 1. Incorrect item collected by OpenSCAP 1.2.10
> 
> Given the following object:
>  xmlns:unix="http://oval.mitre.org/XMLSchema/oval-definitions-5#unix";
> comment="@recurse='symlinks and directories'" version="1">
>  recurse_direction="down"/>
>  datatype="string">/scapVal/File-Test-Level2
> .+
> 
> and the following folder structure:
> 
>   /scapVal/File-Test-Level2
>   drwxr-xr-x. 2 root root  6 Feb 28 15:46 Level3-Folder020
>   drwxr-xr-x. 2 root root  6 Feb 28 15:46 Level3-Folder030
>   drwxr-xr-x. 2 root root  6 Feb 28 15:46 Level3-Folder050
>   drwxr-xr-x. 3 root root 54 Feb 28 15:46 Level3-Folder010
>   drwxr-xr-x. 3 root root 29 Feb 28 15:46 Level4-Folder011
>   -rw-r--r--. 1 root root 49 Feb 28 15:46 
> Level3-File010.txt
>   drwxr-xr-x. 2 root root 30 Feb 28 15:46 Level3-Folder040
> 
> OpenSCAP collects two items:
> 
> 
> /scapVal/File-Test-Level2/Level3-Folder010/Level3-File010.txt
> 
> /scapVal/File-Test-Level2/Level3-Folder010
> Level3-File010.txt
> regular …
> 
> 
> 
> 
> /scapVal/File-Test-Level2/Level3-Folder010/Level4-Folder011/Level5-Folder012
> 
> directory ...
> 
> I believe the item with id="14726416" was incorrectly collected because the
> obj:185 supposed to collect only files.

I am sorry, but I can't reproduce this issue, neither with openscap 1.2.10, nor
with latest 1.2.13. I created a similar directory structure and OVAL.
But it always collected only files for me.
I think I'm missing something. I would need the whole OVAL to be able to help 
you.
Is there any symlink in your structure?

> 
> 
> 2. A similar issue related to #1 it happens when the recurse_direction="up".
> Here is an example:
>  xmlns:unix="http://oval.mitre.org/XMLSchema/oval-definitions-5#unix";
> id="oval:nist.validation.macosFileTest:obj:181" comment="@recurse='symlinks
> and directories'" version="1">
>  recurse="symlinks and directories" recurse_direction="up"/>
> /scapVal/File-Test-Level2/Level3-Folder010
> .+
> 
> 
>  flag="complete">
> 
> 
> 
> 
> 
> 
> /scapVal/File-Test-Level2/Level3-Folder010/Level3-File010.txt
> /scapVal/File-Test-Level2/Level3-Folder010
> Level3-File010.txt
> regular
> 
> 
> 
> /scapVal/File-Test-Level2/Level3-Folder010/Level4-Folder011
> /scapVal/File-Test-Level2/Level3-Folder010
> Level4-Folder011
> directory
> 
> 
> 
> /scapVal/File-Test-Level2/Level3-Folder010
> /scapVal/File-Test-Level2
> Level3-Folder010
> directory
> 
> 
> Since the recurse_direction="up" and the file Level3-File010.txt is a
> 'child', it should not be collected. Also, the other 2 items corresponding
> to folders should not be collected because they are directories. In fact ,
> the obj:181 should have flag="does not exist".

I have noticed that you have set max_depth="0". In the OVAL specification,
UNIX Definitions Schema, I have found the following:
... 'max_depth' defines the maximum depth of recursion to perform when a 
recurse_direction
is specified. A value of '0' is equivalent to no recursion ...
Therefore I think no recursion should be performed, neither up nor down.
I think only the files and directories located directly in 
/scapVal/File-Test-Level2/Level3-Folder010
should be collected. Therefore I think OpenSCAP works correctly in this case.
Yeah, OVAL is tricky :D


> 
> 3. According to unix-system-characteristics-schema.html, when  xsi:nil="true" datatype="string"/>, the filename element of the file_item
> should be “”, but OpenSCAP creates:
> “”.

I agree that this is a bug and it seems to me as easy fix.


> 
> Please let me know if you have any questions.
> 
> Respectfully,
> _Dragos.
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] customizing remediation

[Jan Cerny]

Hello,

Thank you for contacting us.
There is a few things that you might have done incorrectly.

In SCAP Workbench, after you click on "Customize", you will be prompted
for a new profile ID, that will be the ID of your custom profile.
Check if you use the new ID, and not the ID of original profile, in your
commands. By default, it has "_customized" at the end. (It's possible
to change it.)

For scanning with customization, oscap needs path to original datastream,
a tailoring file, and new profile ID. The correct command to scan
would be for example this:

oscap xccdf eval --profile 
xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream_customized 
--tailoring-file ssg-rhel7-ds-tailoring.xml 
/usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml

(I have the tailoring file in current working directory).

For generating a customized fix script, again, oscap needs path to
original datastream, a tailoring file, and new profile ID.
This should work:

oscap xccdf generate fix --profile 
xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream_customized 
--tailoring-file ssg-rhel7-ds-tailoring.xml --output script.sh 
/usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml

Bash is default, so specifying --template is not needed. At least works for me 
with OpenSCAP 1.2.13.

I hope this helped you a little.

Best regards

Jan Černý
Security Technologies | Red Hat, Inc.





- Original Message -
> From: "Greg Silverman (CS)" 
> To: open-scap-list@redhat.com
> Sent: Thursday, March 16, 2017 10:15:36 PM
> Subject: [Open-scap] customizing remediation
> 
> 
> 
> I am missing something when it comes to generating a customized fix script.
> 
> 
> 
> 1. In SCAP Workbench I deselect rules I do not want.
> 
> 2. I save the customization file.
> 
> 3. When I scan with the customization file, it still reports evaluation
> results on * some * of the rules I deselected.
> 
> 4. When I create the remediation script, with oscap xccdf generate fix , it
> generates a fix for the rules mentioned in 3.
> 
> 
> 
> This is the command I run
> 
> 
> 
> oscap xccdf generate fix --template urn:xccdf:fix:script:sh --profile
> xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream --output
> my-remediation-script.sh
> /usr/share/xml/scap/ssg/content/ssg-rhel7-ds-tailoring.xml
> 
> 
> 
> i.e., using the tailored xccdf file.
> 
> 
> 
> What am I missing?
> 
> 
> 
> Thanks,
> 
> 
> 
> Greg Silverman
> 
> Veritas Technologies
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

[Open-scap] OpenSCAP 1.2.14

[Jan Cerny]

Hello OpenSCAPers,

We are thrilled to announce general availability of OpenSCAP 1.2.14 release.

This is the latest release from maint-1.2 maintenance branch. API/ABI is
fully compatible with 1.2.0 release. Users of 1.2.x releases are
recommended to update.

Changes:
  - New features
- Detailed information about ARF files in 'oscap info' (issue #664)
- XSLT template creating XCCDF files from OVAL files
- Generating remediation scripts from ARF
- Significant improvements of User Manual (issue #249, #513)
- HTML report UX improvements (issue #601, #620, #622, #655)
- Warnings are shown by default
- Verbose mode is available in 'xccdf remediate' module (issue #520)
- Added Fedora 26, Fedora 27 and OpenSUSE 42.2 CPEs (issue #698)
- Support for Anaconda remediation in HTML report
  - Maintenance
- Fixed CPE dictionary to identify RHEVH as RHEL7 (RHBZ #1420038)
- Fixed systemd probes crashes inside containers (RHBZ #1431186, issue #700)
- Added a warning on non-existing XCCDF Benchmarks (issue #614)
- Fixed output on terminals with white background (RHBZ #1365911, issue 
#512)
- Error handling in oscap-vm (RHBZ #1391754)
- Fixed SCE stderr stalling (RHBZ #1420811)
- Fixed Android OVAL schema (issue #279)
- Fixed absolute filepath parsing in OVAL (RHBZ #1312831, #1312824)
- Fixes based on Coverity scan report (issue #581, #634, #681)
- Fixed duplicated error messages (issue #707)
- Fixed XCCDF score calculation (issue #617)
- Fixed segmentation faults in RPM probes (RHBZ #1414303, #1414312)
- Fixed failing DataStream build if "@" is in filepath
- Fixed missing header in result-oriented Ansible remediations
- Memory leak and resource leak fixes (issue #635, #636)
- New upstream tests
- Many minor fixes and improvements

Download:
https://github.com/OpenSCAP/openscap/releases/download/1.2.14/openscap-1.2.14.tar.gz

SHA512:
0e408b2dd58b8b424a27f5c852c6dc8c596fdb201e45cc5f762a1998e00511040762df4e55cdfd93dac4c820c28935acdf3942e96227dfa4f4363d682a2da7da

Audit, Fix, And Be Merry!


Jan Černý
Security Technologies, Red Hat, Inc.
on behalf of OpenSCAP contributors

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] customizing generation of mediation scripts

[Jan Cerny]

Hi,

The bash code is taken from the input SCAP content,
eg. from /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml
there is no magic behind that, basically oscap simply extracts
snippets from XML.

If you want to amend the script that is generated by oscap, unfortunately
that is not possible, we don't have any option to customize the
"oscap xccdf generate fix" command. Only way is to edit the generated
script manually. 

The best thing that you could do is to share your bash code
with others, that means to propose a pull request on SCAP Security
Guide project. The source code repository can be found on
https://github.com/OpenSCAP/scap-security-guide
We can help you with that and we will be happy if you contribute.

I recommend exploring /shared/templates/static/bash
and /shared/templates directories in the SCAP Security Guide
source code repository.


Regards


Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Greg Silverman (CS)" 
> To: open-scap-list@redhat.com
> Cc: "DL-VTAS-AS-Team-Sangria" 
> Sent: Tuesday, March 21, 2017 7:17:36 PM
> Subject: [Open-scap] customizing generation of mediation scripts
> 
> 
> 
> I would like to modify the fixes that oscap will generate and add some
> automatic fixes. For example
> 
> 
> 
> 1. The firewall fix bash code does not add the ssh service to the drop zone.
> Which file can I modify so that the “add-services ssh” is included in the
> generated remediation script.
> 
> 2. Where can I add bash code to fix items that are not currently fixed? (I
> realize that some future release may replace changes I make now.)
> 
> 
> 
> 
> 
> Greg Silverman
> 
> Veritas Technologies
> 
> Mountain View, CA
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] “local machine” as a target is not enabled for Workbench on Windows 10

[Jan Cerny]

Hi,

Unfortunately, OpenSCAP can scan only Linux machines.
Windows support is currently not implemented.
The use-case for Workbench on Windows is only to scan remote
Linux servers from a user's Windows laptop.
Installing SSH server locally will not help.

You are not the first person asking for this.
Our developer Raphael Sanchez Prudencio already started to work
on Windows scanning, but that's a pretty large project.
Stay tuned :-)

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Thieyacine Ely Fall" 
> To: open-scap-list@redhat.com
> Sent: Wednesday, March 29, 2017 8:58:46 AM
> Subject: [Open-scap] “local machine” as a target is not enabled for Workbench 
> on Windows 10
> 
> 
> 
> Dear all,
> 
> 
> 
> I have downloaded openscap workbench on my Windows 10 Laptop machine (see
> below)
>   
> 
> 09:22:57
> 
> info
> 
> SCAP Workbench 1.1.4, compiled with Qt 4.8.6, using OpenSCAP 1.3.0
> 
> 
>   
> 
> 09:23:24
> 
> info
> 
> Opened file 'C:/Program Files (x86)/scap-workbench/ssg/ssg-jre-ds.xml'.
> 
> I would like to target my machine using jre or firefox checklist but the
> “local machine” as a target is not enabled.
> 
> Only remote SSH is enabled as a target.
> 
> 
> 
> Is an alternative is to install a SSH client and server on Windows 10 to make
> it work or do you have any other solutions ?
> 
> 
> 
> Thanks for your quick answer.
> 
> 
> 
> Best regards,
> 
> 
> 
> Dr. T. Fall
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] openscap 1.2.15 failed "make check" -> process58

[Jan Cerny]

Hi,

thank you for the report.
This test is not as deterministic as we want, perhaps we need to improve it 
again.
Usually, running it again will be successful.
But it's just a test, you can skip it if you need to install.
We will definitely get back into these issues.


Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Taofei Dong" 
> To: open-scap-list@redhat.com
> Sent: Thursday, March 23, 2017 6:17:45 PM
> Subject: [Open-scap] openscap 1.2.15 failed "make check" -> process58
> 
> 
> 
> Hi,
> 
> I downloaded it and follow the instructions to install in it redhat 7.3, but
> it is failed when I run “make Check”
> 
> 
> 
> Here are the information:
> 
> 
> 
> Making check in process58
> 
> make[3]: Entering directory `/opt/openscap/tests/probes/process58'
> 
> make check-TESTS
> 
> make[4]: Entering directory `/opt/openscap/tests/probes/process58'
> 
> make[5]: Entering directory `/opt/openscap/tests/probes/process58'
> 
> FAIL: all.sh
> 
> make[6]: Entering directory `/opt/openscap/tests/probes/process58'
> 
> make[6]: Nothing to be done for `all'.
> 
> make[6]: Leaving directory `/opt/openscap/tests/probes/process58'
> 
> 
> 
> Testsuite summary for openscap 1.2.15
> 
> 
> 
> # TOTAL: 1
> 
> # PASS: 0
> 
> # SKIP: 0
> 
> # XFAIL: 0
> 
> # FAIL: 1
> 
> # XPASS: 0
> 
> # ERROR: 0
> 
> 
> 
> See tests/probes/process58/test-suite.log
> 
> Please report to open-scap-list@redhat.com
> 
> 
> 
> make[5]: *** [test-suite.log] Error 1
> 
> make[5]: Leaving directory `/opt/openscap/tests/probes/process58'
> 
> make[4]: *** [check-TESTS] Error 2
> 
> make[4]: Leaving directory `/opt/openscap/tests/probes/process58'
> 
> make[3]: *** [check-am] Error 2
> 
> make[3]: Leaving directory `/opt/openscap/tests/probes/process58'
> 
> make[2]: *** [check-recursive] Error 1
> 
> make[2]: Leaving directory `/opt/openscap/tests/probes'
> 
> make[1]: *** [check-recursive] Error 1
> 
> make[1]: Leaving directory `/opt/openscap/tests'
> 
> make: *** [check-recursive] Error 1
> 
> 
> 
> 
> 
> 
> 
> openscap 1.2.15: tests/probes/process58/test-suite.log
> 
> 
> 
> 
> 
> # TOTAL: 1
> 
> # PASS: 0
> 
> # SKIP: 0
> 
> # XFAIL: 0
> 
> # FAIL: 1
> 
> # XPASS: 0
> 
> # ERROR: 0
> 
> 
> 
> .. contents:: :depth: 2
> 
> 
> 
> FAIL: all.sh
> 
> 
> 
> 
> 
> 
> 
> --
> 
> + Ensure that selinux_domain_label is collected [ FAIL ]
> 
> + Ensure that tty number is translated into name [ FAIL ]
> 
> + Ensure loguid returns unsigned int (cat /proc/ID/loginuid) [ FAIL ]
> 
> + Ensure sessionid is correct [ FAIL ]
> 
> + Ensure capabilities with OVAL 5.11 [ FAIL ]
> 
> + Ensure that command_line is collected [ FAIL ]
> 
> --
> 
> See tests/probes/process58/tests_probes_process88.log.
> 
> 
> 
> TEST: Ensure that selinux_domain_label is collected
> 
> result file: selinux_domain_label.out.ug0Blr
> 
> stderr file: selinux_domain_label.err.mu02U3
> 
> Collecting:
> 
> Collected: "oval:x:obj:1" : complete
> 
> OVAL System Characteristics are exported correctly.
> 
> RESULT: FAILED
> 
> 
> 
> TEST: Ensure that tty number is translated into name
> 
> result file: dev_to_tty.out.aX8FCJ
> 
> stderr file: dev_to_tty.err.Ukrrqt
> 
> Eval:
> 
> Definition oval:x:def:1: true
> 
> Evaluation done.
> 
> RESULT: FAILED
> 
> 
> 
> TEST: Ensure loguid returns unsigned int (cat /proc/ID/loginuid)
> 
> result file: loginuid.out.lShK8R
> 
> stderr file: loginuid.err.jp1eps
> 
> Eval:
> 
> Definition oval:x:def:1: true
> 
> Evaluation done.
> 
> RESULT: FAILED
> 
> 
> 
> TEST: Ensure sessionid is correct
> 
> result file: sessionid.out.GnuXZ8
> 
> stderr file: sessionid.err.iNg48L
> 
> Eval:
> 
> Definition oval:x:def:1: true
> 
> Evaluation done.
> 
> RESULT: FAILED
> 
> 
> 
> Details in attachment.
> 
> 
> 
> BR/Taofei
> 
> 
> 
> 
> 
> 
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] OSCAP-SCANNER on RHEL7

[Jan Cerny]

Hi,

Your command
# yum -y install openscap-scanner
should work, because OpenSCAP is a standard component of RHEL 7.

Check your software repositories configuration, eg. output of "yum repolist" 
command,
and /etc/yum.repos.d/ directory. Check if you are able to install
other packages.


Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Bharath Mohanraj" 
> To: open-scap-list@redhat.com
> Sent: Tuesday, April 4, 2017 8:41:28 PM
> Subject: [Open-scap] OSCAP-SCANNER on RHEL7
> 
> Hi Open SCAP Team,
> 
> Can someone help me know how OSCAP scanner can be used on a installed on a
> RHEL 7.
> 
> Any pointers or doc notes will really help.
> 
> I tried the below command, but no luck.
> 
> *
>  [root@vl-pun-mar-dv15 bin]# yum -y install openscap-scanner
> Loaded plugins: refresh-packagekit, rhnplugin
> This system is receiving updates from RHN Classic or RHN Satellite.
> Setting up Install Process
> No package openscap-scanner available.
> Error: Nothing to do
> *
> 
> 
> Regards,
> Bharath M
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
> 

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Using scap workbench to scan Debian on Beaglebone Black

[Jan Cerny]

Hi,

That is pretty cool that you want to run OpenSCAP on such a device.
I like it! You're the first person that I know running it on ARM :)

I think the problem is that Debian Jessie has OpenSCAP 1.0.9,
which is an old version that doesn't support systemd related tests
and it also can't process OVAL documents using OVAL standard 5.11,
which we use to write security policies. The error messages
look like that's the problem.

I suggest trying to backport OpenSCAP packages from Debian Testing (Stretch)
Debian Testing has OpenSCAP 1.2.9 that supports those new standards
and systemd.

Or you might try to compile the latest upstream release 1.2.14 directly from
the sources on Github [1] and install that on your device.

However I don't have an ARM machine with Debian, so I haven't verified
if there is any other issue :) If you encounter a problem,
please inform us. Thank you.


[1] 
https://github.com/OpenSCAP/openscap/releases/download/1.2.14/openscap-1.2.14.tar.gz


Best regards

Jan Černý
Security Technologies | Red Hat, Inc.




- Original Message -
> From: "Luther Goh Lu Feng" 
> To: open-scap-list@redhat.com
> Sent: Thursday, April 6, 2017 6:07:18 AM
> Subject: [Open-scap] Using scap workbench to scan Debian on Beaglebone Black
> 
> I have installed SCAP Workbench on Mac OS X[1] and attempted to scan a
> Beaglebone Black with Debian installed remotely. Debian has been installed
> with OpenSCAP[2]. However the scan threw up a lot of errors and didn't
> complete. I am only including a small subset of the errors so as not to
> overwhelm readers with the amount of text. But am happy to furnish the full
> logs in pastebin if it is helpful. Hope to have some tips. Thanks!
> 
> 
> 13:28:47
> info
> Connection established.
> 
> 
> 13:28:47
> info
> Checking if oscap is available on remote machine...
> 
> 
> 13:28:59
> info
> Querying capabilities on remote machine...
> 
> 
> 13:29:13
> info
> Copying input data to remote target...
> 
> 
> 13:30:32
> info
> Starting the remote process...
> 
> 
> 13:30:32
> info
> Processing on the remote machine...
> 
> 
> 13:30:47
> error
> The 'oscap' process has written the following content to stderr: OpenSCAP
> Error: File '/tmp/tmp.3WyW7Kt0Aa' line 1835: Element
> '{http://oval.mitre.org/XMLSchema/oval-definitions-5#linux}systemdunitdependency_test':
> This element is not expected.
> 
> 
> 13:30:47
> error
> The 'oscap' process has written the following content to stderr:
> [../../../src/XCCDF/xccdf_session.c:342]
> 
> 
> 13:30:47
> error
> The 'oscap' process has written the following content to stderr: File
> '/tmp/tmp.3WyW7Kt0Aa' line 2482: Element
> '{http://oval.mitre.org/XMLSchema/oval-definitions-5#linux}systemdunitdependency_object':
> This element is not expected.
> 
> 
> 13:30:47
> error
> The 'oscap' process has written the following content to stderr:
> [../../../src/XCCDF/xccdf_session.c:342]
> 
> 
> 13:30:47
> error
> The 'oscap' process has written the following content to stderr: File
> '/tmp/tmp.3WyW7Kt0Aa' line 3427: Element
> '{http://oval.mitre.org/XMLSchema/oval-definitions-5#linux}systemdunitdependency_state':
> This element is not expected.
> 
> 
> 13:30:47
> error
> The 'oscap' process has written the following content to stderr:
> [../../../src/XCCDF/xccdf_session.c:342]
> 
> 
> 13:30:47
> error
> The 'oscap' process has written the following content to stderr: File
> '/tmp/tmp.3WyW7Kt0Aa' line 3653: Element
> '{http://oval.mitre.org/XMLSchema/oval-definitions-5}glob_to_regex': This
> element is not expected. Expected is one of (
> {http://www.w3.org/2000/09/xmldsig#}Signature,
> {http://oval.mitre.org/XMLSchema/oval-definitions-5}object_component,
> {http://oval.mitre.org/XMLSchema/oval-definitions-5}variable_component,
> {http://oval.mitre.org/XMLSchema/oval-definitions-5}literal_component,
> {http://oval.mitre.org/XMLSchema/oval-definitions-5}arithmetic,
> {http://oval.mitre.org/XMLSchema/oval-definitions-5}begin,
> {http://oval.mitre.org/XMLSchema/oval-definitions-5}concat,
> {http://oval.mitre.org/XMLSchema/oval-definitions-5}end,
> {http://oval.mitre.org/XMLSchema/oval-definitions-5}escape_regex,
> {http://oval.mitre.org/XMLSchema/oval-definitions-5}split ).
> 
> 
> 
> 
> [1] https://www.open-scap.org/tools/scap-workbench/
> [2] https://packages.debian.org/jessie/python-openscap
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
> 

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Using scap workbench to scan Debian on Beaglebone Black

[Jan Cerny]

Hi,

ad 1) Does this successful run mean that OpenSCAP 1.0.9 supports OVAL 5.11
without issues?

No, it doesn't.

The file at https://www.debian.org/security/oval/oval-definitions-2014.xml
uses OVAL 5.3, that's an older version of the OVAL language standard. The
OVAL documents version is in  element,
located at the beginning of the file.

Last version supported by OpenSCAP 1.0.9 is OVAL 5.10.1. You can check that
by running: $ oscap --version . OVAL is a backward compatible language, so that
means all versions before 5.10.1 are supported as well.

On the other hand, OpenSCAP 1.2.9 supports OVAL version 5.11.1.
The difference between OVAL 5.10.x and 5.11.x is that 5.11 adds
systemd related stuff and offers new built-in macros, eg. glob_to_regex.
Most of the things remained the same, but unfortunately this new stuff
is widely used in security community, because almost every Linux distro
started using systemd.


ad 2) Is OpenSCAP cli on par functionality wise with SCAP workbench?

SCAP Workbench uses OpenSCAP cli under the hood. Workbench is just
a simple GUI on the top of OpenSCAP. That means scanning
either by Workbench or "oscap" cli will give you the same results.

In SCAP Workbench, you can customize the benchmarks to fit your needs
(click on Customize button). The cli tool can't create a new customization
file (that would be very awkward anyway), but it can process it.

At opposite, oscap cli tool has a lot of advanced command line options
and arguments that SCAP Workbench doesn't have, because
SCAP Workbench aims to be an easy-to-use application.


Hope that helps

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Luther Goh Lu Feng" 
> To: "Jan Cerny" 
> Sent: Thursday, April 6, 2017 4:20:17 PM
> Subject: Re: [Open-scap] Using scap workbench to scan Debian on Beaglebone 
> Black
> 
> Thanks for the suggestion! I will most certainly attempt to install  OpenSCAP
> 1.2.9 from testing.
> 
> I am still very much a noob figuring out my way around the various security
> concepts such as OVAL, XCCDF. So pardon me if I indicate any wrong
> assumptions as I have not fully yet read the manual.
> 
> 
> In my debugging, I have ran $ oscap oval eval --results debian-2014.xml
> --report debian-2014.html oval-definitions-2014.xml, and managed to get a
> proper report. The oval definitions are from debian[1].
> 
> So questions:
> 
> - Does this successful run mean that OpenSCAP 1.0.9 supports OVAL 5.11
> without issues?
> - Is OpenSCAP cli on par functionality wise with SCAP workbench?
> 
> 
> [1] https://www.debian.org/security/oval/
> 
> 
> 
> On Thursday, April 6, 2017 4:50 PM, Jan Cerny  wrote:
> 
> 
> 
> Hi,
> 
> That is pretty cool that you want to run OpenSCAP on such a device.
> I like it! You're the first person that I know running it on ARM :)
> 
> I think the problem is that Debian Jessie has OpenSCAP 1.0.9,
> which is an old version that doesn't support systemd related tests
> and it also can't process OVAL documents using OVAL standard 5.11,
> which we use to write security policies. The error messages
> look like that's the problem.
> 
> I suggest trying to backport OpenSCAP packages from Debian Testing (Stretch)
> Debian Testing has OpenSCAP 1.2.9 that supports those new standards
> and systemd.
> 
> Or you might try to compile the latest upstream release 1.2.14 directly from
> the sources on Github [1] and install that on your device.
> 
> However I don't have an ARM machine with Debian, so I haven't verified
> if there is any other issue :) If you encounter a problem,
> please inform us. Thank you.
> 
> 
> [1]
> https://github.com/OpenSCAP/openscap/releases/download/1.2.14/openscap-1.2.14.tar.gz
> 
> 
> Best regards
> 
> Jan Černý
> Security Technologies | Red Hat, Inc.
> 
> 
> 
> 
> 
> - Original Message -
> > From: "Luther Goh Lu Feng" 
> > To: open-scap-list@redhat.com
> > Sent: Thursday, April 6, 2017 6:07:18 AM
> > Subject: [Open-scap] Using scap workbench to scan Debian on Beaglebone
> > Black
> > 
> > I have installed SCAP Workbench on Mac OS X[1] and attempted to scan a
> > Beaglebone Black with Debian installed remotely. Debian has been installed
> > with OpenSCAP[2]. However the scan threw up a lot of errors and didn't
> > complete. I am only including a small subset of the errors so as not to
> > overwhelm readers with the amount of text. But am happy to furnish the full
> > logs in pastebin if it is helpful. Hope to have some tips. Thanks!
> > 
> > 
> > 13:28:47
> > info
> > Connection established.
> > 
> > 
> > 13

Re: [Open-scap] Using scap workbench to scan Debian on Beaglebone Black

[Jan Cerny]

-test_package_telnetd_removed:tst:1' has an unknown flag. This
> may indicate a bug in OpenSCAP.
> [../../../../src/OVAL/results/oval_resultTest.c:908]
> 
> 
> 01:59:46
> error
> The 'oscap' process has written the following content to stderr: Probe with
> PID=10516 has been killed with signal 11
> [../../../../../src/OVAL/probes/SEAP/sch_pipe.c:173]
> 
> 
> 01:59:46
> error
> The 'oscap' process has written the following content to stderr: Item
> corresponding to object
> 'oval:ssg-obj_package_inetutils-telnetd_removed:obj:1' from test
> 'oval:ssg-test_package_inetutils-telnetd_removed:tst:1' has an unknown flag.
> This may indicate a bug in OpenSCAP.
> [../../../../src/OVAL/results/oval_resultTest.c:908]
> 
> 
> 01:59:46
> error
> The 'oscap' process has written the following content to stderr: Probe with
> PID=10522 has been killed with signal 11
> [../../../../../src/OVAL/probes/SEAP/sch_pipe.c:173]
> 
> 
> 01:59:46
> error
> The 'oscap' process has written the following content to stderr: Item
> corresponding to object 'oval:ssg-obj_package_telnetd-ssl_removed:obj:1'
> from test 'oval:ssg-test_package_telnetd-ssl_removed:tst:1' has an unknown
> flag. This may indicate a bug in OpenSCAP.
> [../../../../src/OVAL/results/oval_resultTest.c:908]
> 
> 
> 01:59:46
> error
> The 'oscap' process has written the following content to stderr: Probe with
> PID=10528 has been killed with signal 11
> [../../../../../src/OVAL/probes/SEAP/sch_pipe.c:173]
> 
> 
> 01:59:46
> error
> The 'oscap' process has written the following content to stderr: Item
> corresponding to object 'oval:ssg-obj_package_nis_removed:obj:1' from test
> 'oval:ssg-test_package_nis_removed:tst:1' has an unknown flag. This may
> indicate a bug in OpenSCAP.
> [../../../../src/OVAL/results/oval_resultTest.c:908]
> 
> 
> 01:59:46
> error
> The 'oscap' process has written the following content to stderr: Probe with
> PID=10534 has been killed with signal 11
> [../../../../../src/OVAL/probes/SEAP/sch_pipe.c:173]
> 
> 
> 01:59:46
> error
> The 'oscap' process has written the following content to stderr: Item
> corresponding to object 'oval:ssg-obj_package_ntpdate_removed:obj:1' from
> test 'oval:ssg-test_package_ntpdate_removed:tst:1' has an unknown flag. This
> may indicate a bug in OpenSCAP.
> [../../../../src/OVAL/results/oval_resultTest.c:908]
> 
> 
> 01:59:46
> error
> The 'oscap' process has written the following content to stderr: Probe with
> PID=10540 has been killed with signal 11
> [../../../../../src/OVAL/probes/SEAP/sch_pipe.c:173]
> 
> 
> 01:59:46
> error
> The 'oscap' process has written the following content to stderr: Item
> corresponding to object 'oval:ssg-obj_package_ntp_installed:obj:1' from test
> 'oval:ssg-test_package_ntp_installed:tst:1' has an unknown flag. This may
> indicate a bug in OpenSCAP.
> [../../../../src/OVAL/results/oval_resultTest.c:908]
> 
> 
> 01:59:46
> error
> The 'oscap' process has written the following content to stderr: Probe with
> PID=10546 has been killed with signal 11
> [../../../../../src/OVAL/probes/SEAP/sch_pipe.c:173]
> 
> 
> 01:59:46
> error
> The 'oscap' process has written the following content to stderr: Item
> corresponding to object 'oval:ssg-obj_package_openssh-server_removed:obj:1'
> from test 'oval:ssg-test_package_openssh-server_removed:tst:1' has an
> unknown flag. This may indicate a bug in OpenSCAP.
> [../../../../src/OVAL/results/oval_resultTest.c:908]
> 
> 
> 02:00:09
> info
> Cleaning up...
> 
> 
> 02:00:47
> info
> Processing has been finished!
> 
> 
> 
> 
> 
> On Friday, April 7, 2017 2:02 AM, Luther Goh Lu Feng 
> wrote:
> 
> 
> 
> 
> 
> 
> On Thursday, April 6, 2017 10:20 PM, Luther Goh Lu Feng 
> wrote:
> 
> 
> 
> Thanks for the suggestion! I will most certainly attempt to install  OpenSCAP
> 1.2.9 from testing.
> 
> I am still very much a noob figuring out my way around the various security
> concepts such as OVAL, XCCDF. So pardon me if I indicate any wrong
> assumptions as I have not fully yet read the manual.
> 
> 
> In my debugging, I have ran $ oscap oval eval --results debian-2014.xml
> --report debian-2014.html oval-definitions-2014.xml, and managed to get a
> proper report. The oval definitions are from debian[1].
> 
> So questions:
> 
> - Does this successful run mean that OpenSCAP 1.0.9 supports OVA

Re: [Open-scap] Tuning/Customisation of SSG OVAL

[Jan Cerny]

Hi,

Some of the rules in SCAP Security guide can be parametrized using "XCCDF 
Value".
Those values can be set in SCAP Workbench. However that's not the case of this
particular rule, the value is hard-coded in regular expressions across the
file. We use parametrized values for example in rules that specify minimal
length of a password etc.

The fastest way would be to replace the auid in OVAL file manually.
Better way would be to rework the rules so that they're parametrized using
XCCDF Values.

Best regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Sébastien Barbereau" 
> To: open-scap-list@redhat.com
> Sent: Thursday, April 13, 2017 11:30:40 AM
> Subject: [Open-scap] Tuning/Customisation of SSG OVAL
> 
> Hi
> due to some of our systems setup I am looking for a way to tune some of the
> SSG OVAL tests but i'm not sure what is the best approach.
> 
> For example: the test
> xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_chmod checks
> whether auid >= 1000 this is good but our system implementation puts the
> configuration settings at auid>=512. This results in the test failing while
> the system is in fact compliant. I could of course just skip the test, but
> that would miss the point. Alterntively I though of forking a personal
> version of the ssg oval file with the settings matching my needs. Is there
> another more subtle alternative?
> 
> tx
> 
> 
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

[Open-scap] Dockerfiles for OpenSCAP container

[Jan Cerny]

Hi,

I would like to move the discussion about Dockerfiles for OpenSCAP container
from GitHub [1] to the mailing list, because I'm interested in solving that
topic.

Nowadays, OpenSCAP Deamon upstream repository contains multiple Dockerfiles
in this repository to build various container images with OpenSCAP. There are
Dockerfiles to build either from packages [2] or from latest upstream code [3].

The problem is that the Dockerfiles are outdated.  They used to be to 
demonstrate
"atomic scan", but now we ship an image called "openscap" in Red Hat Registry.
Moreover, upstream dockerfiles are very different from what is used to build
image registry.access.redhat.com/rhel7/openscap. Also there is a lot of 
duplication
in the repository, because the multiple variants are almost the same.

Firstly, I think that for testing and development it would be beneficial to have
a Dockerfile that will enable upstream community to build an image that is very 
similar
to registry.access.redhat.com/rhel7/openscap, but with fresh OpenSCAP daemon 
from upstream git.

Also, the new Dockerfile and other files can be used as a template for 
downstream
container builds.

There are multiple solutions:

* Keep the current directory structure in atomic and atomic-git.
  Update all current Dockerfiles, add all the files. However I'm afraid that
  there will be a lot of duplicates.

* Remove the atomic and atomic-git. Make a new directory, that would contain 
Dockerfile
  and other files. We can reuse the files that are now used for our container 
image
  in Red Hat Registry.

* Make a script that creates a Dockerfile and all the required files and builds
  the image. It could be parametrizable, so the user could choose base image,
  versions of packages (usptream/distro), developer's branches, etc.

I use now this workflow:
I have a Dockerfile on my laptop, I have a script that creates an image
(based on Fedora) with fresh upstream OpenSCAP Daemon. The image is
tagged  as 'openscap:testing'. Then I just configure the image name in
'/etc/atomic.d/openscap' and Atomic uses it instead of
registry.access.redhat.com/rhel7/openscap automatically. This seems to me
really easy and works OK so far.

Are we interested to include something like that into upstream?

What are your opinions on our upstream Dockerfiles? [2] [3]

Regards



[1] https://github.com/OpenSCAP/openscap-daemon/issues/102
[2] https://github.com/OpenSCAP/openscap-daemon/tree/master/atomic
[3] https://github.com/OpenSCAP/openscap-daemon/tree/master/atomic-git


Jan Černý
Security Technologies | Red Hat, Inc.


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] what profile to use in RHEL7

[Jan Cerny]

Actually, Marek Haicman can see the future:
https://github.com/OpenSCAP/openscap/issues/685
I just make the future happen :-)




Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Shawn Wells" 
> To: "Martin Preisler" 
> Cc: open-scap-list@redhat.com
> Sent: Wednesday, July 19, 2017 12:57:11 AM
> Subject: Re: [Open-scap] what profile to use in RHEL7
> 
> 
> 
> On 7/18/17 2:28 PM, Martin Preisler wrote:
> > On Tue, Jul 18, 2017 at 1:34 PM, Shawn Wells  wrote:
> >>
> >> On 7/18/17 1:09 PM, Martin Preisler wrote:
> >>
> >> On Mon, Jul 17, 2017 at 6:44 PM, Smith, Cathy 
> >> wrote:
> >>
> >> Folks
> >>
> >> I’m trying to build a customized profile for RHEL7.   I’m not sure about
> >> the
> >> list of profile names offered through the oscap command and the list shown
> >> in the SCAP Workbench.  For example, in RHEL6 the oscap command listed a
> >> profile usgcb-rhel6-server, and that corresponded to the United States
> >> Government Configuration Baseline (USGCB) in SCAP Workbench.  The RHEL 7
> >> SCAP Workbench has a profile for USGCB, but there is no profile listed by
> >> that name by the oscap info command.  Does anyone know of a list that
> >> shows
> >> the relationship between the profile listed by the oscap command and the
> >> profiles in the SCAP Workbench?
> >>
> >> Thank you for your assistance.
> >>
> >> The IDs and titles don't always match. This is exactly the case with
> >> the USGCB / OSPP profile for RHEL7. Its title is "United States
> >> Government Configuration Baseline (USGCB / STIG)" but its ID is
> >> xccdf_org.ssgproject.content_profile_ospp-rhel7.
> >>
> >> I usually go to https://static.open-scap.org to figure this out. Click
> >> on the product, then browse profiles. The page will always tell you
> >> both title and ID of each.
> >>
> >> Hope this helps!
> >>
> >>
> >>
> >> As a future OpenSCAP RFE, could the 'oscap info' output be modified to
> >> show
> >> the profile title? e.g.
> >>
> >> Title: United States Baseline
> >> XCCDF ID: org.open-scap-ospp-rhel7
> > I think Jan Cerny can see the future:
> > https://github.com/OpenSCAP/openscap/pull/781
> 
> Hah! Nice, Jan :)
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] OpenSCAP Daemon Status

[Jan Cerny]

Hi Jordan,

OpenSCAP Daemon is an active project. I don't think it will be deprecated.

Right now, its main purpose is to integrate OpenSCAP with Project Atomic
to provide "atomic scan" feature. But it can do more: continuous compliance
of bare-metal machines, VMs, containers.

The official RPM is in Red Hat Enterprise Linux Atomic Host.

We also ship it inside a container image:
registry.access.redhat.com/openscap.

Documentation is bad. We need to improve it. I think README is everything
we have.

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Jordan Caraballo" 
> To: open-scap-list@redhat.com
> Sent: Tuesday, July 18, 2017 9:49:53 PM
> Subject: [Open-scap] OpenSCAP Daemon Status
> 
> 
> 
> Hi guys,
> 
> We are really curious about what is the status of OpenSCAP Daemon (
> https://github.com/OpenSCAP/openscap-daemon ). I saw that the last commit
> was yesterday but I have not seen the same activity than before.
> 
> 
> Is this a project that will be deprecated through time? Are there any future
> plans?
> 
> Is there going to be a formal rpm release for rhel or centos? Is there
> documentation outside the readme from git?
> 
> I am interested in using it but I have not seen enough documentation to
> actually get my hands in.
> 
> Thanks in advance,
> 
> 
> - Jordan
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] OpenSCAP support to Solaris and FreeBSD

[Jan Cerny]

Hi,

1) FreeBSD - They use a specific format, called VuXML.
We don't have support for that now. That would require to
implement parsing, evaluating and reporting in VuXML format
and also a probe to scan FreeBSD Ports. That wouldn't be a small task.

2) Solaris - I'm afraid that link you provided doesn't contain data
for Solaris, but it's for Oracle Linux, which is a RHEL derivative.
I don't know if they provide same thing for Solaris. If the Solaris
data exist, and they're in OVAL format as well, we would need
to implement a probe for Solaris packaging system. We don't
have any Solaris probes now.

I don't expect we in Red Hat will work on support for FreeBSD or Solaris.
But we are willing to help people that want to contribute.

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Jordan Caraballo" 
> To: sh...@redhat.com
> Cc: open-scap-list@redhat.com
> Sent: Wednesday, July 19, 2017 7:39:48 PM
> Subject: Re: [Open-scap] OpenSCAP support to Solaris and FreeBSD
> 
> 
> 
> Hi Shawn,
> 
> Thanks for your reply! I will start digging into them to see if I can start
> developing some patches.
> 
> I apologize if these are naive questions:
> 
> - CIS has some pdf benchmark files for FreeBSD. Is this a good start for
> recreating the rules to assess the system?
> 
> 
> - On the other hand, there are vulnerabilities files available for FreeBSD
> https://svn.freebsd.org/ports/head/security/vuxml/vuln.xml and Solaris
> http://linux.oracle.com/security/oval/com.oracle.elsa-all.xml.bz2 . What we
> would need is openscap and openscap-utils working on both OS's?
> 
> 
> - Jordan
> On 7/19/17 1:25 PM, Shawn Wells wrote:
> 
> 
> 
> On 7/19/17 12:41 PM, Jordan Caraballo wrote:
> 
> 
> 
> Hi guys,
> 
> Are there any future or ongoing plans to support Solaris and FreeBSD
> operating systems?
> 
> Both to run OpenSCAP and to have compliance files from the
> SCAP-Security-Guide.
> There were 1-2 people from Oracle interested in porting OpenSCAP to
> Solaris. Not sure what happened to that interest. Nobody has mentioned
> FreeBSD before (that I know about).
> 
> On the SSG side, there's no specific effort. Patches welcome if you'd be
> interested in this.
> 
> ___
> Open-scap-list mailing list Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
> 
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

[Open-scap] OpenSCAP Daemon 0.1.7

[Jan Cerny]

Hello OpenSCAPers,

We are thrilled to announce general availability of OpenSCAP Daemon 0.1.7 
release.

Everybody is encouraged to update.

Changes:

- New features:
  -  Scanning of any XCCDF profile in oscapd-evaluate
  -  Detecting XCCDF profiles applicable to a given target
  -  Generating remediation scripts based on scan results
  -  Shortened profile IDs are accepted
- Maintenance:
  -  Several exceptions are caught
  -  Fixed JSON output
  -  Better error messages


Download:
https://github.com/OpenSCAP/openscap-daemon/releases/download/0.1.7/openscap_daemon-0.1.7.tar.gz

SHA512:
e410dc16d288335874a0f678d494dfb22d3cee6050fb9514950cbc26a9d751f012c43f40ea78d6f629f2f22be66206c5b5d5fc351274a16ad927216f0cd713e2

Audit, Fix, And Be Merry!


Jan Černý
Security Technologies, Red Hat, Inc.
on behalf of OpenSCAP Daemon contributors

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

[Open-scap] OpenSCAP 1.2.15

[Jan Cerny]

Hello OpenSCAPers,

We are thrilled to announce general availability of OpenSCAP 1.2.15 release.

This is the latest release from maint-1.2 maintenance branch. API/ABI is
fully compatible with 1.2.0 release. Users of 1.2.x releases are
recommended to update.

Changes:
  - New features
- short profile names can be used instead of long IDs
- new option --rule allows to evaluate only a single rule
- new option --fix-type in "oscap xccdf generate fix" allows choosing
  remediation script type without typing long URL
- "oscap info" shows profile titles
- OVAL details in HTML report are easier to read
- HTML report is smaller because unselected rules are removed
- HTML report supports NIST 800-171 and CJIS
- remediation scripts contain headers with useful information
- remediation scripts report progress when they run
- basic support for Oracle Linux (CPEs, runlevels)
- remediation scripts can be generated from datastreams that contain
  multiple XCCDF benchmarks (issue #772)
- basic support for OVAL 5.11.2 (only schemas, no features)
- enabled offline RPM database in rpminfo probe (issue #778)
- added Fedora 28 CPE
  - Maintenance
- fixed oscap-docker with Docker >= 2.0 (issue #794)
- fixed behavior of sysctl probe to be consistent with sysctl tool
- fixed generating remediation scripts (issue #723, #773)
- severity of tailored rules is not discarded (issue #739)
- fixed errors in RPM probes initialization
- oscap-docker shows all warnings reported by oscap (issue #713)
- small improvements in verbose mode
- standard C operations are used instead of custom OpenSCAP operations
- fixed compiler warnings
- fixed missing header files
- fixed resource leaks (issue #715)
- fixed pkgconfig file (RHBZ #1414777)
- refactoring
- documentation fixes and improvements

Special thanks to our new contributors Brady Alleman, Evgeni Golov, Ilya Okomin,
John Whipple, Katarina Jankov, Matúš Marhefka, Wesley Ceraso Prudencio
and Xiang Zhai.

Download:
https://github.com/OpenSCAP/openscap/releases/download/1.2.15/openscap-1.2.15.tar.gz

SHA512:
c4ba1150a19464b3deaede837d82e6da700d95ef9dcf1f6105158e9df7b7d6397825270124247dc03b94e2bac3ad1cc4ba6944422b217b4b29d376b6911ab612

Audit, Fix, And Be Merry!


Jan Černý
Security Technologies, Red Hat, Inc.
on behalf of OpenSCAP contributors

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] fix process58 for Ubuntu

[Jan Cerny]

Hi,

Thanks for the patch. I have included it in upstream.
https://github.com/OpenSCAP/openscap/commit/0844e5fa6fb6624882b50e6915ecb3393559b4cc

I tried to reproduce this yesterday, but I wasn't successful.
Do I understand it well that this happens only if SELinux is
not in use?

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Bruno Ducrot" 
> To: "Petr Lautrbach" 
> Cc: open-scap-list@redhat.com
> Sent: Thursday, September 7, 2017 7:47:56 PM
> Subject: Re: [Open-scap] fix process58 for Ubuntu
> 
> On Thu, Sep 07, 2017 at 12:01:34PM +0200, Petr Lautrbach wrote:
> > On Tue, Sep 05, 2017 at 04:05:50PM +0200, Bruno Ducrot wrote:
> > > Hi there,
> > > 
> > > Compiling OpenSCAP 1.2.15 under a Ubuntu Xenial.  The probe for
> > > process58 will segfault.  A possible fix for that could be :
> > 
> > Could you share a backtrace from the segfaulted probe?
> 
> (gdb) bt
> #0  0x7f15bf57f000 in ?? ()
> #1  0x0040616a in get_selinux_label (pid=1) at unix/process58.c:251
> #2  read_process (cmd_ent=cmd_ent@entry=0x7f15a8000b50,
> pid_ent=pid_ent@entry=0x7f15a8000960, ctx=ctx@entry=0x7f15afffed50) at
> unix/process58.c:601
> #3  0x0040676e in probe_main (ctx=ctx@entry=0x7f15afffed50,
> arg=) at unix/process58.c:640
> #4  0x0040a120 in probe_worker (probe=0x7fff958bdd90,
> msg_in=, ret=0x7f15afffedd4) at worker.c:952
> #5  0x00409c47 in probe_worker_runfn (arg=0x7f15bdf0) at
> worker.c:56
> #6  0x7f15bebd86ba in ?? ()
> #7  0x in ?? ()
> 
> 
> > The problem with this patch is that it changes the meaning of the return
> > value. The original code returned only SELinux type associated to a
> > process, e.g.  init_t, while with this change it would be the whole
> > SELinux context, e.g. system_u:system_r:init_t:s0. See
> > https://github.com/OpenSCAP/openscap/commit/4f3d1718f
> 
> Well. Under Ubuntu, the security context happens
> > 
> > > The real problem is, I think, with an API change in libselinux.
> > > I don't know however how to fix that in a way that could be merged
> > > mainstream.
> > 
> > I don't think there was an API change related to getpidcon(),
> > context_new() or context_type_get() in libselinux recently.
> > 
> > The problem seems to be in missing check of return values of these
> > functions.
> > 
> 
> I see.  I had mistaken myself indeed.
> 
> Well, continuing with gdb :
> 
> (gdb) frame 1
> #1  0x0040616a in get_selinux_label (pid=1) at
> unix/process58.c:251
> 251   selinux_label = strdup(context_type_get(context));
> (gdb) print context
> $1 = (context_t) 0x0
> 
> Ah, context is NULL.
> 
> The patch below fix the segfault.
> 
> --- openscap-1.2.15/src/OVAL/probes/unix/process58.c  2017/09/07 17:19:46 
> 1.1
> +++ openscap-1.2.15/src/OVAL/probes/unix/process58.c  2017/09/07 17:43:47
> @@ -248,6 +248,10 @@
>   return NULL;
>   }
>   context = context_new(pid_context);
> + if (context == NULL) {
> + /* Another LSM is in use */
> + return NULL;
> + }
>   selinux_label = strdup(context_type_get(context));
>   context_free(context);
>   freecon(pid_context);
> 
> Cheers,
> 
> --
> Bruno Ducrot
> 
> -- Which is worse: ignorance or apathy?
> -- Don't know.  Don't care.
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
> 

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Implementation for an AppArmor probe.

[Jan Cerny]

Hi Bruno,

this is awesome.

However, as Bill pointed out, AppArmor support was added to OVAL standard
in version 5.11.2.

If you remove the schema changes of 5.11.0 it would be better.
We already have 5.11.2 schemas in the repository, so it should be enough
to change the version in your OVAL files.
I think we shouldn't add any custom extensions to the schemas in schemas/oval
directory in OpenSCAP repository. One of the use-cases of oscap is to
verify whether the content complies with OVAL standard, which would be
broken with the patch :-)

Also, since AppArmor probe is in Linux namespace, I don't see a need to
create any new options in ./configure. The probes aren't Red Hat specific.
For example we have DPKG info probe, which is used only on Ubuntu and Debian,
and we don't have a special option for that. It just doesn't compile the probe
binary on RHEL/Fedora. I think AppArmor probe is a similar case.

Overall, I think that there is a very high chance to include the probe to 
upstream. 
I'm looking forward to your contributions.

Regards

Jan Černý
Security Technologies | Red Hat, Inc.




- Original Message -
> From: "William Munyan" 
> To: "Bruno Ducrot" , open-scap-list@redhat.com
> Sent: Monday, September 11, 2017 2:59:10 PM
> Subject: Re: [Open-scap] Implementation for an AppArmor probe.
> 
> 
> 
> Bruno,
> 
> Support for the apparmor test construct was put into the mainstream Linux
> schema as of the OVAL 5.11.2 release. The 5.11.2 schemas can be found here -
> https://github.com/OVALProject/Language/tree/master/schemas
> 
> 
> 
> As for sample content that wouldn’t necessarily be under the scrutiny of a
> CIS membership or bundles with CIS-CAT, I can probably find you some.
> 
> 
> 
> Cheers,
> 
> -Bill M.
> 
> 
> 
> 
> 
> Bill Munyan
> 
> Technical Product Executive; Security Controls & Automation
> 
> 31 Tech Valley Drive
> 
> East Greenbush, NY 12061
> 
> 
> 
> william.mun...@cisecurity.org
> 
> 518 880-0690
> 
> 518 466-1160 (cell)
> 
> 
> 
> 
> 
> 
> 
> 
> From: open-scap-list-boun...@redhat.com
> [mailto:open-scap-list-boun...@redhat.com] On Behalf Of Bruno Ducrot
> Sent: Monday, September 11, 2017 8:49 AM
> To: open-scap-list@redhat.com
> Subject: [Open-scap] Implementation for an AppArmor probe.
> 
> 
> 
> 
> 
> 
> 
> Hi,
> 
> I'm currently working on a probe for AppArmor, which, I think, could be
> usefull for Ubuntu and Suse systems. The patch can be found here :
> 
> http://poupinou.org/SCAP/openscap-apparmor-1.2.15.diff
> 
> It's actually the same kind of probe (the suse:apparmorstatus thing) that
> can be found in CIS-CAT.
> 
> I think the only stuff that need to be done is to implement some unit
> tests stuff. Ah, and only OVAL 5.11 for now.
> 
> 
> I do have some concerns though :
> 
> 1- I have to provide a file found in CIS-CAT for the OVAL schema.
> 
> I think it's ok, though, since the header contains :
> xmlns:suse=" http://oval.mitre.org/XMLSchema/oval-definitions-5#suse "
> 
> I'm not sure however that I do have the right for redistributing this
> schema.
> 
> 2- This also introduce another NS, namely 'suse'. I think it's
> overkill somewhat, and, IMHO, this should go under linux.
> 
> 3- Lastly, I'm wondering if there will be a chance this probe will go
> mainstream.
> 
> 
> Cheers,
> 
> --
> Bruno Ducrot
> 
> -- Which is worse: ignorance or apathy?
> -- Don't know. Don't care.
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
> 
> .
> This message and attachments may contain confidential information. If it
> appears that this message was sent to you by mistake, any retention,
> dissemination, distribution or copying of this message and attachments is
> strictly prohibited. Please notify the sender immediately and permanently
> delete the message and any attachments.
> 
> . . . . .
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Implementation for an AppArmor probe.

[Jan Cerny]

Hi,

The new patch looks great. I'll review and test. I'll let you know.

Thanks

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Bruno Ducrot" 
> To: "Jan Cerny" 
> Cc: open-scap-list@redhat.com, "William Munyan" 
> 
> Sent: Monday, September 11, 2017 6:18:59 PM
> Subject: Re: [Open-scap] Implementation for an AppArmor probe.
> 
> Hi Jan,
> 
> On Mon, Sep 11, 2017 at 09:44:40AM -0400, Jan Cerny wrote:
> > Hi Bruno,
> > 
> > this is awesome.
> > 
> > However, as Bill pointed out, AppArmor support was added to OVAL standard
> > in version 5.11.2.
> 
> Indeed.
> 
> > 
> > If you remove the schema changes of 5.11.0 it would be better.
> > We already have 5.11.2 schemas in the repository, so it should be enough
> > to change the version in your OVAL files.
> > I think we shouldn't add any custom extensions to the schemas in
> > schemas/oval
> > directory in OpenSCAP repository. One of the use-cases of oscap is to
> > verify whether the content complies with OVAL standard, which would be
> > broken with the patch :-)
> > 
> > Also, since AppArmor probe is in Linux namespace, I don't see a need to
> > create any new options in ./configure. The probes aren't Red Hat specific.
> > For example we have DPKG info probe, which is used only on Ubuntu and
> > Debian,
> > and we don't have a special option for that. It just doesn't compile the
> > probe
> > binary on RHEL/Fedora. I think AppArmor probe is a similar case.
> 
> Ok.  But there is no real library dependancies, so it will be
> compiled under systems without AppArmor.
> 
> The next iteration can be found here :
> http://poupinou.org/SCAP/openscap-apparmor-20170911.diff
> 
> That one is against current git, instead of 1.2.15.  I'm planing to clone the
> openscap
> git, just in case I'll have to do more stuff.
> 
> There is still the unit tests to be written though.  I hope doing so
> this week, but I'm a bit busy atm.
> 
> > 
> > Overall, I think that there is a very high chance to include the probe to
> > upstream.
> > I'm looking forward to your contributions.
> 
> Thanks !
> 
> 
> --
> Bruno Ducrot
> 
> -- Which is worse: ignorance or apathy?
> -- Don't know.  Don't care.
> 

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Implementation for an AppArmor probe.

[Jan Cerny]

Hi,

I have reviewed your patch.  I have tested it on my Ubuntu Server 16.04.3, and 
it works great.

The patch overall looks good, but I have a few minor findings:

src/OVAL/probes/unix/linux/apparmorstatus.c :
* It shouldn't fail hard if you don't run it as root. In general OpenSCAP 
doesn't terminate
  just because it couldn't get some data. I suggest `return 0` on line 362.
* Please use `snprintf` instead of `sprintf`. It's safer.
* On line 320, SEXP_free(item) shouldn't be commented out. But please make sure
  everything is freed properly then.
* Please don't mix spaces and tabs. Tabs should be used to indent everywhere in 
C code.
* On line 200 you close a file that was already closed on line 177.
* I guess that the sizeof operator on line 273 should take "struct aa_profile".
* Compiler reports some warnings:
```
unix/linux/apparmorstatus.c: In function ‘probe_main’:
unix/linux/apparmorstatus.c:330:24: warning: variable ‘over’ set but not used 
[-Wunused-but-set-variable]
  oval_schema_version_t over;
^
unix/linux/apparmorstatus.c: In function ‘aa_isenabled’:
unix/linux/apparmorstatus.c:90:2: warning: ignoring return value of ‘read’, 
declared with attribute warn_unused_result [-Wunused-result]
  (void) read(fd, &status, 1);
```


Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Jan Cerny" 
> To: "Bruno Ducrot" 
> Cc: open-scap-list@redhat.com
> Sent: Friday, September 15, 2017 10:26:28 AM
> Subject: Re: [Open-scap] Implementation for an AppArmor probe.
> 
> Hi,
> 
> The new patch looks great. I'll review and test. I'll let you know.
> 
> Thanks
> 
> Regards
> 
> Jan Černý
> Security Technologies | Red Hat, Inc.
> 
> - Original Message -
> > From: "Bruno Ducrot" 
> > To: "Jan Cerny" 
> > Cc: open-scap-list@redhat.com, "William Munyan"
> > 
> > Sent: Monday, September 11, 2017 6:18:59 PM
> > Subject: Re: [Open-scap] Implementation for an AppArmor probe.
> > 
> > Hi Jan,
> > 
> > On Mon, Sep 11, 2017 at 09:44:40AM -0400, Jan Cerny wrote:
> > > Hi Bruno,
> > > 
> > > this is awesome.
> > > 
> > > However, as Bill pointed out, AppArmor support was added to OVAL standard
> > > in version 5.11.2.
> > 
> > Indeed.
> > 
> > > 
> > > If you remove the schema changes of 5.11.0 it would be better.
> > > We already have 5.11.2 schemas in the repository, so it should be enough
> > > to change the version in your OVAL files.
> > > I think we shouldn't add any custom extensions to the schemas in
> > > schemas/oval
> > > directory in OpenSCAP repository. One of the use-cases of oscap is to
> > > verify whether the content complies with OVAL standard, which would be
> > > broken with the patch :-)
> > > 
> > > Also, since AppArmor probe is in Linux namespace, I don't see a need to
> > > create any new options in ./configure. The probes aren't Red Hat
> > > specific.
> > > For example we have DPKG info probe, which is used only on Ubuntu and
> > > Debian,
> > > and we don't have a special option for that. It just doesn't compile the
> > > probe
> > > binary on RHEL/Fedora. I think AppArmor probe is a similar case.
> > 
> > Ok.  But there is no real library dependancies, so it will be
> > compiled under systems without AppArmor.
> > 
> > The next iteration can be found here :
> > http://poupinou.org/SCAP/openscap-apparmor-20170911.diff
> > 
> > That one is against current git, instead of 1.2.15.  I'm planing to clone
> > the
> > openscap
> > git, just in case I'll have to do more stuff.
> > 
> > There is still the unit tests to be written though.  I hope doing so
> > this week, but I'm a bit busy atm.
> > 
> > > 
> > > Overall, I think that there is a very high chance to include the probe to
> > > upstream.
> > > I'm looking forward to your contributions.
> > 
> > Thanks !
> > 
> > 
> > --
> > Bruno Ducrot
> > 
> > -- Which is worse: ignorance or apathy?
> > -- Don't know.  Don't care.
> > 
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] SCE not able to find sh script

[Jan Cerny]

Hi,

The datastream you mentioned looks like it references another file. But in 
fact, this
is a reference to another part of the datastream, 'extended-component'. There 
can be
multiple reasons for this issue. Could you check you can write to /tmp? Could
you run the command with --verbose INFO ?

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Šimon Lukašík" 
> To: "Krishna Mannem" , open-scap-list@redhat.com
> Sent: Thursday, November 9, 2017 11:13:19 AM
> Subject: Re: [Open-scap] SCE not able to find sh script
> 
> On 10/24/2017 11:38 PM, Krishna Mannem wrote:
> > Hi,
> > 
> > We have built openscap for ubuntu 14.04 with --enable-sce. We are trying
> > to run a sample test where oscap can check using a bash script. We tried
> > to run one of the test files from the openscap repo
> > https://github.com/OpenSCAP/openscap/blob/3f74bdc3c133e44bff6eb154731ca771b3e8e8e2/tests/sce/test_sce_in_ds.xml
> > 
> > We are encountering this error:
> > SCE couldn't find script file
> > 'services/obsolete/disable_nfs_exports.sh'. Expected location:
> > '/tmp/oscap.rOXJ8X/xccdf.xml/services/obsolete/disable_nfs_exports.sh'.
> > [sce_engine.c:368]
> > 
> > Why is it trying to look in a tmp dir? Under the Usage section on
> > https://www.open-scap.org/features/other-standards/sce/ it states that
> > oscap will look relative for the script relative to the xccdf file or
> > from an absolute path but we tried both with no luck.
> > 
> > 
> 
> Hiya,
> 
> The documentation you cite is correct for the low-level layer (SCE)
> 
> Yours, test_sce_in_ds.xml is datastream file and that adds one more
> layer on top of this. The DataStream may contain all the needed assets
> in a single XML file. During the scan OpenSCAP unpacks the assets for
> SCE to the temp files.
> 
> You will perhaps need to debug which part fails and why.
> ~š.
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

[Open-scap] OpenSCAP Daemon - Fedora Updates

[Jan Cerny]

Hi,

Please provide Karma on OpenSCAP daemon 0.1.9.

Fedora 26 - https://bodhi.fedoraproject.org/updates/FEDORA-2018-8654af23fe

Fedora 27 - https://bodhi.fedoraproject.org/updates/FEDORA-2018-509bf79a3b

EPEL 7 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-db54a11b6d

Thank you very much.

Best Regards

Jan Černý
Security Technologies | Red Hat, Inc.


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Open SCAP on Ubuntu

[Jan Cerny]

Hi,

Unfortunately, scap-workbench was introduced in Ubuntu 17.04, so it is not 
available in 16.04.
In ubuntu 16.04 you can use still command-line tool oscap, which is found in 
package libopenscap8.
But there is old OpenSCAP 1.2.8. I don't expect Ubuntu people will update 
packages in LTS release.

Jan Černý
Security Technologies | Red Hat, Inc.


- Original Message -
> From: "Geoffry Roberts" 
> To: Open-scap-list@redhat.com
> Sent: Wednesday, January 24, 2018 4:04:34 PM
> Subject: [Open-scap] Open SCAP on Ubuntu
> 
> All,
> 
> Can anyone give me the status of OpenSCAP on Ubuntu? Is it healthy?
> 
> 
> 
> I am using Ubuntu because I can't get Fedora 27 Workstation to install on my
> vbox, an issue I'll be posting to the Fedora forum.
> I am just getting started with OpenSCAP. According to the users manual I
> should be able to install on Ubuntu 16.04 thus:
> 
> 
> # apt-get install scap-workbench
> 
> But I am getting no package found.
> 
> Thanks
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] oscap results stored in central database?

[Jan Cerny]

Hi,

This idea is very interesting.

Unfortunately it is not likely that we in Red Hat work on this database,
because it will create a strong competition for Red Hat Satellite.

But we will be very happy to provide our support and knowledge
if there will be a project developed by community.

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Šimon Lukašík" 
> To: "Luke Salsich" 
> Cc: "open-scap-list" 
> Sent: Friday, February 2, 2018 9:21:31 PM
> Subject: Re: [Open-scap] oscap results stored in central database?
> 
> On 02/02/2018 03:18 PM, Luke Salsich wrote:
> > Hi Simon,
> > 
> > I am surprised that SCAPtimony did not get traction as well.
> > 
> > when you say
> > 
> > "To this day, I am surprised there is no lean and functional microservice
> > to store, query and postprocess SCAP results.
> > ​"
> > 
> > What would you suggest? ​I ask because it seems like there is a
> > discussion about a lean microservice (to start with) and then a
> > discussion about a larger application or framework which can then make
> > use of the stored data. Personally, I don't think these two discussions
> > conflict. I think they are describing the first small step to a
> > microservice and then maybe to something larger after that.
> > 
> 
> When I said `that I am surprised that there is no lean and functional
> microservice to stre query and postprocess SCAP results` I was trying to
> imply that the task is really not that hard.
> 
> Take SCAPtimony and you are pretty close. I think its about 1 month of
> fulltime developer time (assuming she really knows what she is doing and
> she can afford to not look at mails, ignore sprints, scrums, managers,
> re-orgs and other urgent non-important things).
> 
> Cheers,
> ~š.
> 
> > But I would be interested to hear your thoughts on this.
> > 
> > 
> > 
> > 
> > ---
> > Luke Salsich
> > 
> > On Fri, Feb 2, 2018 at 8:21 AM, Šimon Lukašík  > > wrote:
> > 
> > Hello,
> > 
> > As original author of SCAPtimony, I feel urged to come in and say here
> > is my $0.02 coin.
> > 
> > After spending some time on OpenSCAP development, I started wondering
> > where all the results of the scans go. I thought there has to be
> > immense
> > need to make sense of the data organizations have and make a use of it.
> > For instance scan-result-diff in Satellite 5 was highly regarded at the
> > time. The other idea was to waive certain rule on certain system. And
> > there were more ideas like that.
> > 
> > Unfortunately, SCAPtimony project did not receive a traction I hoped
> > for. And hence the development stopped. Later on, Satellite 6 absorbed
> > SCAPtimony code, so community can no longer leverage what they did
> > since.
> > 
> > To this day, I am surprised there is no lean and functional
> > microservice
> > to store, query and postprocess SCAP results. I am still ready, to make
> > the SCAPtimony fly, but I would need a funding.
> > 
> > --
> > 
> > The standardization was also mentioned in the thread, so let me share
> > my
> > view on that as well. I think the standardization is great in theory. I
> > was huge fun of standardizations after coming out from uni. However,
> > after few years I realized that it is extremely hard to write standards
> > that are comprehensive and usable at the same time.
> > 
> > The way you can write good standard is to learn first. Let the
> > businesses or independent actors come up with few solutions, notice
> > similarities, standardize them. Let the businesses adopt that and
> > iterate again.
> > 
> > To return back to the topic. Parsing XML to SQL models/tables is great
> > idea and many freshmen would certainly love to jump on it. My gut tells
> > me, however, this is not the best (or sensible) way. I sometimes
> > struggle to describe why my gut says what it says, but consider
> > following: If I were founding start-up on building SCAP database, I
> > would surely not be parsing entities to SQL for sure.
> > 
> > Best,
> > ~š.
> > 
> > 
> > 
> > On 01/31/2018 10:22 PM, Luke Salsich wrote:
> > > Hey all,
> > >
> > > I've been using OpenSCAP for a while on our servers and really
> > > appreciate what it does.
> > >
> > > I've been looking around for a way to store scan results and then
> > query
> > > them and I can't seem to locate any plugins or apps which do this
> > other
> > > than SCAPTimony.
> > >
> > > SCAPTimony sounds great, but I'm not sure it's currently
> > maintained and
> > > I don't really want to dive into Foreman just to store Oscap results.
> > >
> > > What does the community use for this kind of scan / report storing
> > > and
> > > querying?
> > >
> > > We're currently using Ansible AWX to run scans and to manage
> >   

Re: [Open-scap] Openscap and Windows

[Jan Cerny]

Hi,

I have taken over the initiative and I work on enabling Windows support in 
OpenSCAP.

Unfortunately OpenSCAP was designed for Linux, and there is a lot of low-level 
stuff
that needs to be changed to make it working on Windows.
It isn't working on Windows now, but I'm getting closer.

I hope we will be able to release an upstream version of OpenSCAP for Windows 
in 2-3 months.

Stay tuned.

Best Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Michele Naldini" 
> To: open-scap-list@redhat.com
> Sent: Sunday, March 11, 2018 1:24:16 PM
> Subject: Re: [Open-scap] Openscap and Windows
> 
> Hi Team,
> i'm interested in $subject topic.
> I saw this old post:
> 
> https://www.redhat.com/archives/open-scap-list/2017-February/msg00010.html
> 
> Any update ?
> 
> Thanks in advance
> 
> 
> 
> MICHELE NALDINI
> 
> SOLUTION ARCHITECT , RHCSA
> 
> Red Hat Italy
> 
> Via Fara 26
> 
> mnald...@redhat.com M: ​+393409703180
> TRIED. TESTED. TRUSTED.
> 
> 
> 
> @redhatnews Red Hat Red Hat
> 
> 
> 
> On Sat, Mar 10, 2018 at 12:47 AM, Raphael Sanchez Prudencio <
> rasan...@redhat.com > wrote:
> 
> 
> 
> Hi Michele,
> 
> Please reach open-scap-list@redhat.com as I'm not on that team anymore.
> 
> 
> Thanks
> Raphael
> 
> On Fri, Mar 9, 2018 at 7:29 PM, Michele Naldini < mnald...@redhat.com >
> wrote:
> 
> 
> 
> ​​
> Hi Raphael,
> i'm interested in $subject topic.
> I saw this old post:
> 
> https://www.redhat.com/archives/open-scap-list/2017-February/msg00010.html
> 
> Any update ?
> 
> Thanks in advance
> 
> Regards
> 
> 
> MICHELE NALDINI
> 
> SOLUTION ARCHITECT , RHCSA
> 
> Red Hat Italy
> 
> Via Fara 26
> 
> mnald...@redhat.com M: ​+393409703180
> TRIED. TESTED. TRUSTED.
> 
> 
> 
> @redhatnews Red Hat Red Hat
> 
> 
> 
> 
> 
> --
> Raphael Sanchez Prudencio
> Red Hat Product Security
> 
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] OVAL filtering on directories?

[Jan Cerny]

Hi,

I'm afraid you have discovered a bug in OpenSCAP.
The problem isn't with the filters, but the problem is that OpenSCAP completely 
ignores directories.

I have reduced your OVAL to just collect everything under /usr/foo, I removed 
the filters. See the attachement.

I run following commands:

sudo mkdir -p /usr/foo/bar
sudo oscap oval eval --verbose INFO --results results.xml 
directory_reproducer.xml 

The results.xml does not contain any collected object, which shouldn't happen,
there should be the "bar" directory collected.

This needs to be fixed in OpenSCAP source code.

Regards

Jan Černý
Security Technologies | Red Hat, Inc.




- Original Message -
> From: ml+opens...@kcore.org
> To: open-scap-list@redhat.com
> Sent: Wednesday, April 11, 2018 4:10:14 PM
> Subject: [Open-scap] OVAL filtering on directories?
> 
> Hello list,
> 
> I'm fairly new to OVAL, and for a project I'm documenting several of our
> configuration rules into XCCDF, and adding OVAL rules to them to be able to
> have automated testing afterwards.
> 
> For most it's fairly straightforward, but for one I'm stumped and can't seem
> to get it right.
> 
> I want to scan /usr/foo and check that all directories in that directory have
> the correct permissions (0755).
> (Also same but check that all files have the right selinux context.)
> 
> For some reason, I can't seem to get it to filter the way I want. The oval
> collector always returns
> Collected: "oval:com.foobar:obj:24" : does not exist
> 
> 
> OVAL content:
> 
>   
> /usr/foo permissions
> /usr/foo directory (and subdirectories) should have
> permissions 0755 (rwx r-x r-x)
> 
> 
>   Red Hat Enterprise Linux 7
> 
>   
>   
>  test_ref="oval:com.foobar:tst:23"/>
>  test_ref="oval:com.foobar:tst:24"/>
>   
> 
> 
>xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#unix";>
>   
>   
> 
> 
>  xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#unix";>
>   
>   
> 
> 
>  xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#unix";>
>   /usr/foo
>   
> 
>  xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#unix";>
>  xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5";>
> oval:com.foobar:obj:25
> oval:com.foobar:ste:21
>   
> 
> 
>  xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#unix";>
>   
>   /usr/foo
>   ^.*$
> 
> 
>  xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#unix";>
>   false
>   false
>   false
>   true
>   true
>   true
>   true
>   false
>   true
>   true
>   false
>   true
> 
> 
>  xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#unix";>
>   directory
> 
> 
>  xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#unix";>
>   false
>   false
>   false
>   true
>   true
>   true
>   true
>   false
>   true
>   true
>   false
>   true
> 
> 
> 
> It seems that the include action filter on ste:21 is the problem - if i
> remove this, i get a bunch of files returned. If i change this to eg. an
> exclude filter on "regular", i'll just get all the other files. But an
> include on "directory" seems to not work?
> 
> I also tried using two exclude filters, but that also returned no results.
> 
> Any ideas?
> 
> Thanks in advance.
> 
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
> 


directory_reproducer.xml
Description: XML document
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Debugging xinetd_probe

[Jan Cerny]

Hi,

it could be easier to debug the probe in 'master' branch, where probes are not 
separate processes,
but are included in the oscap process.

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Šimon Lukašík" 
> To: open-scap-list@redhat.com
> Sent: Thursday, April 19, 2018 7:52:36 AM
> Subject: Re: [Open-scap] Debugging xinetd_probe
> 
> On 04/19/2018 01:07 AM, Joy Latten wrote:
> > Hi,
> > 
> > I am new to OVAL, so my apologies if I make a few incorrect
> > statements.   I get weird results when I scan some OVAL that I and a
> > colleague wrote for xinetd. I would like to dig a bit deeper to get an
> > understanding of what is going on and see if the problem is in the oval
> > or the xinetd_probe. I took a look at the OpenSCAP User Manual in the
> > section about Debugging. I would like to run gdb on the xinetd_probe, so
> > did
> > 
> > ./run gdb src/OVAL/probes/.libs/probe_xinetd
> > 
> > within gdb I entered the following that I cut-and-paste from my logfile,
> > 
> > run ("seap.msg" ":id" 0 (("xinetd_object" ":id"
> > "oval:com.myubuntu:obj:5536" ":oval_version" "5.11.1" ) (("protocol"
> > ":operation" 5 ":var_check" 1 ) "tcp" ) (("service_name" ":operation" 5
> > ":var_check" 1 ) "chargen" ) ) )
> > 
> > but I get the error message,
> > 
> > /bin/bash: -c: line 0: syntax error near unexpected token `('
> > During startup program exited with code 1.
> > (gdb)
> > 
> > What is the correct way to enter input to debug a probe in gdb?
> > 
> 
> I wish I had remembered. :-)
> 
> I think the SEXP (the input you pass in) needs to go to stdin of probe
> (but it has been while since I have been there).
> 
> I think i replaced the probe with a shell script that runs the probe and
> logs inputs and outputs and this way I learned to debug it.
> 
> Good luck,
> ~š.
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

[Open-scap] OpenSCAP 1.2.17

[Jan Cerny]

Hello OpenSCAPers,

We are thrilled to announce general availability of OpenSCAP 1.2.17 release.

This is the latest release from maint-1.2 maintenance branch. API/ABI is
fully compatible with 1.2.0 release. Users of 1.2.x releases are
recommended to update.

Changes:
  - New features
- HTML Guide user experience improvements
- New options in HTML report "Group By" menu
- oscap-ssh supports --oval-results (issue #863)
  - Maintenance
- Support comparing state record elements with item
- Updated Bash completion
- Make Bash role headers consistent with --help output
- Fixed problems reported by Coverity (issue #909)
- Fixed CVE schema to support 4 to 7 digits CVEs
- Fix output of generated bash role missing fix message
- Fix oscap-docker to clean up temporary image (RHBZ #1454637)
- Fix Ansible remediations generation
- Add a newline between ids in xccdf info (issue #968)
- Fix unknown subtype handling in oval_subtype_parse (issue #986)
- Outsourced the pthreads feature check and setup
- Speed up in debug mode
- Refactored the Python handling in build scripts
- Prevent reading from host in offline mode (issue #1001)
- Many probes use OWN offline mode
- Improve offline mode logic in OVAL probes
- Do not use chroot in system_info probe
- Prevent a segfault in oscap_seterr on Solaris
- Out of tree build is possible
- Use chroot for RPM probes in offline mode
- PEP8 accepts lines up to 99 characters
- New configure parameter --with-oscap-temp-dir (issue #1016)
- Fixed OVAL record elements namespace and SEXP conversion
- Removed '\r' characters from help output (issue #1023)
- Full Python 3 compatibility
- Removed basic Python implementation of oval_probes.c
- Added support for Travis CI and Sonar Cloud
- Minor fixes inspired by Sonar Cloud
- Added Fedora 29 CPE
- New tests in upstream test suite (offline mode, Ansible, etc.)

Special thanks to our new contributors Axel Nennker, Nitin Ravindran,
Vincent Batts and Yoon Jean Kim.

Download:
https://github.com/OpenSCAP/openscap/releases/download/1.2.17/openscap-1.2.17.tar.gz

SHA512:
38b80215e4815c3a4a50e86376fbd680e58d2470b67dbc02dda052b11de5dd4af4b525d639c3ad5359ac70194c63276fbecbe7445df36009f5fe492a80a77a27

Audit, Fix, And Be Merry!


Jan Černý
Security Technologies, Red Hat, Inc.
on behalf of OpenSCAP contributors

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] New GitHub teams

[Jan Cerny]

Hi,

These are great news!

However, I used to change settings in OpenSCAP repository, which I can't now,
because I don't have the settings button anymore.

This is a huge problem. Now, I can't merge the maint-1.2 branch into master,
because I'm not able to temporary disable the required check for
this operation and then enable it again after the merge.
Could that be fixed so that we can enable and disable the required checks
every time we need?

I also noticed that AppVeyor CI does not report build status on master pull
requests. Can that be related to the permission?
Please see https://github.com/OpenSCAP/openscap/pull/1075 to see an example.

Thank you very much!

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Martin Preisler" 
> To: "open-scap-list" 
> Sent: Wednesday, June 13, 2018 8:48:58 PM
> Subject: [Open-scap] New GitHub teams
> 
> GitHub has been notifying us for ages that we should migrate from
> legacy teams to the new system. I decided it was time to finally do
> it.
> 
> As part of this change the Owners team has been removed. GitHub
> recommends doing that (because once you migrate, the "Owners" team
> loses its special meaning).
> 
> We had 10 teams in the organization which was way too much. And they
> were overlapping a lot. I decided to merge them into just 2 teams -
> trusted tools developers for everything except SSG and trusted SSG
> developers for SSG. These 2 teams have full push rights to the repos
> (github write access). This should make it much simpler to audit and
> keep up to date. Besides, if we trust someone to push into openscap we
> probably trust them to push into scap-workbench as well...
> 
> You might have received notifications about deleted teams and you
> might have received invites to the new teams. I couldn't find any
> option to migrate people from team to team without notifying them like
> this, sorry for the inconvenience. I tried my best to keep everybody's
> permissions but with the amount of people and teams maybe I missed
> something. In case you encounter permission issues please let me know
> and I will fix it.
> 
> --
> Martin Preisler
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
> 

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

[Open-scap] OpenSCAP 1.3.0_alpha1

[Jan Cerny]

Hello OpenSCAPers,

We are thrilled to announce general availability of OpenSCAP 1.3.0_alpha1 
release.

This is the first alpha release from master branch. This alpha release
contains significant changes. API/ABI is not compatible with 1.2.x releases.
API/ABI may be subject of further changes before final version 1.3.0 will be
released. Users are encouraged to test and report bugs using
https://github.com/OpenSCAP/openscap/issues.

Changes:
  - New features
- Microsoft Windows support (issue #195)
- new probes:
   - Windows registry probe
   - Windows accesstoken probe
   - Windows wmi57 probe
- CMake is used as build system (issue #542)
- CTest is used as test suite driver
  - Maintenance
- probes are not separate processes, they are threads within oscap
- OpenSCAP can be compiled using Visual Studio 2017
- Dropped 53 deprecated API symbols (issue #1088)
- Removed GNU Automake
- Removed Python 2 support (issue #1034)
- Ninja build is supported
- Public API symbols are marked by OSCAP_API macro
- Removed variable lenght arrays
- Removed custom memory allocation functions (issue #1077)
- Improved OS X build support
- Fixed crash when deallocating red-black-tree node in Windows
- Several large tests are splitted into smaller test cases
- User manual is splitted in User and Developer manual
- Many documentation updates (issue #1069, #1066)
- Stopped using '\r' characters on stdout (issue #579, #1023)
- Updated release tools to reflect CMake (issue #1036)
- Dropped Cygwin support from User Manual (issue #1011)
- source tarball does not contain build artifacts
- Many small fixes

Special thanks to our new contributors Alexander Scheel and Milan Lysoněk.

Download:
https://github.com/OpenSCAP/openscap/releases/download/1.3.0_alpha1/openscap-1.3.0_alpha1.tar.gz

SHA512:
29d7c3fa7c0fb05973cd5f587d31abee9c77af85141c9556532a02acd1ec936c51e26f631931ad3fbe99025910ecf64e613f8d0fcb2cca3e35e69238b865f7e7


Audit, Fix, And Be Merry!


Jan Černý
Security Technologies, Red Hat, Inc.
on behalf of OpenSCAP contributors

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Submitting Remediation Fix Scripts

[Jan Cerny]

Hi,

Your understanding is correct, the remediation scripts are short scripts
that make a finding compliant, in other words they should fix the system
in a way the given rule will be passing.

The remediations scripts are part of SCAP Security Guide project,
https://github.com/OpenSCAP/scap-security-guide.

You can submit a new script by creating a pull request on GitHub. If you're not
familiar with GitHub yet, check https://guides.github.com/.

I recommend reading through "SCAP Security Guide Developer Guide".
https://github.com/OpenSCAP/scap-security-guide/blob/master/docs/manual/developer_guide.adoc
Remediations are described in Section 8.2, but the whole document is
helpful to understand the project.

You can get inspired by files in "shared/fixes" directory in SCAP Security 
Guide.
https://github.com/OpenSCAP/scap-security-guide/tree/master/shared/fixes

Let me point out some details:

The 'shared' directory is probably a right place if your script is applicable
to more than 1 operating system, which usually happens eg. if you work on RHEL7,
it is also applicable to Fedora.

Also notice that some of the remediation are generated automatically using
templates. That helps us to prevent duplicating code. For example, the scripts
that install a package are always the same, they just differ in the name of
package to be installed, so we just substitute the name to a template.
https://github.com/OpenSCAP/scap-security-guide/tree/master/shared/templates

If you have any questions, feel free to ask.

Best regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Boyd Ako" 
> To: open-scap-list@redhat.com
> Sent: Thursday, August 9, 2018 5:40:49 AM
> Subject: [Open-scap] Submitting Remediation Fix Scripts
> 
> Can anyone point me in the direction of how I help submit remediation fix
> scripts?
> 
> From my understanding and correct me if I'm wrong, those scripts make a
> finding compliant.
> 
> I'm aware of
> https://github.com/OpenSCAP/scap-security-guide/tree/master/rhel7/fixes/bash
> containing several fix scripts. I'm wondering if there's a certain process
> or format I should be aware of before I try to push some stuff over to it.
> 
> My submissions will be based off of using the DISA IASE RHEL XCCDFs in
> OpenSCAP.
> 
> 
> Thank you for your time,
> 
> Boyd H. Ako
> 
> boyd.hanalei@gmail.com
> 
>   
>   Cell Phone: (808) 226-8245 PGP/GPG Public Key:
>   https://sks-keyservers.net/pks/lookup?op=get&search=0xC58073B21618F134
> 
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

[Open-scap] OpenSCAP 1.3.0_alpha2

[Jan Cerny]

Hello OpenSCAPers,

We are thrilled to announce general availability of OpenSCAP 1.3.0_alpha2 
release.

This is the second alpha release from master branch. This alpha release
contains significant changes. API/ABI is not compatible with 1.2.x releases.
API/ABI may be subject of further changes before final version 1.3.0 will be
released. Users are encouraged to test and report bugs using
https://github.com/OpenSCAP/openscap/issues.

Changes:
  - Maintenance
- Removed '--probe-root' option
- Removed '--show' option from 'oscap xccdf generate report'
- Removed CCE API
- Removed deprecated option '--sce-results'
- Removed 'oscap oval list-probes' submodule
- Removed 'validate-xml' submodule from CPE, OVAL, XCCDF modules
- Moved OVAL probe handler to private headers
- Added tests for filehash58 offline mode
- Fixed broken SCE
- Fixed problematic versioning in CMake and pkgconfig file
- Removed many unused code
- Rewritten test tests/API/XCCDF/default_cpe
- Started to use asciidoc instead of asciidoctor
- Fixed many compiler warnings
- Fixed MinGW builds
- Documentation updates
- Small fixes


Download:
https://github.com/OpenSCAP/openscap/releases/download/1.3.0_alpha2/openscap-1.3.0_alpha2.tar.gz

SHA512:
6494c9e5728629b85cacc1364fce6a7b2fc341069341cbbf68f13ea4051c36f7ebb1ef7a5ad5bddad69e0006eed672de35090b86193796e938e2d6b66fa9defb


Audit, Fix, And Be Merry!


Jan Černý
Security Technologies, Red Hat, Inc.
on behalf of OpenSCAP contributors

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] New Structure for Content - Rule Directories in SCAP Security Guide

[Jan Cerny]

Hi,

Thank you for your excellent write-up. I think this new structure
is a big step forward and definitely makes contributing to SSG easier.

Kudos!

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Alexander Scheel" 
> To: "Open-scap-list" 
> Sent: Friday, August 24, 2018 8:03:04 PM
> Subject: [Open-scap] New Structure for Content - Rule Directories in SCAP 
> Security Guide
> 
> Hello everyone!
> 
> 
> This is part two of my end of internship mailing list posts. For part
> one and an introduction, see the earlier post, subject “Guide Mergers
> and Simplifications in SCAP Security Guide":
> https://www.redhat.com/archives/open-scap-list/2018-August/msg7.html
> 
> Another recent, major change was a complete reorganization of the content.
> We switched to a new rule directory format that should help simplify the
> contribution process. In the past, a rule was a completely separate entity
> from the check and fix content it described. This was apparent in the
> directory structure. For example, under the old system:
> 
> debian8/guide/services/ssh/ssh_server/sshd_set_keepalive.rule
> rhel6/fixes/bash/sshd_set_keepalive.sh
> rhel6/guide/services/ssh/ssh_server/sshd_set_keepalive.rule
> rhel7/fixes/bash/sshd_set_keepalive.sh
> shared/checks/oval/sshd_set_keepalive.xml
> shared/fixes/ansible/sshd_set_keepalive.yml
> shared/fixes/bash/sshd_set_keepalive.sh
> shared/guide/services/ssh/ssh_server/sshd_set_keepalive.rule
> ubuntu1404/guide/services/ssh/ssh_server/sshd_set_keepalive.rule
> ubuntu1604/guide/services/ssh/ssh_server/sshd_set_keepalive.rule
> 
> By making a rule a directory instead of just a YAML file (after merging all
> of the rules to the shared `linux_os/guide` directory), we can group all
> of the fix and check content in the same location. The same rule now looks
> like:
> 
> linux_os/guide/services/ssh/ssh_server/sshd_set_keepalive/rule.yml
> 
> linux_os/guide/services/ssh/ssh_server/sshd_set_keepalive/ansible/shared.yml
> linux_os/guide/services/ssh/ssh_server/sshd_set_keepalive/bash/shared.sh
> linux_os/guide/services/ssh/ssh_server/sshd_set_keepalive/oval/shared.xml
> 
> When looking for compliance content, there is now only one directory which
> contains all this information. This will help everyone find the correct
> directory for a rule, improve maintainability, and extensibility. As an
> overview, a rule directory contains a rule.yml file (previously called
> rule_id.rule and with the same information) and five subdirectories:
> 
> - oval/ (.xml extension)
> - ansible/ (.yml extension)
> - anaconda/ (.anaconda extension)
> - bash/ (.sh extension)
> - puppet/ (.pp extension)
> 
> Inside each of these subdirectories, files named “shared.ext” will be
> included
> in all products, whereas files named with “product.ext” will be included in
> only that product. This lets us see at a glance what content can be included
> in the build, and eventually enhance our build tests to see if content which
> could have been in a product is not.
> 
> For more information, see the rule directory section of the developer
> documentation:
> https://github.com/OpenSCAP/scap-security-guide/blob/master/docs/manual/developer_guide.adoc#812-rule-directories
> 
> Note that old rule files and the old locations for content is still
> supported by the build system, so if your patches apply against master
> (and/or a are in a separate product), this will not affect them. These
> changes
> were introduced in the following PRs:
> 
>   - Build system support:
>   https://github.com/OpenSCAP/scap-security-guide/pull/3188
>   - Move all existing rules:
>   https://github.com/OpenSCAP/scap-security-guide/pull/3178
>   - Several other PRs adding tests, documentation which are referenced from
>   the above two.
> 
> However, if you have any patches that include new products into our build
> system and wish to convert your changes to this new system, feel free to
> modify and use the `utils/move_rules.py` utility. If you have questions,
> feel free to reach out to us.
> 
> 
> We also introduced a new set of utilities for analyzing the source
> content. These are be located under `utils/rule_dir*.py`. For more
> information on these utilities and other utilities in the build system,
> check out the relevant PRs and the developer documentation (linked above):
> 
>   - Utilities: https://github.com/OpenSCAP/scap-security-guide/pull/3193
> 
> Thanks for reading! As always, if you have any questions, feel free to
> reply to the mailing list, open issues, or find us on the #openscap
> channel on Freenode.
> 
> 
> 
> Until next time,
> 
> Alex Scheel
> 
> Freenode: cipherboy in #openscap
> GitHub: https://github.com/cipherboy
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___

Re: [Open-scap] question on addon_fedora_oscap

[Jan Cerny]

Hi,

Unfortunately, the "tailoring" feature is broken in Anaconda Addon.

However, there is a workaround, suggested by Watson Yuuma Sato (adding him to 
this conversation).
Let me copy-paste his idea:

There is a tool that can combine the tailoring to the datastream or XCCDF file. 
So it is possible
to embed the tailoring into content file and get it through "content-url" field.

Quick howto commands and instructions below:
Grab the combine-tailoring tool
$ git clone https://github.com/mpreisler/combine-tailoring.git
cd combine-tailoring

Combine tailoring and content
./combine-tailoring.py --output ssg-rhel7-ds-combined.xml 
/usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml 
ssg-rhel7-ds-standard-tailoring.xml

Serve the file ssg-rhel7-ds-combined.xml in your network, and 
in the kickstart:
- change content-type to datastream or xccdf
- add field content-url and point to your new combined content
- change profile to the id of your customized profile, please note that it must 
be the full id.

For example:
%addon org_fedora_oscap
   content-type = datastream
   content-url = http://192.168.0.2/content/ssg-rhel7-ds-combined.xml
   profile = xccdf_org.ssgproject.content_profile_standard_customized
%end


Hopefully it helps.

Regards



Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "MARK D CTR USAF AFMC 412 RANS ROSS/JT4" 
> To: open-scap-list@redhat.com
> Sent: Thursday, October 4, 2018 2:02:51 AM
> Subject: [Open-scap] question on addon_fedora_oscap
> 
> HI
> I hope this is the right place to ask this ? I am not finding much help with
> the documents. My goal is to build virtual systems that is scapped and using
> the kickstart  Anaconda Addon to automate the scaping process. Everything is
> working except for the "tailoring-path". I have created a tailoring.xml file
> and  I don't understand how to fetch the tailoring.xml file
> 
> >From the DOCS
> tailoring-path - Path of the tailoring file that should be used, given as a
> relative path in the archive.
> 
> So if the tailoring-path must be in an archive, does the content-type have to
> be "archive" ? if so then what type of archive ? tar ? rpm ?
> I am fetching everything over the network so what would be my best option ?
> Can anyone direct me to an example of this ?
> thanks
> 
> %addon org_fedora_oscap
> 
> content-type = datastream
> 
> content-url = http://adaps-f1/scap/ssg-centos7-ds.xml
> 
> datastream-id =
> scap_org.open-scap_datastream_from_xccdf_ssg-rhel7-xccdf-1.2.xml
> 
> xccdf-id = scap_org.open-scap_cref_ssg-rhel7-xccdf-1.2.xml
> 
> profile = xccdf_org.ssgproject.content_profile_stig-rhel7-disa
> 
> tailoring-path = http://adaps-f1/scap/ssg-centos7-ds-tailoring.xml
> 
> %end
> 
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
> 

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

[Open-scap] OpenSCAP 1.3.0

[Jan Cerny]

Hello OpenSCAPers,

We are thrilled to announce general availability of OpenSCAP 1.3.0 release.

This is the first release from maint-1.3 maintenance branch. API/ABI is not
compatible with 1.2.x releases. API/ABI is not compatible with 1.3.0_alpha
releases.

Changes from 1.3.0_alpha2:
  - New features
- Introduced a virtual '(all)' profile selecting all rules
- Verbose mode is a global option in all modules
- Added Microsoft Windows CPEs
- oscap-ssh can supply SSH options into an environment variable
  - Maintenance
- Removed SEXP parser
- Added Fedora 30 CPE
- Fixed many Coverity defects (memory leaks etc.)
- SCE builds are enabled by default
- Moved many low-level functions out of public API
- Removed unused and dead code
- Updated manual pages
- Numerous small fixes

Key differences from 1.2.x series:
- Basic Microsoft Windows support
- Removed deprecated command line interfaces
- Removed deprecated API symbols
- Probes are not separate processes anymore
- CMake used as build system
- CTest used as a test framework

Download:
https://github.com/OpenSCAP/openscap/releases/download/1.3.0/openscap-1.3.0.tar.gz

SHA512:
9405d0f17b60ab4a52ddd0f49d0e2395eb2540f0d07d68dfd142e2b8b2988e88cf127230523e68f67d3d22a6dd4eb2397f9468c923d19bb7cb059abf487ab5a1

Audit, Fix, And Be Merry!


Jan Černý
Security Technologies, Red Hat, Inc.
on behalf of OpenSCAP contributors


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] OpenSCAP 1.3.0

[Jan Cerny]

Hi,

OpenSCAP support for Windows hasn't been improved much since the
1.3.0_alpha1 releases. The only thing that we have done
recently is that we added Windows CPEs to the inbuilt CPE dictionary.

> How far along is Windows support? Saw the mention of 'basic' -- but how
> should OpenSCAP on Windows be positioned?

OpenSCAP 1.3.0 can be compiled and installed on Windows, it runs, it produces
"some" results. But it's very bad.

> - How many Windows probes are implemented?

OpenSCAP 1.3.0 for Windows has the following 4 probes:
* system_info
* registry
* wmi57
* accesstoken

> - Does OpenSCAP on Windows pass the NIST automated tooling?

Nobody tried that. I expect that it doesn't pass.

> - Where can we send people who want to find out more?

For people that would like to contribute code I would point them to developer's
manual where they can find how to build it on Windows.
https://github.com/OpenSCAP/openscap/blob/master/docs/developer/developer.adoc

For normal users we don't have anything.
I think we definitely should mention that it exists on www.open-scap.org.

The problem with OpenSCAP for Windows is that nobody is working on that now,
and it is not tested at all. Also, it is not supported by Red Hat in any way.

I'm sorry if the release announcement email caused a confusion.
I mentioned the Windows support under "Key differences from 1.2.x series"
because the 1.3.0_alpha1 and 1.3.0_alpha2 releases were intended as 
pre-releases.
I supposed most people didn't follow their changelog. I wanted to point out 
there
at least the main differences of 1.3.0 for users of 1.2.x releases.

However, as usually, the full changelog is located at:
https://github.com/OpenSCAP/openscap/blob/master/NEWS

Regards

Jan Černý
Security Technologies | Red Hat, Inc.





- Original Message -
> From: "Shawn Wells" 
> To: open-scap-list@redhat.com
> Sent: Tuesday, October 9, 2018 5:53:08 PM
> Subject: Re: [Open-scap] OpenSCAP 1.3.0
> 
> 
> 
> On 10/9/18 7:38 AM, Jan Cerny wrote:
> > Hello OpenSCAPers,
> >
> > We are thrilled to announce general availability of OpenSCAP 1.3.0 release.
> >
> > This is the first release from maint-1.3 maintenance branch. API/ABI is not
> > compatible with 1.2.x releases. API/ABI is not compatible with 1.3.0_alpha
> > releases.
> >
> > Changes from 1.3.0_alpha2:
> >- New features
> >  - Introduced a virtual '(all)' profile selecting all rules
> >  - Verbose mode is a global option in all modules
> >  - Added Microsoft Windows CPEs
> >  - oscap-ssh can supply SSH options into an environment variable
> >- Maintenance
> >  - Removed SEXP parser
> >  - Added Fedora 30 CPE
> >  - Fixed many Coverity defects (memory leaks etc.)
> >  - SCE builds are enabled by default
> >  - Moved many low-level functions out of public API
> >  - Removed unused and dead code
> >  - Updated manual pages
> >  - Numerous small fixes
> >
> > Key differences from 1.2.x series:
> > - Basic Microsoft Windows support
> > - Removed deprecated command line interfaces
> > - Removed deprecated API symbols
> > - Probes are not separate processes anymore
> > - CMake used as build system
> > - CTest used as a test framework
> >
> > Download:
> > https://github.com/OpenSCAP/openscap/releases/download/1.3.0/openscap-1.3.0.tar.gz
> >
> > SHA512:
> > 9405d0f17b60ab4a52ddd0f49d0e2395eb2540f0d07d68dfd142e2b8b2988e88cf127230523e68f67d3d22a6dd4eb2397f9468c923d19bb7cb059abf487ab5a1
> >
> > Audit, Fix, And Be Merry!
> 
> Thanks Jan!
> 
> How far along is Windows support? Saw the mention of 'basic' -- but how
> should OpenSCAP on Windows be positioned?
> 
> For example:
> - How many Windows probes are implemented?
> - Does OpenSCAP on Windows pass the NIST automated tooling?
> - Where can we send people who want to find out more?
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
> 

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Developing content for Oracle Linux

[Jan Cerny]

Hi Tina,

Thank you for reaching us. There is ComplianceAsCode project (formerly known
as SCAP Security Guide) that provides SCAP content for various Linux 
distributions.

ComplianceAsCode is an open-source project and it's developed actively on 
GitHub.
Here's the link: https://github.com/ComplianceAsCode/content
Check out the README there.

ComplianceAsCode already has some SCAP content for Oracle Linux 7. It needs a 
lot of
improvements, but it's a great place to start. It's possible to reuse a lot of 
stuff
that is used in RHEL content. There is a person from Oracle, Ilya Okomin,
who used work on that.

The process for sharing content with the community is to submit patches
via GitHub using pull requests. We are willing to provide feedback and help
your developers with that.
There is a developer guide that explains how the content is built:
https://github.com/ComplianceAsCode/content/blob/master/docs/manual/developer_guide.adoc

Hopefully this helps. We're looking forward to hear from you soon. 

Regards

Jan Černý
Security Technologies | Red Hat, Inc.




- Original Message -
> From: "Tina Rose" 
> To: open-scap-list@redhat.com
> Sent: Friday, October 19, 2018 7:38:45 PM
> Subject: [Open-scap] Developing content for Oracle Linux
> 
> 
> 
> I had a customer request Open-SCAP content specific to Oracle Linux to
> complete STIG compliance. Can someone point me in the right direction to
> begin researching this request? Is there a process for creating and sharing
> content to the open-scap community?
> 
> 
> 
> 
> 
> Tina Rose | Consulting Member of Technical Staff
> 
> Office: +1 719 757 3203
> 
> Oracle Platform Integration MAA Team
> 
> 
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Making Fix Templates

[Jan Cerny]

Hi,

I have looked into this quickly. But I haven't able to get that working. I 
haven't found
anything in the source code that uses it. It seems to me that the feature has 
been removed
without changing the documentation. I'm not sure if the removal was intended or 
if it is
a regression.

The "oscap xccdf generate fix" command only extracts the code snippets from the 
input
XCCDF or DS file. There is no magic logic behind that, it is a very simple 
transformation.
It doesn't understand or doesn't analyze the rules that are there.

It isn't clear to me what you need. Do you try to map SSG XCCDF to XCCDF 
provided by DISA?

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Boyd Ako" 
> To: open-scap-list@redhat.com
> Sent: Wednesday, January 9, 2019 1:32:48 AM
> Subject: [Open-scap] Making Fix Templates
> 
> Aloha,
> 
> So I had a couple questions.
> 
> A) Is using the Fix Template function still being supported?
> 
> B) Is there more detailed documentation on creating the template? I'm already
> aware of the XSL "legacy" files in /usr/share/openscap/xsl. I seem to be
> having issues with openscap outputing anything from the
> legacy-fixtpl-bash.xml as it is or when I try to modify the "fixentry" to
> map to a rule.
> 
> C) If the Fix Template function is more or less dead in the water, is there a
> way I can "convey" fixes for the remediation script generation that's either
> local or on premise? I know that OpenSCAP does have a bunch of fixes for the
> SSGs. But I can't really reach them due to isolation and even if I could it
> wouldn't be permitted since it's "external" to "DISA Approved" stuff.
> 
> 
> My environment: As awesome as it is that there's SSGs for DISA RHEL 7, I
> can't use it because it doesn't have the MAC and Sensitivity profiles in the
> actual RHEL 7 Benchmark from the DISA XCCDF. So, I'm using the the XCCDF
> from DISA with the appropriate profile and none of the "rules" seem to match
> any of the remediation fixes for the failed rules. Also due to networking
> infrastructure, I'm more or less isoalted so fetching remote resources is
> out.
> 
> 
> 
> 
> Thank you for your time,
> 
> Boyd H. Ako
> 
> boyd.hanalei@gmail.com
> https://www.boydhanaleiako.me
> 
>   
>   Cell Phone: (424) 244-9653 PGP/GPG Public Key:
>   https://sks-keyservers.net/pks/lookup?op=get&search=0xC58073B21618F134
> 
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Making Fix Templates

[Jan Cerny]

Hi,

Thank you for a detailed explanation of your use case. I have a couple  of 
ideas:

You don't need `oscap` to run a XSLT transformation. You can just run `xsltproc`
with the template. OpenSCAP can generate XCCDF results (add --results 
results.xml).
You can then process the XCCDF results in arbitrary way. XCCDF results is a 
normal
XML file. You can write XSLTs and use them to extract the snippets or do any 
other
transformation as with normal XML.

Even better, you can have a Python or Perl (or whatever) script that processes 
the
XCCDF results. That script can generates your code snippets, it can have more 
complex
logic. I guess it would be easier to write this logic in a scripting language.
The XCCDF results is a standard format, specified by NIST. It includes the 
input XCCDF
inside, so you have all the data to be able to process (it contains CCEs, rule 
IDs, etc.)

I'm not sure if this feature could be a good fit for OpenSCAP or if we should 
develop
something like that in OpenSCAP, because it seems to me as a very custom thing
and every user will have different needs. If you envision something, any 
contributions
are welcome.

People are already collaborating on the fixes within SSG, which was renamed to
ComplianceAsCode, on GitHub. https://github.com/ComplianceAsCode/content


Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Boyd Ako" 
> To: "Jan Cerny" 
> Cc: open-scap-list@redhat.com
> Sent: Saturday, January 12, 2019 2:05:21 AM
> Subject: Re: [Open-scap] Making Fix Templates
> 
> What do you mean by "map" the XCCDFs of SSG and DISA? I've looked into the
> the DISA Vunerability IDs referenceing the CCI/CCEs that it's for. I
> haven't checked it against the SSG XCCDF though.
> 
> Yeah... I know the "generate fix" thing is muck. I'm actually having to
> rebuild a system because the script killed my bootloader.
> 
> I'm essentially trying to use the "generate fix" functionality using
> external snippets. It's pretty obvious the snippets and the results are not
> that dependable to use on production systems. It's what the template used
> to do. It finds CCI XXX as open and searches the template for function CCI
> XXX and adds the snippet to script. The snippet it's self would also
> "double check" the finding and "fix" the finding in means that you could
> run it over and over again and it'd only do something when the snippet
> actually finds the finding as open.
> 
> I get why the snippets are included into the XCCDF. However, it doesn't
> have the ability to take in logic and conditions on a "per system" basis. I
> know that's where the "tailoring" comes in. But that's also to "static". By
> using a template, in the PRE section I can state that "if 3rd IP octet is
> 130 do not run fix for CCI XXX or use value of blah for CCI XXX setting"
> noting some official documentation for exception.
> 
> That all being said, all Open SCAP then does is essentially just scan the
> system. And in my work environment the SPAWAR SCC is the more approved
> scanner. And I could make a script to read the results XML and generate a
> fix script like Open SCAP would do. But, that would imply that we don't
> need Open SCAP to begin with and remove a justification for the department
> to purchase Red Hat Satellite. ... However, if I can use the Open SCAP to
> use the stated authorized and approved DISA XCCDF and then use a template
> to fill in the blanks for the finding snippets that would be a means more
> likely to be approved.
> 
> 
> All the XCCDFs are good for scanning. But, the fixing and remediation is
> where most of the Sys Ads complain. And the XCCDF code snippets are not
> reliable because only a really tiny group of people are able to update the
> XCCDF files; officially. If the template function worked, I'd imagine a
> bunch of people collaborating on making fix templates on GITHUB or where
> ever. The XCCDF file needs to be official and authorized. The fix templates
> do not.
> 
> 
> --
> Thank you for your time,
> 
> Boyd H. Ako
> 
> boyd.hanalei@gmail.com
> https://www.boydhanaleiako.me
> Cell Phone: (424) 244-9653PGP/GPG Public Key:
> https://sks-keyservers.net/pks/lookup?op=get&search=0xC58073B21618F134
> --
> 
> 
> On Thu, Jan 10, 2019 at 9:27 PM Jan Cerny  wrote:
> 
> > Hi,
> >
> > I have looked into this quickly. But I haven't able to get that working. I
> > haven't found
> > anything in the source code that uses it. It seems to me that the feature
> > has been remo

Re: [Open-scap] Benchmark for Canonical Ubuntu 16.04 LTS

[Jan Cerny]

Hi,

You're correct that SCAP Security Guide was not shipped as a package in Ubuntu 
16.04, but it is
shipped in Ubuntu 18.04.

The file “U_Canonical_16-04_LTS_V1R1_STIG.zip" is a different content, which 
isn't provided by
SCAP Security Guide project, but is provided by DISA.


Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "William Boucher" 
> To: "Watson Sato" 
> Cc: open-scap-list@redhat.com
> Sent: Monday, January 21, 2019 11:55:54 PM
> Subject: Re: [Open-scap] Benchmark for Canonical Ubuntu 16.04 LTS
> 
> 
> 
> Stuart and Watson,
> 
> 
> 
> I found the packages for Ubuntu 18.04 (“cosmic”) but not for Ubuntu 16.04
> (“xenial”). The DISA STIG is written specifically for Ubuntu 16.04
> (“U_Canonical_16-04_LTS_V1R1_STIG.zip”). Am I not looking in the right place
> for the SSG?
> 
> 
> 
> I found the ssg packages for Ubuntu 18.04 at
> https://packages.ubuntu.com/search?suite=cosmic&searchon=names&keywords=ssg
> , but they are not in the 16.04 package listing at
> https://packages.ubuntu.com/search?suite=xenial&searchon=names&keywords=ssg
> .
> 
> 
> 
> Could they be in another repository for 16.04? (Note I am using the latest
> xenial, 16.04.5, which has the same Linux kernel as the latest cosmic
> release, 4.15.)
> 
> 
> 
> Thank you for your help and patience,
> 
> 
> 
> --Bill
> 
> 
> 
> William B. Boucher, BSEE
> 
> Embedded Systems Software Engineer
> Information Systems Security Manager
> 
> MZA Associates Corporation
> 
> 4900 Lang Ave. NE, Suite 100
> 
> Albuquerque, NM 87109-9708
> 
> Phone: 505.245.9970 x166
> 
> Fax: 505.245.9971
> 
> Cell: 505.459.7620
> 
> william.bouc...@mza.com
> 
> 
> 
> From: Watson Sato [mailto:ws...@redhat.com]
> Sent: Monday, January 7, 2019 7:58 AM
> To: Boucher, William 
> Cc: Newman, Stuart J. (GSFC-491.0)[KBRwyle] ;
> open-scap-list@redhat.com
> Subject: Re: [Open-scap] Benchmark for Canonical Ubuntu 16.04 LTS
> 
> 
> 
> 
> Hello,
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, Nov 28, 2018 at 5:39 PM Boucher, William < william.bouc...@mza.com >
> wrote:
> 
> 
> 
> 
> 
> Stuart,
> 
> 
> 
> How do I get the current/latest scap security guide?
> 
> 
> 
> 
> Latest pre-built content can be grabbed at
> https://github.com/ComplianceAsCode/content/releases , just download the zip
> file.
> 
> 
> 
> 
> 
> 1) I went to https://www.open-scap.org/security-policies/scap-security-guide/
> and clicked on the Ubuntu symbol to get directions for installing it, but
> that gave message “The SCAP Security Guide package is not available on the
> Ubuntu distribution yet. Check for update.”
> 
> 
> The website needs to updated, there are SCAP Security Guide packages for
> Ubuntu and Debian.
> 
> 
> 
> 
> 
> 2) “apt-get install scap-security-guide” produced the error “Unable to locate
> package scap-security-guide.”
> 
> 
> 
> 
> 
> It seems that the packages are named slightly different in Ubuntu, see:
> https://packages.ubuntu.com/source/disco/scap-security-guide
> 
> 
> 
> 
> 
> 
> 
> I did successfully install libopenscap8 (“apt-get install libopenscap8”).
> 
> 
> 
> All help is appreciated.
> 
> 
> 
> 
> William B. Boucher, BSEE
> 
> Embedded Systems Software Engineer
> Information Systems Security Manager
> 
> MZA Associates Corporation
> 
> 2021 Girard Blvd., SE, Suite 150
> 
> Albuquerque, New Mexico 87106
> 
> Phone: 505.245.9970 x166
> 
> Fax: 505.245.9971
> 
> Cell: 505.459.7620
> 
> william.bouc...@mza.com
> 
> 
> 
> 
> 
> From: Newman, Stuart J. (GSFC-491.0)[KBRwyle] [mailto:
> stuart.j.new...@nasa.gov ]
> Sent: Wednesday, November 28, 2018 4:19 AM
> To: Boucher, William < william.bouc...@mza.com >; open-scap-list@redhat.com
> Subject: RE: Benchmark for Canonical Ubuntu 16.04 LTS
> 
> 
> 
> 
> The current (0.1.41) version of the scap security guide has Ubuntu
> benchmarks.
> 
> 
> 
> 
> Stuart J Newman
> 
> 
> 
> 
> 
> 
> 
> Engineer 4; Systems
> 
> NASA/Goddard Space Flight Center, Building 14 Room 252 | Greenbelt, Maryland
> 20771 | USA
> 
> Office: +1 301. 286.5145 | Mobile: +1443.878.6146 | stuart.j.new...@nasa.gov
> 
> 
> 
> 
> 
> 
> 
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient. Any
> review, use, distribution, or disclosure by others is strictly prohibited.
> If you are not the intended recipient (or authorized to receive information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.
> 
> 
> 
> 
> 
> From: open-scap-list-boun...@redhat.com < open-scap-list-boun...@redhat.com >
> On Behalf Of Boucher, William
> Sent: November 27, 2018 18:23
> To: open-scap-list@redhat.com
> Subject: [Open-scap] Benchmark for Canonical Ubuntu 16.04 LTS
> 
> 
> 
> 
> 
> 
> Hi folks,
> 
> 
> 
> I am currently hardening an Ubuntu embedded system for delivery to a
> customer.
> 
> 
> 
> I have downloaded the “Canonical Ubuntu 16.04 LTS STIG Ver 1, Rel 1” from
> DISA, and I have obtained a copy of t

Re: [Open-scap] Ubuntu Security Guide content

[Jan Cerny]

Hi Todd,

The security content is provided by "ComplianceAsCode" project, which was
up until recently known as "SCAP Security Guide" or "SSG".
See https://github.com/ComplianceAsCode/content

The security content is packaged in Ubuntu since Ubuntu 18.04 (Bionic Beaver).
The packages are: ssg-base, ssg-debderived, ssg-debian,  ssg-nondebian,  
ssg-applications.

However, the packages contain outdated versions of upstream content, and AFAIK
the content in the packages is applicable to Ubuntu 16.04 an 14.04. That is
kind of useless on 18.04 :)

Therefore, I suggest downloading the latest upstream release from GitHub:
https://github.com/ComplianceAsCode/content/releases/download/v0.1.42/scap-security-guide-0.1.42.zip
Extract the archive and then open ssg-ubuntu1804-ds.xml in SCAP Workbench.

Thank you very much for reminding us about the outdated web site. I will try
to update the web soon.

Best Regards

Jan Černý
Security Technologies | Red Hat, Inc.



- Original Message -
> From: "Todd Williams" 
> To: open-scap-list@redhat.com
> Sent: Wednesday, January 30, 2019 6:58:40 PM
> Subject: [Open-scap] Ubuntu Security Guide content
> 
> 
> 
> Hello,
> 
> I am new to SCAP and have been tasked with setting it up on a Ubuntu test
> system. It is running Ubuntu 18.04.1 LTS. I have these 2 packages installed:
> 
> libopenscap8/bionic,now 1.2.15-1build1 amd64 [installed]
> scap-workbench/bionic,now 1.1.5-1 amd64 [installed]
> 
> I can bring up the GUI for the workbench, but with no security content I am
> stuck as far as being able to run a scan and/or editing the security
> requirements. According to the web site there is no security guide for
> Ubuntu.
> 
> 
> 
> But I have been told that there is a package for Ubuntu out there, "apt-get
> list" did not return anything, can someone tell if there is or not?
> 
> 
> 
>   Thanks,
> Todd M. Williams
> Unix System Admin, devIT-US, AIX/Linux/CC/CQ/SPoRT/DB2
> Phone: 772-257-5706 | Mobile: 772-925-2042
> E-Mail: tod...@us.ibm.com
> devIT
> 
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Ubuntu Security Guide content

[Jan Cerny]

Hi,

You're correct it's missing CPE dictionary and CPE OVAL. 
The files are located here:
https://github.com/OpenSCAP/openscap/blob/maint-1.2/cpe/openscap-cpe-dict.xml
https://github.com/OpenSCAP/openscap/blob/maint-1.2/cpe/openscap-cpe-oval.xml
They're list of platform definitions based on which the platform applicability 
of SCAP 
content is determined.
OpenSCAP expect them to be present in '/usr/share/openscap/cpe/'

I'm not an Ubuntu user, so I'm only guessing, but I think that downloading 
these files
and saving them to '/usr/share/openscap/cpe/' should help.

This is probably a bug in Ubuntu packaging, because it seems Ubuntu doesn't 
ship these
files in its packages, but they are required by OpenSCAP to work correctly. You 
can try
to file a bug report on Ubuntu.

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

- Original Message -
> From: "Todd Williams" 
> To: "Jan Cerny" 
> Sent: Friday, February 1, 2019 4:35:50 PM
> Subject: Re: [Open-scap] Ubuntu Security Guide content
> 
> 
> Hi Jan,
> 
> So I was able to use ssg-ubuntu1804-ds.xml in scap-workbench on Ubuntu
> 18.4, and I got this error when I ran the scan
> 
> 
> 14:27:38
> info
> SCAP Workbench 1.1.5, compiled with Qt 4.8.7, using OpenSCAP 1.2.15
> 
> 
> 14:28:16
> info
> Opened file '/root/scap-security-guide-0.1.42/ssg-ubuntu1804-ds.xml'.
> 
> 
> 14:28:25
> info
> Querying capabilities...
> 
> 
> 14:28:25
> info
> Creating temporary files...
> 
> 
> 14:28:25
> info
> Starting the oscap process...
> 
> 
> 14:28:25
> info
> Processing...
> 
> 
> 14:28:30
> error
> The 'oscap' process has written the following content to stderr: OpenSCAP
> Error: Unable to open file:
> '/usr/share/openscap/cpe/openscap-cpe-dict.xml'
> [../../../src/source/oscap_source.c:284]
> 
> 
> 
> 14:28:30
> error
> The 'oscap' process has written the following content to stderr: Failed to
> add default CPE to newly created CPE Session.
> [../../../src/CPE/cpe_session.c:58]
> 
> 
> 14:28:30
> info
> The oscap tool has finished. Reading results...
> 
> 
> 14:28:30
> info
> Processing has been finished!
> 
> 
> 14:28:58
> info
> Querying capabilities...
> 
> 
> 14:28:58
> info
> Creating temporary files...
> 
> 
> 14:28:58
> info
> Starting the oscap process...
> 
> 
> 14:28:58
> info
> Processing...
> 
> 
> 14:29:00
> error
> The 'oscap' process has written the following content to stderr: OpenSCAP
> Error: Unable to open file:
> '/usr/share/openscap/cpe/openscap-cpe-dict.xml'
> [../../../src/source/oscap_source.c:284]
> 
> 
> 
> 14:29:00
> error
> The 'oscap' process has written the following content to stderr: Failed to
> add default CPE to newly created CPE Session.
> [../../../src/CPE/cpe_session.c:58]
> 
> 
> 14:29:00
> info
> The oscap tool has finished. Reading results...
> 
> 
> 14:29:00
> info
> Processing has been finished!
> 
> 
> So I went to /usr/share/openscap/cpe and the only file there is the README,
> so I read it and it pointed me to https://nvd.nist.gov/Products/CPE.  I
> found these files there:
> official-cpe-dictionary_v2.3.xml.gz
> official-cpe-dictionary_v2.2.xml.gz
> Can I rename and use 1 of these?
> 
> I have it setup and running on RHEL 7.6 and when I look at that dir on that
> system it has 2 files, can I use them?
> openscap-cpe-dict.xml
> openscap-cpe-oval.xml
> 
> 
> BTW, the setup for RHEL goes much smoother than Ubuntu..
> 
>   
>       
>   
>Thanks,
>Todd M. Williams
>Unix System Admin, devIT-US,
>AIX/Linux/CC/CQ/SPoRT/DB2
>Phone: 772-257-5706 | Mobile: 772-925-2042
>E-Mail: tod...@us.ibm.com
>devIT
>   
> 
> 
> 
> 
> 
> 
> From: Jan Cerny 
> To:   Todd Williams 
> Cc:   open-scap-list@redhat.com
> Date: 01/31/2019 03:57 AM
> Subject:  Re: [Open-scap] Ubuntu Security Guide content
> 
> 
> 
> Hi Todd,
> 
> The security content is provided by "ComplianceAsCode" project, which was
> up until recently known as "SCAP Security Guide" or "SSG".
> See
> https://urldefen

Re: [Open-scap] Need help on openscap SSG question

[Jan Cerny]

Hi,

I will try to answer, but I don't use Nessus, so I'm not sure what is
the exact reason of this fail.

In general, the SSG files are validated against SCAP XML schemas, so
they are valid SCAP content.
However, SCAP standard consist of multiple separate specifications.
Strictly speaking, the SSG datastream
doesn't conform to SCAP 1.2 specification, because the datastream
contains OVAL checks conforming to OVAL
version 5.11 which is a part of SCAP 1.3. For SCAP 1.2 conformance it
would need to use OVAL checks
in version 5.10 or older.

According to this forum thread, it seems that Nessus doesn't support
OVAL 5.11 it yet, but they say it's planned to be updated
https://community.tenable.com/s/question/0D5f25hKRwqCAG/nessus-pro-7-trouble-getting-oval-scans-to-work

It could be a problem that Nessus expects datastreams that  contain
OVAL 5.10 only.
Try using the SSG datastreams that contain OVAL 5.10 only. They can be
downloaded from
https://github.com/ComplianceAsCode/content/releases/download/v0.1.43/scap-security-guide-0.1.43-oval-510.zip
I hope Nessus should be able to consume these files.

The reason why we use 5.11 is that it contains new checks that allows
us to check easily system services using systemd
and other new things introduced in RHEL 7. The aforementioned
datastreams that contain OVAL 5.10 only
have limited abilities in comparison with those containing OVAL 5.11.

Best Regards

Jan Černý
Security Technologies | Red Hat, Inc.


On Sat, Apr 27, 2019 at 6:34 AM Riaz Ebrahim  wrote:
>
> I need help on openscap SSG project.
>
> I am currently exploring SCAP Auditing feature from Nessus console. I 
> understood that Nessus supports SCAP Content (1.0 or 1.1 or 1.2) which can be 
> downloaded from NIST repository (https://nvd.nist.gov/ncp/repository) based 
> on the target host version. This works great, However when i use SCAP from 
> OpenSCAP SSG (example "ssg-rhel6-ds.xml”), i am getting error as 
> “sg-rhel6-ds. .zip :  sg-rhel6-ds.xml failed XML Schema validation” .
>
> I would like to what is the difference between openSSG scap data stream &  
> scap1.2 content downloaded from NIST repository. How i can convert openssg 
> data stream (Example - ssg-rhel6-ds.xml) to NIST scap 1.2 format.
>
>
> My objective - To use openscap SSG from Nessus. Nessus scap scanning expects 
> SCAP 1.0, 1.1 or 1.2 content(in zip format).
>
>
> Thanks in advance!
>
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Need help on openscap SSG question

[Jan Cerny]

Hi,

I have no idea. Does Nessus have any "verbose" mode to get more
helpful error message?

Including scap-security-guide list in this conversation because there
might be people familiar with using SSG with Nessus.

Regards

On Mon, Apr 29, 2019 at 4:54 PM Riaz Ebrahim  wrote:
>
> Hi Jan Cerny,
>
> Thanks a lot for your response, Your answer was very useful to understand 
> about SSG files. As per your advice i tried with 
> scap-security-guide-0.1.43-oval-510.zip  and XML validation error was gone, 
> but encountering new error as below from nessus
>
> "ssg-rhel6-ds-1.zip : Default namespace not found in OVAL"
>
> Do you get any clue by seeing this error?. Thanks in advance :)
>
> Thanks,
> Riaz
>
> On Mon, Apr 29, 2019 at 2:44 PM Jan Cerny  wrote:
>>
>> Hi,
>>
>> I will try to answer, but I don't use Nessus, so I'm not sure what is
>> the exact reason of this fail.
>>
>> In general, the SSG files are validated against SCAP XML schemas, so
>> they are valid SCAP content.
>> However, SCAP standard consist of multiple separate specifications.
>> Strictly speaking, the SSG datastream
>> doesn't conform to SCAP 1.2 specification, because the datastream
>> contains OVAL checks conforming to OVAL
>> version 5.11 which is a part of SCAP 1.3. For SCAP 1.2 conformance it
>> would need to use OVAL checks
>> in version 5.10 or older.
>>
>> According to this forum thread, it seems that Nessus doesn't support
>> OVAL 5.11 it yet, but they say it's planned to be updated
>> https://community.tenable.com/s/question/0D5f25hKRwqCAG/nessus-pro-7-trouble-getting-oval-scans-to-work
>>
>> It could be a problem that Nessus expects datastreams that  contain
>> OVAL 5.10 only.
>> Try using the SSG datastreams that contain OVAL 5.10 only. They can be
>> downloaded from
>> https://github.com/ComplianceAsCode/content/releases/download/v0.1.43/scap-security-guide-0.1.43-oval-510.zip
>> I hope Nessus should be able to consume these files.
>>
>> The reason why we use 5.11 is that it contains new checks that allows
>> us to check easily system services using systemd
>> and other new things introduced in RHEL 7. The aforementioned
>> datastreams that contain OVAL 5.10 only
>> have limited abilities in comparison with those containing OVAL 5.11.
>>
>> Best Regards
>>
>> Jan Černý
>> Security Technologies | Red Hat, Inc.
>>
>>
>> On Sat, Apr 27, 2019 at 6:34 AM Riaz Ebrahim  wrote:
>> >
>> > I need help on openscap SSG project.
>> >
>> > I am currently exploring SCAP Auditing feature from Nessus console. I 
>> > understood that Nessus supports SCAP Content (1.0 or 1.1 or 1.2) which can 
>> > be downloaded from NIST repository (https://nvd.nist.gov/ncp/repository) 
>> > based on the target host version. This works great, However when i use 
>> > SCAP from OpenSCAP SSG (example "ssg-rhel6-ds.xml”), i am getting error as 
>> > “sg-rhel6-ds. .zip :  sg-rhel6-ds.xml failed XML Schema validation” .
>> >
>> > I would like to what is the difference between openSSG scap data stream &  
>> > scap1.2 content downloaded from NIST repository. How i can convert openssg 
>> > data stream (Example - ssg-rhel6-ds.xml) to NIST scap 1.2 format.
>> >
>> >
>> > My objective - To use openscap SSG from Nessus. Nessus scap scanning 
>> > expects SCAP 1.0, 1.1 or 1.2 content(in zip format).
>> >
>> >
>> > Thanks in advance!
>> >
>> > ___
>> > Open-scap-list mailing list
>> > Open-scap-list@redhat.com
>> > https://www.redhat.com/mailman/listinfo/open-scap-list



--
Jan Černý
Security Technologies | Red Hat, Inc.

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] OVAL: join variables with empty value

[Jan Cerny]

Hi,

I'm afraid we hit the limitation of OVAL specification:
https://oval.mitre.org/language/version5.11/ovaldefinition/documentation/oval-definitions-schema.html#ObjectComponentType

> The required object_ref attribute provides a reference to an existing
OVAL Object declaration. The referenced OVAL Object specifies a set of OVAL
Items to collect. Note that an OVAL Object might identify 0, 1, or many
OVAL Items on a system. If no items are found on the system then an error
should be reported when determining the value of an ObjectComponentType. If
1 or more OVAL Items are found then each OVAL Item will be considered and
the ObjectComponentType may have one or more values.

I think that the workaround could be that the regular expression always
matches at least an empty string. Then I think the variable will not be
empty but it would contain an item that contains an empty string, so the
concatenation could proceed. I haven't tried it if it works, though.

Regards

On Fri, May 31, 2019 at 3:26 PM Ilya Okomin  wrote:

> Hi Team,
>
> I need some piece of advice how to implement join in OVAL for variables if
> some of them are empty .
>
> I'm looking at the existing example from master which uses
> -. However this code doesn't work as expected for empty
> variable var_rfg_include_config_regex in  - returned result "no
> value", while expected would be "%^/etc/rsyslog.conf$":
>
> https://github.com/ComplianceAsCode/content/blob/master/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_files_groupownership/oval/shared.xml#L43
>
> Note: UniqueFunctionType
> 
> looks more applicable here, but it doesn't work as well with the same
> reason - returned result is "no value" when one of variables is empty.
>
> Can any approach be suggested to avoid getting "no value" and return
> expected result for sample var_rfg_all_log_files_as_string_regex variable
> (with joined values from defined only variables/objects)?
>
> Regards,
> Ilya.
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list



-- 
Jan Černý
Security Technologies | Red Hat, Inc.
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

[Open-scap] OpenSCAP 1.3.1

[Jan Cerny]

Hello OpenSCAPers,

We are thrilled to announce general availability of OpenSCAP 1.3.1 release.

This is the latest release from maint-1.3 maintenance branch. API/ABI is
fully compatible with 1.3.0 release. Users of 1.3.x releases are
recommended to update.

Changes:
  - New features
- Support for SCAP 1.3 Source Datastreams (evaluating, XML schemas,
  validation)
- Introduced `oscap-podman` -- a tool for SCAP evaluation of Podman
  images and containers (rhbz#1642373)
- Tailoring files are included in ARF result files (#902)
- OVAL details are always shown in HTML report, users do not have to
  provide `--oval-results` on command line
- HTML report displays OVAL test details also for OVAL tests included
  from other OVAL definitions using `extend_definition` (#916, #954)
- OVAL test IDs are shown in HTML report
- Rule IDs are shown in HTML guide (#1293)
- Added `block_size` in Linux `partition_state` defined in OVAL 5.11.2
- Added `oscap_wrapper` that can be used to comfortably execute custom
  compiled oscap tool
  - Maintenance, bug fixes
- Remote filesystems mounted using `autofs` direct maps are not
  recognized as local filesystems (rhbz#1655943)
- SCAP source datastreams containing remote components can be
  evaluated without downloading remote data (rhbz#1709423)
- Fixed duplicated variables in generated Ansible Playbooks
- Fixed trailing whitespace characters in Ansible Playbooks
- Correctly handle multiline profile titles and profile descriptions
  in generated Ansible Playbooks (#1112)
- Fixed STIG Viewer output (--stig-viewer) to handle multiple rules
  that have the same STIG ID
- Fixed incorrect displaying of OVAL test results in HTML report
- Fixed segmentation fault in offline mode caused by usage of `chroot`
  file descriptor after closing (rhbz#1636431)
- Fixed textfilecontent54 probe to not ignore `max_depth`, `recurse`,
  `recurse_direction` and `recurse_file_system` attributes of
  `behaviors` element when `filepath` element is given (rhbz#1655943)
- Added CMake policies (CMP0078 and CMP0086) related to UseSWIG
- Added RHEL 8 CPE, Fedora 31 CPE, Oracle Linux 8 CPE
- Fedora CPEs fixed to work also on Fedora >= 30
- Fixed segmentation fault in CVRF module (rhbz#1642283)
- Fixed unresolved symbols in libopenscap_sce.so
- Fixed memory leaks in Windows registry probe (#1269)
- Fixed many GCC compiler warnings
- Removed dead code from `fsdev` module
- Many new test cases in upstream test suite
- Refactoring
- Updated Developer Guide
- Updated manual pages

Special thanks to our new contributors Chloe Lee, Dmitry Teselkin,
Evgeny Kolesnikov, Gabriel Gaspar Becker, Malte Kraus and Robert
Frohl.

Download:
https://github.com/OpenSCAP/openscap/releases/download/1.3.1/openscap-1.3.1.tar.gz

SHA512:
c42c59a19e3f71a4ef55daa82be7a2b66514dfe4a98b8e897a03d4785b25395a3508ff2457072d3ae123328a104cab054e64dcb52209ae77060542484439d859


Audit, Fix, And Be Merry!


Jan Černý
Security Technologies, Red Hat, Inc.
on behalf of OpenSCAP contributors

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] customize scap report

[Jan Cerny]

Hi,

You need to pass the ID of the customized profile in --profile instead
of the ID of the original profile.

The ID of the customized profile is the ID that Workbench prompted you
when you clicked on "Customize" button.
By default it's stig-rhel7-disa_customized. You can check by opening
the tailoring file in a text editor and checking "id" attribute of the
"Profile" element.

Regards

On Thu, Jul 4, 2019 at 4:19 PM Kenny Woodson  wrote:
>
> I'm attempting to run openscap and I was looking for some assistance for 
> customizing a security guide.
>
> I would like to disable options from the rhel7-stig-disa security guide.  For 
> example, we do not allow ssh to our image and therefore would like to disable 
> the check to install the screen package.
>
> I followed the instructions here:
> https://www.open-scap.org/resources/documentation/customizing-scap-security-guide-for-your-use-case/
>
> This allowed me to capture the customized tailoring-file.  With this file I 
> attempted to scan our image with the following command:
>
> oscap xccdf eval   --profile stig-rhel7-disa  \
>  --results /tmp/scap-results.xml \
>  --report /tmp/scap-report.html \
>  --tailoring-file /root/data/ssg-rhel7-ds-aro.xml \
>  --oval-results --fetch-remote-resources  \
>  --cpe /usr/share/xml/scap/ssg/content/ssg-rhel7-cpe-dictionary.xml 
> /usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml
>
> I admit that I am new to openscap and I'm not sure I understand each of the 
> options here but when viewing the results I continue to see that the screen
> check fails.  Is this behavior expected?
>
> Here is the option in my tailoring-file:
>  idref="xccdf_org.ssgproject.content_rule_package_screen_installed" 
> selected="false"/>
>
> I would appreciate some assistance or some explanation of how to achieve a 
> customized security guide.
>
> Thanks,
> kenny
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list



-- 
Jan Černý
Security Technologies | Red Hat, Inc.

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] openscap for windows?

[Jan Cerny]

Hi,

OpenSCAP can be run on Windows. The Windows installer can be downloaded from:
https://github.com/OpenSCAP/openscap/releases/download/1.3.1/OpenSCAP-1.3.1-win32.msi

However, the Windows version it contains only the 4 most used probes,
so it can scan only a few checks.

There is no integration with Satellite.


Regards

On Thu, Jul 11, 2019 at 8:49 AM Maurizio Pagani  wrote:
>
>
>
> Hi,
>
>
>
> i need to know if is possible scan windows machine, and if is possible to 
> import scap report (for example a report that generate a windows machine) to 
> satellite.
>
>
>
> Can somone help me?
>
>
>
> Thanks
>
>
>
> Maurizio
>
>
>
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list



-- 
Jan Černý
Security Technologies | Red Hat, Inc.

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Questions about OVAL

[Jan Cerny]

Hi,

On Tue, Aug 13, 2019 at 4:53 AM Tim Burress  wrote:
>
> Hello,
>
> I'm trying to learn my way around SCAP just now, with the main focus
> right now on scans of Linux-based systems using oscap and the related
> tools. I'm hitting a bit of a wall when it comes to writing OVAL content
> and just wondered if someone could point me to resources that unpack
> things from the perspective of someone accustomed to writing software in
> "normal" programming languages?

I'm not aware of any comprehensive book about that.

The official website can be a good start:
- https://oval.mitre.org/

We have created a tutorial for Red Hat Summit about ComplianceAsCode,
which also mentions OVAL:
- 
https://github.com/RedHatDemos/SecurityDemos/tree/master/2019Labs/CustomSecurityContent/documentation

>
> Some more-or-less specific questions:
>
> o In an object definition like this (condensed from OVAL found in SSG,
> where B is a local variable containing a set of file paths):
>
> 
> 
> ^0$
> 1
> 
>
> what is the function of var_check="at least one"? I assume that this is
> a condition being applied to the value of the variable B, saying that it
> must have at least one member, but what happens if the variable B is an
> empty set?

When var_check is set to "at least one" it means that for a file to be
matched its file path must be equal to at least one of the members of
variable B.

If the variable B is an empty set, the object will be evaluated as
"does not exist".

var_check is described here:
https://oval.mitre.org/language/version5.11/ovaldefinition/documentation/oval-definitions-schema.html
- search for var_check in section
EntityAttributeGroup.

>
> o Basic question: is the order in which entities appear in a file of
> OVAL content irrelevant? Given that they are all tagged with types and
> ID strings it seems like this would be the case, but OVAL is a new world
> where many things are not what they seem, so I thought I would check.

The order of objects, states, variables etc. is irrelevant. For
example, it doesn't matter if object id=1 is defined before or after
object id=2.

However, the order of different child elements matters. For example,
within  element the 
element must always be before  element. OpenSCAP will
tell you if you put elements in a wrong order, because it performs XML
validation each time.

>
> o Is there a tool that allows you to debug OVAL at runtime? That is,
> much like any other debugger, to set breakpoints and examine the values
> of objects/variables/etc at runtime?

We don't have any tool. We usually run OpenSCAP with --verbose, or we
generate the XML results and we analyse the results.

>
> o Is there a document/book/tutorial that guides a person through
> creating complex OVAL rules (preferably on Linux systems)? Most of the
> examples I've found on the web are of the very simple "Hello World"
> variety, so lead to more questions than they answer. Something that
> walks through even just how to *think* about solving problems in OVAL
> would be helpful at this point.

I also wish there was something like that. Try to get inspired by the
existing rules in SSG. If you have any further question, feel free to
ask here anytime.

Regards


>
> Thanks!
>
>
>
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list



-- 
Jan Černý
Security Technologies | Red Hat, Inc.

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] OpenSCAP web interface

[Jan Cerny]

Hi Gopal,

Red Hat Satellite provides a web interface for OpenSCAP.

See
https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/host_configuration_guide/chap-red_hat_satellite-host_configuration_guide-security_compliance_management_with_openscap

Watch the demo here: https://www.youtube.com/watch?v=p4uNlzYld-Y

Regards

On Tue, Dec 3, 2019 at 6:11 PM Peddabuddi, Gopal 
wrote:

> Hi,
>
>
>
> I am Gopal Peddabuddi, from NextEra Energy, we are planning to use
> OpenSCAP  with web interface option. We could not find proper documentation
> regarding web interface.
>
>
>
> We would like to take your support in getting web interface for OpenSCAP
> to scan the remote hosts.
>
>
>
> Thank you
>
> Gopal Peddabuddi
>
> Contract DevOps Engineer
>
> On behalf of KForce
>
> gopal.peddabu...@fpl.com
>
> Cell: 919-866-8342
>
>  [image: A]
>
>
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list



-- 
Jan Černý
Security Technologies | Red Hat, Inc.
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] make test fails on Debian 9 and Debian 10

[Jan Cerny]

Hi Bryan,

Thank you very much for reaching us.

In general, the tests aren't expected to fail. I think that the problem is
that the tests were written on Fedora, without considering other Linux
distributions. If a test fails, it doesn't necessarily mean that the tested
part of the OpenSCAP code doesn't work on Debian. It's more likely that
there is something specific for Fedora in the tests.

We welcome any patches that will fix the tests for Debian. Feel free to
open a pull request.

Fixing the tests will require deeper investigation. I suggest examining
each failing test individually.
To get detailed test results, you can run `ctest --verbose -R
name_of_the_test` in the build directory. Also, the test cases are Bash
scripts, so putting `set -x` at the beginning of each .sh file can help you
to debug.
If a test fails on "assert_exists" command, examine the results XML files
generated during the tests. Adding `--verbose INFO` to `oscap` calls in the
tests sometimes helps as well.

There can be various different things that can cause the failures. For
example, the tests can depend on something that doesn't exist on Debian,
eg. they read from /etc/fedora-release or consult the RPM database. Things
like that probably need to be replaced by something that exist on most of
Linux distributions, or the test will have to contain 2 variants depending
on the OS.
Also consider disabling the RPM-related tests on Debian.

Regards

On Mon, Dec 9, 2019 at 5:48 PM Bryan Schneiders 
wrote:

> I’m trying to build or fix OpenSCAP content for Debian 10.  I’m
> encountering problems with existing content for Debian 8 and 9.  To ensure
> I’m not running into known or fixed issues, I’m attempting to build the
> latest available openscap binaries since the Debian packages are old.
>
>
>
> When building the latest openscap on Debian 9 or 10, it fails several
> tests in `make test`.  I can run the failed tests individually and with
> more verbose output but it’s not obvious why each test fails.  Are these
> tests expected to fail? Are there known solutions?  Let me know what
> details I can provide or point me in the right direction to troubleshoot
> this deeper.  I’m happy to contribute in any way toward solutions if there
> are outstanding problems with some of the tests in this environment.
>
>
>
> I’m following the build instructions on
> https://github.com/OpenSCAP/openscap/blob/maint-1.3/docs/developer/developer.adoc
>
>
>
> This is the output from the end of `make test` on Debian 9:
>
>
>
> ```
>
> 94% tests passed, 10 tests failed out of 168
>
>
>
> Total Test time (real) = 290.80 sec
>
>
>
> The following tests FAILED:
>
>   13 - API/OVAL/unittests/all.sh (Failed)
>
>   77 - API/XCCDF/unittests/test_xccdf_transformation.sh (Not
> Run)
>
>   143 - probes/rpmverify/all.sh (Failed)
>
>   144 - probes/rpmverifyfile/all.sh (Failed)
>
>   145 -
> probes/rpmverifypackage/test_probes_rpmverifypackage.sh (Not Run)
>
>   146 - probes/runlevel/test_probes_runlevel.sh (Failed)
>
>   150 - probes/symlink/test_offline_mode_symlink.sh (Not Run)
>
>   151 - probes/sysctl/all.sh (Failed)
>
>   157 - probes/uname/test_probes_uname.sh (Failed)
>
>   159 - sce/test_sce.sh (Failed)
>
> Errors while running CTest
>
> Makefile:127: recipe for target 'test' failed
>
> make: *** [test] Error 8
>
> ```
>
>
>
> This is the output from the end of `make test` on Debian 10:
>
>
>
> ```
>
> 96% tests passed, 6 tests failed out of 167
>
>
>
> Total Test time (real) = 317.42 sec
>
>
>
> The following tests did not run:
>
>   145 -
> probes/rpmverifypackage/test_probes_rpmverifypackage.sh (Skipped)
>
>
>
> The following tests FAILED:
>
>   13 - API/OVAL/unittests/all.sh (Failed)
>
>   112 - DS/test_ds_misc.sh (Failed)
>
>   115 - DS/test_sds_eval.sh (Failed)
>
>   146 - probes/runlevel/test_probes_runlevel.sh (Failed)
>
>   150 - probes/sysctl/all.sh (Failed)
>
>   156 - probes/uname/test_probes_uname.sh (Failed)
>
> Errors while running CTest
>
> make: *** [Makefile:130: test] Error 8
>
> ```
>
>
>
> [image: TriSept Logo]
>
>
>
> *www.trisept.com *
>
> *Paul Bryan Schneiders*
>
> Principal Software Engineer
> 302-858-0329
>
> *pschneid...@trisept.com *
>
> *CONFIDENTIALITY NOTICE:* This e-mail, including attachments, is intended
> for the exclusive use of the person or entity to whom it is addressed and
> may contain confidential or privileged information. If the reader of this
> e-mail is not the intended recipient or his or her authorized agent, the
> reader is hereby notified that any dissemination, distribution or copying
> of this e-mail is prohibited. If you think that you have received this
> e-mail in error, please advise the sender by reply e-mail of the error and
> then delete this e-mail immediately.
>
>
>
>
> 

Re: [Open-scap] make test fails on Debian 9 and Debian 10

[Jan Cerny]

Hi,
Just a note: running tests is optional part of the build process, you can
skip the tests and proceed to install.

On Tue, Dec 10, 2019 at 1:00 PM Jan Cerny  wrote:

> Hi Bryan,
>
> Thank you very much for reaching us.
>
> In general, the tests aren't expected to fail. I think that the problem is
> that the tests were written on Fedora, without considering other Linux
> distributions. If a test fails, it doesn't necessarily mean that the tested
> part of the OpenSCAP code doesn't work on Debian. It's more likely that
> there is something specific for Fedora in the tests.
>
> We welcome any patches that will fix the tests for Debian. Feel free to
> open a pull request.
>
> Fixing the tests will require deeper investigation. I suggest examining
> each failing test individually.
> To get detailed test results, you can run `ctest --verbose -R
> name_of_the_test` in the build directory. Also, the test cases are Bash
> scripts, so putting `set -x` at the beginning of each .sh file can help you
> to debug.
> If a test fails on "assert_exists" command, examine the results XML files
> generated during the tests. Adding `--verbose INFO` to `oscap` calls in the
> tests sometimes helps as well.
>
> There can be various different things that can cause the failures. For
> example, the tests can depend on something that doesn't exist on Debian,
> eg. they read from /etc/fedora-release or consult the RPM database. Things
> like that probably need to be replaced by something that exist on most of
> Linux distributions, or the test will have to contain 2 variants depending
> on the OS.
> Also consider disabling the RPM-related tests on Debian.
>
> Regards
>
> On Mon, Dec 9, 2019 at 5:48 PM Bryan Schneiders 
> wrote:
>
>> I’m trying to build or fix OpenSCAP content for Debian 10.  I’m
>> encountering problems with existing content for Debian 8 and 9.  To ensure
>> I’m not running into known or fixed issues, I’m attempting to build the
>> latest available openscap binaries since the Debian packages are old.
>>
>>
>>
>> When building the latest openscap on Debian 9 or 10, it fails several
>> tests in `make test`.  I can run the failed tests individually and with
>> more verbose output but it’s not obvious why each test fails.  Are these
>> tests expected to fail? Are there known solutions?  Let me know what
>> details I can provide or point me in the right direction to troubleshoot
>> this deeper.  I’m happy to contribute in any way toward solutions if there
>> are outstanding problems with some of the tests in this environment.
>>
>>
>>
>> I’m following the build instructions on
>> https://github.com/OpenSCAP/openscap/blob/maint-1.3/docs/developer/developer.adoc
>>
>>
>>
>> This is the output from the end of `make test` on Debian 9:
>>
>>
>>
>> ```
>>
>> 94% tests passed, 10 tests failed out of 168
>>
>>
>>
>> Total Test time (real) = 290.80 sec
>>
>>
>>
>> The following tests FAILED:
>>
>>   13 - API/OVAL/unittests/all.sh (Failed)
>>
>>   77 - API/XCCDF/unittests/test_xccdf_transformation.sh (Not
>> Run)
>>
>>   143 - probes/rpmverify/all.sh (Failed)
>>
>>   144 - probes/rpmverifyfile/all.sh (Failed)
>>
>>   145 -
>> probes/rpmverifypackage/test_probes_rpmverifypackage.sh (Not Run)
>>
>>   146 - probes/runlevel/test_probes_runlevel.sh (Failed)
>>
>>   150 - probes/symlink/test_offline_mode_symlink.sh (Not Run)
>>
>>   151 - probes/sysctl/all.sh (Failed)
>>
>>   157 - probes/uname/test_probes_uname.sh (Failed)
>>
>>   159 - sce/test_sce.sh (Failed)
>>
>> Errors while running CTest
>>
>> Makefile:127: recipe for target 'test' failed
>>
>> make: *** [test] Error 8
>>
>> ```
>>
>>
>>
>> This is the output from the end of `make test` on Debian 10:
>>
>>
>>
>> ```
>>
>> 96% tests passed, 6 tests failed out of 167
>>
>>
>>
>> Total Test time (real) = 317.42 sec
>>
>>
>>
>> The following tests did not run:
>>
>>   145 -
>> probes/rpmverifypackage/test_probes_rpmverifypackage.sh (Skipped)
>>
>>
>>
>> The following tests FAILED:
>>
>>   13 - API/OVAL/unittests/all.sh (Failed)
>>
>>   112 - DS/test_ds_misc.sh (Failed)
>>
>>   115 - DS/test

Re: [Open-scap] OpenSCAP 1.3.3

[Jan Cerny]

Hi Fen,

On RHEL7 you can build OpenSCAP 1.3.3 from source code. Check [1] for
instructions. Unfortunately, RHEL 7 won't ship OpenSCAP 1.3.x  as a
RPM package, because OpenSCAP 1.3.x isn't API compatible with the
1.2.x versions.

But, OpenSCAP and SSG in RHEL7 should work together. There was a fix
[2] in RHEL7 for OpenSCAP to work with SCAP 1.3 data streams. Can you
tell us how your scans are broken?

Regards

[1] 
https://github.com/OpenSCAP/openscap/blob/maint-1.3/docs/developer/developer.adoc#building-openscap-on-linux
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1709423



On Mon, May 4, 2020 at 5:06 AM Fen Labalme  wrote:
>
> Awesome - great work - thank you!
>
> Is there an easy way to have 1.3.x installed on RHEL/7 instances? Yum is 
> installing 1.2.17 and since (the default) SSG 0.1.46 is now defaulting to 1.3 
> data streams, my scans are broken.
>
> Thanks again!
> =Fen
>
> CivicActions Inc. | Making Compliance Secure
> +1.412.996.4113 | civicactions.com
>
>
> On Sun, May 3, 2020 at 3:38 PM Evgeny Kolesnikov  wrote:
>>
>> Hello!
>>
>> We are proud to announce the OpenSCAP release 1.3.3. This release is
>> based on the main-1.3 branch, and it is backward-compatible
>> with 1.3.x releases.
>>
>> Notable improvements in this release:
>> - a Python script that can be used for CLI tailoring (autotailor)
>> (thank you, Matěj Týč);
>> - timezone for XCCDF TestResult start and end time (thank you, Jan Černý);
>> - new yamlfilecontent independent probe (draft implementation),
>>   see the proposal https://github.com/OVAL-Community/OVAL/issues/91
>>   for additional information.
>>
>> There are other changes as well, here is the list:
>> - Introduced `urn:xccdf:fix:script:kubernetes` fix type in XCCDF;
>> - Added ability to generate `machineconfig` fix;
>> - Detect ambiguous scan target (utils/oscap-podman);
>> - Fixed #170: The rpmverifyfile probe can't verify files from '/bin' 
>> directory;
>> - The data system_info probe return for offline and online modes is
>> consistent and actual;
>> - Prevent crashes when complicated regexes are executed in
>> textfilecontent58 probe;
>> - Fixed #1512: Severity refinement lost in generated guide;
>> - Fixed #1453: Pointer lost in Swig API;
>> - Evaluation Characteristics of the XCCDF report are now consistent
>> with OVAL entities;
>>   from system_info probe;
>> - Fixed filepath pattern matching in offline mode in textfilecontent58 probe;
>> - Fixed infinite recursion in systemdunitdependency probe;
>> - Fixed the case when CMake couldn't find libacl or xattr.h.
>>
>> Also thanks to all our contributors, who helped to make this release.
>>
>> Download:
>> https://github.com/OpenSCAP/openscap/archive/1.3.3.tar.gz
>>
>> SHA512:
>> e230668cdf900a2f31ccabc20787dce6c4174740aa7d2cc7b91c1c095e2a5b73d81bb614aa767d2e51383b5472def360c4204e9a6c4c85110c58b566613e
>>
>> Enjoy!
>>
>> On behalf of OpenSCAP contributors
>>
>> Evgenii Kolesnikov,
>> Red Hat, Inc.
>>
>>
>> ___
>> Open-scap-list mailing list
>> Open-scap-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/open-scap-list
>
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list



--
Jan Černý
Security Technologies | Red Hat, Inc.


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

[Open-scap] OpenSCAP 1.3.3 COPR builds are available for RHEL 7 and RHEL 8

[Jan Cerny]

Hi,

We have received feedback from multiple people that they want to try
the latest OpenSCAP 1.3.3 on their RHEL 7 and RHEL 8 systems.
Therefore, we have added OpenSCAP 1.3.3 builds for RHEL 7 and RHEL 8
to our COPR account:

https://copr.fedorainfracloud.org/coprs/openscapmaint/openscap-latest/

Installation on RHEL 8:

dnf copr enable openscapmaint/openscap-latest
dnf install openscap-utils

Installation on RHEL 7:

wget 
http://copr.fedoraproject.org/coprs/openscapmaint/openscap-latest/repo/epel-7/openscapmaint-openscap-latest-epel-7.repo
-O /etc/yum.repos.d/openscapmaint-openscap-latest-epel-7.repo
yum install openscap-utils

Note that software in COPR is only for testing purposes and is NOT
supported by Red Hat.

Regards

-- 
Jan Černý
Security Technologies | Red Hat, Inc.


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list