From pravin.goyal at outlook.com Wed Feb 1 08:22:08 2017 From: pravin.goyal at outlook.com (Pravin Goyal) Date: Wed, 1 Feb 2017 08:22:08 +0000 Subject: [Open-scap] Referencing variable in an object Message-ID: Hi All, I have a requirement to check that all system accounts are locked. So, I need to get the username from /etc/passwd file based on UIDs (<500) and then check the /etc/shadow file that the password field has either * or !. This is the definition: None None 5.11 2017-02-04T12:32:41 Ensure System Accounts are disabled This rule verifies that the system accounts are disabled. .* oval:test.test.com:ste:9 ^(!?!|[\*]) 500 The execution goes fine. But, the result is not correct. When I check the results file, I see below: root daemon bin sys sync games man lp mail news uucp proxy www-data backup list irc gnats libuuid syslog messagebus landscape sshd pollinate mongodb colord tomcat7 Now, my question is why does the flag say "does not exist" even though the variables are getting populated? Please help. Thanks and regards, Pravin Goyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsprudencio at redhat.com Fri Feb 3 16:28:17 2017 From: rsprudencio at redhat.com (Raphael Sanchez Prudencio) Date: Fri, 3 Feb 2017 17:28:17 +0100 Subject: [Open-scap] Windows Support Message-ID: <709a1271-53a1-cceb-f8e0-6d1073a69438@redhat.com> 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. 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. 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! 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. 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'd like to hear feedback from our users, developers, maintainers, everyone. Thanks -- Raphael Sanchez Prudencio Security Technologies | Red Hat, Inc. From pravin.goyal at outlook.com Sun Feb 5 14:40:57 2017 From: pravin.goyal at outlook.com (Pravin Goyal) Date: Sun, 5 Feb 2017 14:40:57 +0000 Subject: [Open-scap] oscap-docker on Ubuntu 14.04 Message-ID: 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 at 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_iflisteners rpmverify probe_rpmverify rpmverifyfile probe_rpmverifyfile rpmverifypackage probe_rpmverifypackage selinuxboolean probe_selinuxboolean selinuxsecuritycontext probe_selinuxsecuritycontext systemdunitproperty probe_systemdunitproperty systemdunitdependency probe_systemdunitdependency 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 routingtable probe_routingtable symlink probe_symlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From pravin.goyal at outlook.com Sun Feb 5 14:53:15 2017 From: pravin.goyal at outlook.com (Pravin Goyal) Date: Sun, 5 Feb 2017 14:53:15 +0000 Subject: [Open-scap] oscap-docker on Ubuntu 14.04 In-Reply-To: References: Message-ID: However, on the machine I do see openscap-python is present: ubuntu at 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 at 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 at 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_iflisteners rpmverify probe_rpmverify rpmverifyfile probe_rpmverifyfile rpmverifypackage probe_rpmverifypackage selinuxboolean probe_selinuxboolean selinuxsecuritycontext probe_selinuxsecuritycontext systemdunitproperty probe_systemdunitproperty systemdunitdependency probe_systemdunitdependency 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 routingtable probe_routingtable symlink probe_symlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcerny at redhat.com Mon Feb 6 14:51:02 2017 From: jcerny at redhat.com (Jan Cerny) Date: Mon, 6 Feb 2017 09:51:02 -0500 (EST) Subject: [Open-scap] oscap-docker on Ubuntu 14.04 In-Reply-To: References: Message-ID: <1184604492.26201602.1486392662123.JavaMail.zimbra@redhat.com> 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 at 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 at 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 at 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 at 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_iflisteners > rpmverify probe_rpmverify > rpmverifyfile probe_rpmverifyfile > rpmverifypackage probe_rpmverifypackage > selinuxboolean probe_selinuxboolean > selinuxsecuritycontext probe_selinuxsecuritycontext > systemdunitproperty probe_systemdunitproperty > systemdunitdependency probe_systemdunitdependency > 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 > routingtable probe_routingtable > symlink probe_symlink > > > > > > > _______________________________________________ > Open-scap-list mailing list > Open-scap-list at redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list From jcerny at redhat.com Tue Feb 7 08:11:26 2017 From: jcerny at redhat.com (Jan Cerny) Date: Tue, 7 Feb 2017 03:11:26 -0500 (EST) Subject: [Open-scap] oscap-docker on Ubuntu 14.04 In-Reply-To: References: <1184604492.26201602.1486392662123.JavaMail.zimbra@redhat.com> Message-ID: <476982224.26617667.1486455086390.JavaMail.zimbra@redhat.com> 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 at 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 at 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 at 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 at 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 at 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_iflisteners > > rpmverify probe_rpmverify > > rpmverifyfile probe_rpmverifyfile > > rpmverifypackage probe_rpmverifypackage > > selinuxboolean probe_selinuxboolean > > selinuxsecuritycontext probe_selinuxsecuritycontext > > systemdunitproperty probe_systemdunitproperty > > systemdunitdependency probe_systemdunitdependency > > 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 > > routingtable probe_routingtable > > symlink probe_symlink > > > > > > > > > > > > > > _______________________________________________ > > Open-scap-list mailing list > > Open-scap-list at redhat.com > > https://www.redhat.com/mailman/listinfo/open-scap-list > From jcerny at redhat.com Tue Feb 7 09:33:22 2017 From: jcerny at redhat.com (Jan Cerny) Date: Tue, 7 Feb 2017 04:33:22 -0500 (EST) Subject: [Open-scap] Windows Support In-Reply-To: <709a1271-53a1-cceb-f8e0-6d1073a69438@redhat.com> References: <709a1271-53a1-cceb-f8e0-6d1073a69438@redhat.com> Message-ID: <1599867573.26640229.1486460002759.JavaMail.zimbra@redhat.com> Hi, ----- Original Message ----- > From: "Raphael Sanchez Prudencio" > To: open-scap-list at 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'd like to hear feedback from our users, > developers, maintainers, everyone. Yes, I agree. I encourage everyone from the community to reply to this thread. Thanks for your replies. Best regards Jan ?ern? Security Technologies | Red Hat, Inc. From zmoravec at redhat.com Tue Feb 7 13:42:20 2017 From: zmoravec at redhat.com (Zbynek Moravec) Date: Tue, 7 Feb 2017 08:42:20 -0500 (EST) Subject: [Open-scap] Windows Support In-Reply-To: <1599867573.26640229.1486460002759.JavaMail.zimbra@redhat.com> References: <709a1271-53a1-cceb-f8e0-6d1073a69438@redhat.com> <1599867573.26640229.1486460002759.JavaMail.zimbra@redhat.com> Message-ID: <669364474.101496487.1486474940748.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Jan Cerny" > To: rsprudencio at redhat.com, "open-scap-list" > Sent: Tuesday, February 7, 2017 10:33:22 AM > Subject: Re: [Open-scap] Windows Support > > Hi, > > ----- Original Message ----- > > From: "Raphael Sanchez Prudencio" > > To: open-scap-list at 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. +1. C++ is not so cool when you still need to use openscap C structures in C++, but if you would have nice interface in probes, C++ could be great. > > > > > > > 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'd like to hear feedback from our users, > > developers, maintainers, everyone. > > Yes, I agree. I encourage everyone from the community to reply to this > thread. > Thanks for your replies. > > > Best regards > > Jan ?ern? > Security Technologies | Red Hat, Inc. > > > _______________________________________________ > Open-scap-list mailing list > Open-scap-list at redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list From bharath_mohanraj_tp at bmc.com Wed Feb 8 06:34:19 2017 From: bharath_mohanraj_tp at bmc.com (Mohanraj, Bharath) Date: Wed, 8 Feb 2017 06:34:19 +0000 Subject: [Open-scap] Open SCAP for Windows Message-ID: <99f6868f9a2d4bad90e2fcab6f7cec85@phx-exmbprd-02.adprod.bmc.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bharath_mohanraj_tp at bmc.com Wed Feb 8 06:38:02 2017 From: bharath_mohanraj_tp at bmc.com (Mohanraj, Bharath) Date: Wed, 8 Feb 2017 06:38:02 +0000 Subject: [Open-scap] Open SCAP for Windows Message-ID: <80f04833288348bb82d8504af1d19c05@phx-exmbprd-02.adprod.bmc.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcerny at redhat.com Thu Feb 9 08:24:31 2017 From: jcerny at redhat.com (Jan Cerny) Date: Thu, 9 Feb 2017 03:24:31 -0500 (EST) Subject: [Open-scap] Open SCAP for Windows In-Reply-To: <99f6868f9a2d4bad90e2fcab6f7cec85@phx-exmbprd-02.adprod.bmc.com> References: <99f6868f9a2d4bad90e2fcab6f7cec85@phx-exmbprd-02.adprod.bmc.com> Message-ID: <1466367415.27686086.1486628671579.JavaMail.zimbra@redhat.com> 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/msg00001.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 at 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 at redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list From chartwel at redhat.com Thu Feb 9 12:20:44 2017 From: chartwel at redhat.com (Calvin Hartwell) Date: Thu, 9 Feb 2017 12:20:44 +0000 Subject: [Open-scap] Windows Support In-Reply-To: <709a1271-53a1-cceb-f8e0-6d1073a69438@redhat.com> References: <709a1271-53a1-cceb-f8e0-6d1073a69438@redhat.com> Message-ID: 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. 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! +1 for this, I assume you are going to use native win32 api? Have you started a branch for this? I am pretty interested. Cheers, - Calvin On Fri, Feb 3, 2017 at 4:28 PM, Raphael Sanchez Prudencio < rsprudencio at redhat.com> wrote: > 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. > > 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. 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! > > > 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. > > > 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'd like to hear feedback from our users, > developers, maintainers, everyone. > > > Thanks > -- > Raphael Sanchez Prudencio > Security Technologies | Red Hat, Inc. > > _______________________________________________ > Open-scap-list mailing list > Open-scap-list at redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list > -- ------------------------------ Calvin Hartwell *Red Hat, Inc.* |Infrastructure Consultant - EMEA GPS Peninsular House, 30-36 Monument Street, 4th Floor, London, EC3R 8NB. *? Mobile:* +44 (0) 7917052881 | *? Email: calvin.hartwell at redhat.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsprudencio at redhat.com Thu Feb 9 12:38:42 2017 From: rsprudencio at redhat.com (Raphael Sanchez Prudencio) Date: Thu, 9 Feb 2017 13:38:42 +0100 Subject: [Open-scap] Windows Support In-Reply-To: References: <709a1271-53a1-cceb-f8e0-6d1073a69438@redhat.com> Message-ID: Hello Calvin, On 02/09/2017 01:20 PM, Calvin Hartwell wrote: > 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. 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! > > +1 for this, I assume you are going to use native win32 api? Yes, we'll use native WIN32 API for Windows objects. > > Have you started a branch for this? I am pretty interested. I'm going to make pull request in master branch for now, but we can create a specific branch for that as well. Nice to see more people interested on this effort :) > > Cheers, > > - Calvin > > On Fri, Feb 3, 2017 at 4:28 PM, Raphael Sanchez Prudencio > > wrote: > > 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. > > 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. 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! > > > 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. > > > 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'd like to hear feedback from our users, > developers, maintainers, everyone. > > > Thanks > -- > Raphael Sanchez Prudencio > Security Technologies | Red Hat, Inc. > > _______________________________________________ > Open-scap-list mailing list > Open-scap-list at redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list > > > > > > -- > > > ------------------------------------------------------------------------ > > Calvin Hartwell > > *Red Hat, Inc.* |Infrastructure Consultant - EMEA GPS > > Peninsular House, 30-36 Monument Street, 4th Floor, London, EC3R 8NB. > > *? Mobile:*+44 (0) 7917052881 | *? Email: calvin.hartwell at redhat.com > * > -- Raphael Sanchez Prudencio Security Technologies | Red Hat, Inc. From bharath_mohanraj_tp at bmc.com Thu Feb 9 09:02:37 2017 From: bharath_mohanraj_tp at bmc.com (Mohanraj, Bharath) Date: Thu, 9 Feb 2017 09:02:37 +0000 Subject: [Open-scap] Open SCAP for Windows In-Reply-To: <1466367415.27686086.1486628671579.JavaMail.zimbra@redhat.com> References: <99f6868f9a2d4bad90e2fcab6f7cec85@phx-exmbprd-02.adprod.bmc.com> <1466367415.27686086.1486628671579.JavaMail.zimbra@redhat.com> Message-ID: Thankyou for the detailed explanation, Jan. I will discuss this with my team here and will get back to you. Regards, Bharath M -----Original Message----- From: Jan Cerny [mailto:jcerny at redhat.com] Sent: Thursday, February 09, 2017 1:55 PM To: Mohanraj, Bharath Cc: open-scap-list at redhat.com Subject: Re: [Open-scap] Open SCAP for Windows 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.open-2Dscap.org_security-2Dpolicies_scap-2Dsecurity-2Dguide_&d=CwIFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=AUaowh4kDgwmfFF8B9dpIGVcrfeOZDaHu6Di1CZTnp4&m=6wh69S7-VLPd67PefRgUWaRDngvqyBGwloUIiu1ULIk&s=QC_FyHkeZSYVA_RXoHaPl4jFZoZjPVnQd8fkg5lyqKY&e= [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_archives_open-2Dscap-2Dlist_2017-2DFebruary_msg00001.html&d=CwIFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=AUaowh4kDgwmfFF8B9dpIGVcrfeOZDaHu6Di1CZTnp4&m=6wh69S7-VLPd67PefRgUWaRDngvqyBGwloUIiu1ULIk&s=Xnyuu2a6RIG98NTFRr_UsUjTVoaSGK_7LPS4DN6UDqg&e= 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 at 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 at redhat.com > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_listinfo_open-2Dscap-2Dlist&d=CwIFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=AUaowh4kDgwmfFF8B9dpIGVcrfeOZDaHu6Di1CZTnp4&m=6wh69S7-VLPd67PefRgUWaRDngvqyBGwloUIiu1ULIk&s=On5li6cvuSS9drcI1cgw5VT5hUgcCgJFj5t76juvBwc&e= From rsanders at forcepoint.com Fri Feb 10 15:50:18 2017 From: rsanders at forcepoint.com (Robert Sanders) Date: Fri, 10 Feb 2017 15:50:18 +0000 Subject: [Open-scap] Kickstart with SCAP tailoring Message-ID: <848FB1215E2AD643A5E10D906091D3FBF58B8486@TCSEXCH1.tcs-sec.com> Morning all, Have a quick question - I'm looking at using a kickstart file to automate our OS install, but I also want to use the SCAP plugin to handle the initial lockdown of our images. Looking at the 'tailoring-path' option to the anaconda plugin looks promising, but the docs indicate that the path for this option is relative to the archive being used. Is there a way to specify the path so that it will the path from the 'floppy' image I'm using (currently booting by adding "linux ks=hd:fd0:ks.cfg"), or do I need to stand everything up as an http/https/ftp server and reference the SCAP contents and my tailoring file that way? -Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshua.lubell at nist.gov Mon Feb 13 19:32:04 2017 From: joshua.lubell at nist.gov (Lubell, Joshua (Fed)) Date: Mon, 13 Feb 2017 19:32:04 +0000 Subject: [Open-scap] Windows Support In-Reply-To: References: <709a1271-53a1-cceb-f8e0-6d1073a69438@redhat.com> Message-ID: I'm excited about the planned Windows support! My particular interest relates to the SCAP Security Guide project. Specifically, I would like to be able to experiment with the SSG source and possibly contribute to SSG in the future. However, I currently use Windows for all my XML-related development, writing, etc. It would be great for me if I could install a limited-functionality oscap executable that doesn't do scanning, but does what is needed to build the SSG. In other words, all I need is to be able to validate datastreams and components, compose and split datastreams, and generate HTML guides from XCCDF. I have two questions: 1. Is there a way I can easily build such an oscap executable now? Cygwin would be OK, but I've tried building using the instructions in section 5.4 of OpenSCAP User Manual without success. It appears to me that these instructions are out of sync with the latest release and current master branch on GitHub, in that they say to run configure with the currently-nonexistent --disable-probes option. 2. I get the sense that the planned overhaul of the probes system is a big undertaking and won't be ready for a while. Would it be helpful for me to submit a new openscap issue requesting an interim limited-functionality Cygwin or w32 oscap executable as a shorter-term solution for those of us who are interested primarily in XML transformation/validation? Thanks for considering these questions/requests. For me, a limited-functionality oscap-for-Windows would be an excellent complement to SCAP Workbench. -Josh Joshua Lubell National Institute of Standards and Technology 100 Bureau Drive, Stop 8260 Gaithersburg MD 20899-8260 USA > -----Original Message----- > From: open-scap-list-bounces at redhat.com [mailto:open-scap-list- > bounces at redhat.com] On Behalf Of Raphael Sanchez Prudencio > Sent: Thursday, February 09, 2017 7:39 AM > To: Calvin Hartwell > Cc: open-scap-list at redhat.com > Subject: Re: [Open-scap] Windows Support > > Hello Calvin, > > On 02/09/2017 01:20 PM, Calvin Hartwell wrote: > > 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. 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! > > > > +1 for this, I assume you are going to use native win32 api? > Yes, we'll use native WIN32 API for Windows objects. > > > > Have you started a branch for this? I am pretty interested. > I'm going to make pull request in master branch for now, but we can create a > specific branch for that as well. Nice to see more people interested on this > effort :) > > > > Cheers, > > > > - Calvin > > > > On Fri, Feb 3, 2017 at 4:28 PM, Raphael Sanchez Prudencio > > > wrote: > > > > 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. > > > > 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. 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! > > > > > > 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. > > > > > > 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'd like to hear feedback from our users, > > developers, maintainers, everyone. > > > > > > Thanks > > -- > > Raphael Sanchez Prudencio > > Security Technologies | Red Hat, Inc. > > > > _______________________________________________ > > Open-scap-list mailing list > > Open-scap-list at redhat.com > > https://www.redhat.com/mailman/listinfo/open-scap-list > > > > > > > > > > > > -- > > > > > > ---------------------------------------------------------------------- > > -- > > > > Calvin Hartwell > > > > *Red Hat, Inc.* |Infrastructure Consultant - EMEA GPS > > > > Peninsular House, 30-36 Monument Street, 4th Floor, London, EC3R 8NB. > > > > *? Mobile:*+44 (0) 7917052881 | *? Email: calvin.hartwell at redhat.com > > * > > > > -- > Raphael Sanchez Prudencio > Security Technologies | Red Hat, Inc. > > _______________________________________________ > Open-scap-list mailing list > Open-scap-list at redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list From wsato at redhat.com Tue Feb 14 10:15:05 2017 From: wsato at redhat.com (Watson Yuuma Sato) Date: Tue, 14 Feb 2017 11:15:05 +0100 Subject: [Open-scap] Windows Support In-Reply-To: References: <709a1271-53a1-cceb-f8e0-6d1073a69438@redhat.com> Message-ID: <27180a21-21ab-193b-df3d-7bf0d489e4c4@redhat.com> On 13/02/17 20:32, Lubell, Joshua (Fed) wrote: > I'm excited about the planned Windows support! Hi, happy to hear that. > > My particular interest relates to the SCAP Security Guide project. Specifically, I would like to be able to experiment with the SSG source and possibly contribute to SSG in the future. However, I currently use Windows for all my XML-related development, writing, etc. It would be great for me if I could install a limited-functionality oscap executable that doesn't do scanning, but does what is needed to build the SSG. In other words, all I need is to be able to validate datastreams and components, compose and split datastreams, and generate HTML guides from XCCDF. > > I have two questions: > > 1. Is there a way I can easily build such an oscap executable now? Cygwin would be OK, but I've tried building using the instructions in section 5.4 of OpenSCAP User Manual without success. It appears to me that these instructions are out of sync with the latest release and current master branch on GitHub, in that they say to run configure with the currently-nonexistent --disable-probes option. Never tried Cygwin builds, it might be some issue with the environment, as --disable-probes option still exists. Another option is to cross-compile OpenSCAP. The OpenSCAP library used by SCAP Workbench is built this way. Section 5.6 [1] of manual details how to do it, or you might want to check Section 1 of SCAP Workbench Windows build guide[2]. > > 2. I get the sense that the planned overhaul of the probes system is a big undertaking and won't be ready for a while. Would it be helpful for me to submit a new openscap issue requesting an interim limited-functionality Cygwin or w32 oscap executable as a shorter-term solution for those of us who are interested primarily in XML transformation/validation? > > Thanks for considering these questions/requests. For me, a limited-functionality oscap-for-Windows would be an excellent complement to SCAP Workbench. > > -Josh > > Joshua Lubell > National Institute of Standards and Technology > 100 Bureau Drive, Stop 8260 > Gaithersburg MD 20899-8260 USA > > _______________________________________________ > Open-scap-list mailing list > Open-scap-list at redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list [1] https://github.com/OpenSCAP/openscap/blob/maint-1.0/docs/manual/manual.adoc#56-building-openscap-for-windows-cross-compilation [2] https://github.com/OpenSCAP/scap-workbench/wiki/Windows-build-and-installer-guide#1-install-openscap-from-master -- Watson Sato Security Technologies | Red Hat, Inc From joshua.lubell at nist.gov Mon Feb 13 16:49:06 2017 From: joshua.lubell at nist.gov (Lubell, Joshua (Fed)) Date: Mon, 13 Feb 2017 16:49:06 +0000 Subject: [Open-scap] Windows Support In-Reply-To: References: <709a1271-53a1-cceb-f8e0-6d1073a69438@redhat.com> Message-ID: I'm excited about the planned Windows support! My particular interest relates to the SCAP Security Guide project. Specifically, I would like to be able to experiment with the SSG source and possibly contribute to SSG in the future. However, I currently use Windows for all my XML-related development, writing, etc. It would be great for me if I could install a limited-functionality oscap executable that doesn't do scanning, but does what is needed to build the SSG. In other words, all I need is to be able to validate datastreams and components, compose and split datastreams, and generate an HTML guides from XCCDF. I have two questions: 1. Is there a way I can easily build such an oscap executable now? Cygwin would be OK, but I've tried building using the instructions in section 5.4 of OpenSCAP User Manual without success. I realize that that these instructions are out of sync with the latest release and current master branch on GitHub, in that they say to run configure with the currently-nonexistent --disable-probes option. 2. I get the sense that the planned overhaul of the probes system is a big undertaking and won't be ready for a while. Would it be appropriate for me to submit a new openscap issue requesting an interim limited-functionality Cygwin or w32 oscap executable as a shorter-term solution for those of us who are interested primarily in XML transformation/validation? Thanks for considering these questions/requests. For me, a limited-functionality oscap-for-Windows would be an excellent addition to SCAP Workbench. -Josh Joshua Lubell National Institute of Standards and Technology 100 Bureau Drive, Stop 8260 Gaithersburg MD 20899-8260 USA > -----Original Message----- > From: open-scap-list-bounces at redhat.com [mailto:open-scap-list- > bounces at redhat.com] On Behalf Of Raphael Sanchez Prudencio > Sent: Thursday, February 09, 2017 7:39 AM > To: Calvin Hartwell > Cc: open-scap-list at redhat.com > Subject: Re: [Open-scap] Windows Support > > Hello Calvin, > > On 02/09/2017 01:20 PM, Calvin Hartwell wrote: > > 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. 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! > > > > +1 for this, I assume you are going to use native win32 api? > Yes, we'll use native WIN32 API for Windows objects. > > > > Have you started a branch for this? I am pretty interested. > I'm going to make pull request in master branch for now, but we can create a > specific branch for that as well. Nice to see more people interested on this > effort :) > > > > Cheers, > > > > - Calvin > > > > On Fri, Feb 3, 2017 at 4:28 PM, Raphael Sanchez Prudencio > > > wrote: > > > > 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. > > > > 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. 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! > > > > > > 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. > > > > > > 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'd like to hear feedback from our users, > > developers, maintainers, everyone. > > > > > > Thanks > > -- > > Raphael Sanchez Prudencio > > Security Technologies | Red Hat, Inc. > > > > _______________________________________________ > > Open-scap-list mailing list > > Open-scap-list at redhat.com > > https://www.redhat.com/mailman/listinfo/open-scap-list > > > > > > > > > > > > -- > > > > > > ---------------------------------------------------------------------- > > -- > > > > Calvin Hartwell > > > > *Red Hat, Inc.* |Infrastructure Consultant - EMEA GPS > > > > Peninsular House, 30-36 Monument Street, 4th Floor, London, EC3R 8NB. > > > > *? Mobile:*+44 (0) 7917052881 | *? Email: calvin.hartwell at redhat.com > > * > > > > -- > Raphael Sanchez Prudencio > Security Technologies | Red Hat, Inc. > > _______________________________________________ > Open-scap-list mailing list > Open-scap-list at redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list From Brandon.Westover at ellucian.com Wed Feb 15 17:35:24 2017 From: Brandon.Westover at ellucian.com (Westover, Brandon) Date: Wed, 15 Feb 2017 17:35:24 +0000 Subject: [Open-scap] OpenScap Scanner on Windows Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwallace at ramlabs.com Wed Feb 15 19:43:10 2017 From: bwallace at ramlabs.com (Brooke Wallace) Date: Wed, 15 Feb 2017 19:43:10 +0000 Subject: [Open-scap] Git clone build fails in autogen.sh Message-ID: <3634DB8ABD61FB48A0AC3D017E9C37A855E2108A@ORD2MBX09A.mex05.mlsrvr.com> 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwallace at ramlabs.com Wed Feb 15 20:57:48 2017 From: bwallace at ramlabs.com (Brooke Wallace) Date: Wed, 15 Feb 2017 20:57:48 +0000 Subject: [Open-scap] Git clone build fails in autogen.sh In-Reply-To: <3634DB8ABD61FB48A0AC3D017E9C37A855E2108A@ORD2MBX09A.mex05.mlsrvr.com> References: <3634DB8ABD61FB48A0AC3D017E9C37A855E2108A@ORD2MBX09A.mex05.mlsrvr.com> Message-ID: <3634DB8ABD61FB48A0AC3D017E9C37A855E210AB@ORD2MBX09A.mex05.mlsrvr.com> 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 at 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsanders at forcepoint.com Thu Feb 16 14:15:30 2017 From: rsanders at forcepoint.com (Robert Sanders) Date: Thu, 16 Feb 2017 14:15:30 +0000 Subject: [Open-scap] Kickstart with SCAP tailoring In-Reply-To: <848FB1215E2AD643A5E10D906091D3FBF58B8486@TCSEXCH1.tcs-sec.com> References: <848FB1215E2AD643A5E10D906091D3FBF58B8486@TCSEXCH1.tcs-sec.com> Message-ID: <848FB1215E2AD643A5E10D906091D3FBF58BB35B@TCSEXCH1.tcs-sec.com> Updating with some extra testing - crossposted from the scap-security-guide list.... The initial work I was doing was just using a floppy to provide both the kickstart and the tailoring file from scap-workbench. We've migrated to having a full bootable ISO remastered from the RHEL 7.3 install media instead, with our tailoring file added as an extra RPM to be installed. I finally managed some syntax on the oscap addon that didn't raise an exception using this: %addon org_fedora_oscap content-type = scap-security-guide profile = ospp-rhel7-server tailoring-path = ../../usr/share/xml/scap/custom/tailoring.xml %end But after the system installs my modified banner is not present. Looking at the logs it appears that the tailoring path was completely ignored. I re-installed the system and dropped to one of the alternate windows to see exactly what oscap command was being executed and it was this: oscap xccdf eval --remediate --results=/root/openscap_data/eval_remediate_results.xml --profile=ospp-rhel7-server tailoring-file=/usr/share/xml/scap/custom/tailoring.xml /usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml While it runs apparently without error messages - I've noticed several things: 1) my tailoring is never used - just the steps from the profile 2) it looks like some of the 'kickstart actions' are not being done - if I understand the USGCB profile, it has an action for installing the 'screen' package if needed, but this is not happening at kickstart. I just found a bug in the oscap anacoonda addon (https://github.com/OpenSCAP/oscap-anaconda-addon/issues/16) that seems to confirm this, at least for RHEL 7.3 which we are using. 3) If I run the above command from a 'live' system (with or without the tailoring line) it still ignores the tailoring and there is an quick message is displayed - 'This content points out to the remote resources. Use `--fetch-remote-resources` option to download them.' If I provide an incorrect filename for the tailoring it does error without doing any other actions. So far the only way I've been able to have my tailoring file used is to use a command similar to what scap-workbench displays in the 'dry-run' option - and that command uses the datastream flavor of commands not the xccdf flavor. So it seems if I want to have tailoring done using the plugin I have to use the datastream content, which I can't because these systems will be totally isolated at configuration. None of this is a hard show-stopper, but it means that the oscap plugin is not usable as it stands. Right now I don't have time to delve deeper into the plugin (although I have pulled the source to try and understand it better). -RobFrom: open-scap-list-bounces at redhat.com [open-scap-list-bounces at redhat.com] on behalf of Robert Sanders [rsanders at forcepoint.com] Sent: Friday, February 10, 2017 10:50 AM To: open-scap-list at redhat.com Subject: EXTERNAL: [Open-scap] Kickstart with SCAP tailoring Morning all, Have a quick question - I'm looking at using a kickstart file to automate our OS install, but I also want to use the SCAP plugin to handle the initial lockdown of our images. Looking at the 'tailoring-path' option to the anaconda plugin looks promising, but the docs indicate that the path for this option is relative to the archive being used. Is there a way to specify the path so that it will the path from the 'floppy' image I'm using (currently booting by adding "linux ks=hd:fd0:ks.cfg"), or do I need to stand everything up as an http/https/ftp server and reference the SCAP contents and my tailoring file that way? -Rob Scanned by Forcepoint Email Security Gateway Click here to report this email as spam -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsprudencio at redhat.com Thu Feb 16 14:33:19 2017 From: rsprudencio at redhat.com (Raphael Sanchez Prudencio) Date: Thu, 16 Feb 2017 15:33:19 +0100 Subject: [Open-scap] OpenScap Scanner on Windows In-Reply-To: References: Message-ID: 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 at redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list > -- Raphael Sanchez Prudencio Security Technologies | Red Hat, Inc. From rsprudencio at redhat.com Thu Feb 16 14:35:46 2017 From: rsprudencio at redhat.com (Raphael Sanchez Prudencio) Date: Thu, 16 Feb 2017 15:35:46 +0100 Subject: [Open-scap] Git clone build fails in autogen.sh In-Reply-To: <3634DB8ABD61FB48A0AC3D017E9C37A855E210AB@ORD2MBX09A.mex05.mlsrvr.com> References: <3634DB8ABD61FB48A0AC3D017E9C37A855E2108A@ORD2MBX09A.mex05.mlsrvr.com> <3634DB8ABD61FB48A0AC3D017E9C37A855E210AB@ORD2MBX09A.mex05.mlsrvr.com> Message-ID: Hi Brooke, You can either disable python with ./configure --disable-python --disable-python3 or you can download swig and compile with Python support. I'm not sure if that swig package comes with Python support. Kind Regards On 02/15/2017 09:57 PM, Brooke Wallace wrote: > 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 at 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 at redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list > -- Raphael Sanchez Prudencio Security Technologies | Red Hat, Inc. From rsprudencio at redhat.com Thu Feb 16 14:48:57 2017 From: rsprudencio at redhat.com (Raphael Sanchez Prudencio) Date: Thu, 16 Feb 2017 15:48:57 +0100 Subject: [Open-scap] Kickstart with SCAP tailoring In-Reply-To: <848FB1215E2AD643A5E10D906091D3FBF58BB35B@TCSEXCH1.tcs-sec.com> References: <848FB1215E2AD643A5E10D906091D3FBF58B8486@TCSEXCH1.tcs-sec.com> <848FB1215E2AD643A5E10D906091D3FBF58BB35B@TCSEXCH1.tcs-sec.com> Message-ID: <30f1d966-5bb6-04fa-b17e-9546fb584033@redhat.com> Hi Robert On 02/16/2017 03:15 PM, Robert Sanders wrote: > Updating with some extra testing - crossposted from the > scap-security-guide list.... > > The initial work I was doing was just using a floppy to provide both > the kickstart and the tailoring file from scap-workbench. We've > migrated to having a full bootable ISO remastered from the RHEL 7.3 > install media instead, with our tailoring file added as an extra RPM to > be installed. I finally managed some syntax on the oscap addon that > didn't raise an exception using this: > > %addon org_fedora_oscap > content-type = scap-security-guide > profile = ospp-rhel7-server > tailoring-path = ../../usr/share/xml/scap/custom/tailoring.xml > %end > > But after the system installs my modified banner is not present. > Looking at the logs it appears that the tailoring path was completely > ignored. I re-installed the system and dropped to one of the alternate > windows to see exactly what oscap command was being executed and it was > this: > > oscap xccdf eval --remediate > --results=/root/openscap_data/eval_remediate_results.xml > --profile=ospp-rhel7-server > tailoring-file=/usr/share/xml/scap/custom/tailoring.xml > /usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml Is this a typo or are you using --tailoring-file without double dashes? > > While it runs apparently without error messages - I've noticed several > things: > 1) my tailoring is never used - just the steps from the profile > 2) it looks like some of the 'kickstart actions' are not being done - > if I understand the USGCB profile, it has an action for installing the > 'screen' package if needed, but this is not happening at kickstart. I > just found a bug in the oscap anacoonda addon > (https://github.com/OpenSCAP/oscap-anaconda-addon/issues/16) that seems > to confirm this, at least for RHEL 7.3 which we are using. > 3) If I run the above command from a 'live' system (with or without > the tailoring line) it still ignores the tailoring and there is an quick > message is displayed - 'This content points out to the remote resources. > Use `--fetch-remote-resources` option to download them.' If I provide > an incorrect filename for the tailoring it does error without doing any > other actions. > > So far the only way I've been able to have my tailoring file used is to > use a command similar to what scap-workbench displays in the 'dry-run' > option - and that command uses the datastream flavor of commands not the > xccdf flavor. > > So it seems if I want to have tailoring done using the plugin I have to > use the datastream content, which I can't because these systems will be > totally isolated at configuration. > > None of this is a hard show-stopper, but it means that the oscap plugin > is not usable as it stands. Right now I don't have time to delve deeper > into the plugin (although I have pulled the source to try and understand > it better). > > -Rob*From:* open-scap-list-bounces at redhat.com > [open-scap-list-bounces at redhat.com] on behalf of Robert Sanders > [rsanders at forcepoint.com] > *Sent:* Friday, February 10, 2017 10:50 AM > *To:* open-scap-list at redhat.com > *Subject:* EXTERNAL: [Open-scap] Kickstart with SCAP tailoring > > Morning all, > Have a quick question - I'm looking at using a kickstart file to > automate our OS install, but I also want to use the SCAP plugin to > handle the initial lockdown of our images. Looking at the > 'tailoring-path' option to the anaconda plugin looks promising, but the > docs indicate that the path for this option is relative to the archive > being used. Is there a way to specify the path so that it will the path > from the 'floppy' image I'm using (currently booting by adding "linux > ks=hd:fd0:ks.cfg"), or do I need to stand everything up as an > http/https/ftp server and reference the SCAP contents and my tailoring > file that way? > > -Rob > > > > > Scanned by Forcepoint Email Security Gateway > Click here > to > report this email as spam > > > > > > > _______________________________________________ > Open-scap-list mailing list > Open-scap-list at redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list > -- Raphael Sanchez Prudencio Security Technologies | Red Hat, Inc. From rsanders at forcepoint.com Thu Feb 16 15:04:55 2017 From: rsanders at forcepoint.com (Robert Sanders) Date: Thu, 16 Feb 2017 15:04:55 +0000 Subject: [Open-scap] Kickstart with SCAP tailoring In-Reply-To: <30f1d966-5bb6-04fa-b17e-9546fb584033@redhat.com> References: <848FB1215E2AD643A5E10D906091D3FBF58B8486@TCSEXCH1.tcs-sec.com> <848FB1215E2AD643A5E10D906091D3FBF58BB35B@TCSEXCH1.tcs-sec.com>, <30f1d966-5bb6-04fa-b17e-9546fb584033@redhat.com> Message-ID: <848FB1215E2AD643A5E10D906091D3FBF58BB64D@TCSEXCH1.tcs-sec.com> Raphael, I never tried with a leading '//' on the tailoring-path - I did see one reference in the utils.py code to the join_paths() call. Without the '../../' then my tailoring path wound up being preceeded by some other path components that broke when executed in the chroot part of the kickstart. What I have here 'works' - in that it didn't raise an error..... -Rob ________________________________________ From: Raphael Sanchez Prudencio [rsprudencio at redhat.com] Sent: Thursday, February 16, 2017 9:48 AM To: Robert Sanders; open-scap-list at redhat.com Subject: EXTERNAL: Re: [Open-scap] Kickstart with SCAP tailoring Hi Robert On 02/16/2017 03:15 PM, Robert Sanders wrote: > Updating with some extra testing - crossposted from the > scap-security-guide list.... > > The initial work I was doing was just using a floppy to provide both > the kickstart and the tailoring file from scap-workbench. We've > migrated to having a full bootable ISO remastered from the RHEL 7.3 > install media instead, with our tailoring file added as an extra RPM to > be installed. I finally managed some syntax on the oscap addon that > didn't raise an exception using this: > > %addon org_fedora_oscap > content-type = scap-security-guide > profile = ospp-rhel7-server > tailoring-path = ../../usr/share/xml/scap/custom/tailoring.xml > %end > > But after the system installs my modified banner is not present. > Looking at the logs it appears that the tailoring path was completely > ignored. I re-installed the system and dropped to one of the alternate > windows to see exactly what oscap command was being executed and it was > this: > > oscap xccdf eval --remediate > --results=/root/openscap_data/eval_remediate_results.xml > --profile=ospp-rhel7-server > tailoring-file=/usr/share/xml/scap/custom/tailoring.xml > /usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml Is this a typo or are you using --tailoring-file without double dashes? > > While it runs apparently without error messages - I've noticed several > things: > 1) my tailoring is never used - just the steps from the profile > 2) it looks like some of the 'kickstart actions' are not being done - > if I understand the USGCB profile, it has an action for installing the > 'screen' package if needed, but this is not happening at kickstart. I > just found a bug in the oscap anacoonda addon > (https://github.com/OpenSCAP/oscap-anaconda-addon/issues/16) that seems > to confirm this, at least for RHEL 7.3 which we are using. > 3) If I run the above command from a 'live' system (with or without > the tailoring line) it still ignores the tailoring and there is an quick > message is displayed - 'This content points out to the remote resources. > Use `--fetch-remote-resources` option to download them.' If I provide > an incorrect filename for the tailoring it does error without doing any > other actions. > > So far the only way I've been able to have my tailoring file used is to > use a command similar to what scap-workbench displays in the 'dry-run' > option - and that command uses the datastream flavor of commands not the > xccdf flavor. > > So it seems if I want to have tailoring done using the plugin I have to > use the datastream content, which I can't because these systems will be > totally isolated at configuration. > > None of this is a hard show-stopper, but it means that the oscap plugin > is not usable as it stands. Right now I don't have time to delve deeper > into the plugin (although I have pulled the source to try and understand > it better). > > -Rob*From:* open-scap-list-bounces at redhat.com > [open-scap-list-bounces at redhat.com] on behalf of Robert Sanders > [rsanders at forcepoint.com] > *Sent:* Friday, February 10, 2017 10:50 AM > *To:* open-scap-list at redhat.com > *Subject:* EXTERNAL: [Open-scap] Kickstart with SCAP tailoring > > Morning all, > Have a quick question - I'm looking at using a kickstart file to > automate our OS install, but I also want to use the SCAP plugin to > handle the initial lockdown of our images. Looking at the > 'tailoring-path' option to the anaconda plugin looks promising, but the > docs indicate that the path for this option is relative to the archive > being used. Is there a way to specify the path so that it will the path > from the 'floppy' image I'm using (currently booting by adding "linux > ks=hd:fd0:ks.cfg"), or do I need to stand everything up as an > http/https/ftp server and reference the SCAP contents and my tailoring > file that way? > > -Rob > > > > > Scanned by Forcepoint Email Security Gateway > Click here > to > report this email as spam > > > > > > > _______________________________________________ > Open-scap-list mailing list > Open-scap-list at redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list > -- Raphael Sanchez Prudencio Security Technologies | Red Hat, Inc. Scanned by Forcepoint Email Security Gateway To report this email as SPAM, please forward it to spam at forcepoint.com From rsprudencio at redhat.com Thu Feb 16 15:08:07 2017 From: rsprudencio at redhat.com (Raphael Sanchez Prudencio) Date: Thu, 16 Feb 2017 16:08:07 +0100 Subject: [Open-scap] Kickstart with SCAP tailoring In-Reply-To: <848FB1215E2AD643A5E10D906091D3FBF58BB64D@TCSEXCH1.tcs-sec.com> References: <848FB1215E2AD643A5E10D906091D3FBF58B8486@TCSEXCH1.tcs-sec.com> <848FB1215E2AD643A5E10D906091D3FBF58BB35B@TCSEXCH1.tcs-sec.com> <30f1d966-5bb6-04fa-b17e-9546fb584033@redhat.com> <848FB1215E2AD643A5E10D906091D3FBF58BB64D@TCSEXCH1.tcs-sec.com> Message-ID: No, I mean double dashes (--), in your command it looks like you're using tailoring-file instead of --tailoring-file. On 02/16/2017 04:04 PM, Robert Sanders wrote: > oscap xccdf eval --remediate >> --results=/root/openscap_data/eval_remediate_results.xml >> --profile=ospp-rhel7-server >> tailoring-file=/usr/share/xml/scap/custom/tailoring.xml >> /usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml -- Raphael Sanchez Prudencio Security Technologies | Red Hat, Inc. From rsanders at forcepoint.com Thu Feb 16 15:22:20 2017 From: rsanders at forcepoint.com (Robert Sanders) Date: Thu, 16 Feb 2017 15:22:20 +0000 Subject: [Open-scap] Kickstart with SCAP tailoring In-Reply-To: References: <848FB1215E2AD643A5E10D906091D3FBF58B8486@TCSEXCH1.tcs-sec.com> <848FB1215E2AD643A5E10D906091D3FBF58BB35B@TCSEXCH1.tcs-sec.com> <30f1d966-5bb6-04fa-b17e-9546fb584033@redhat.com> <848FB1215E2AD643A5E10D906091D3FBF58BB64D@TCSEXCH1.tcs-sec.com>, Message-ID: <848FB1215E2AD643A5E10D906091D3FBF58BB695@TCSEXCH1.tcs-sec.com> That would be due to a typo on my side. I manually copied the command rather than cut/pasting from the kickstart window. Sorry for the confusion. The command does indeed have '--tailoring-file' on it..... -Rob ________________________________________ From: Raphael Sanchez Prudencio [rsprudencio at redhat.com] Sent: Thursday, February 16, 2017 10:08 AM To: Robert Sanders; open-scap-list at redhat.com Subject: EXTERNAL: Re: [Open-scap] Kickstart with SCAP tailoring No, I mean double dashes (--), in your command it looks like you're using tailoring-file instead of --tailoring-file. On 02/16/2017 04:04 PM, Robert Sanders wrote: > oscap xccdf eval --remediate >> --results=/root/openscap_data/eval_remediate_results.xml >> --profile=ospp-rhel7-server >> tailoring-file=/usr/share/xml/scap/custom/tailoring.xml >> /usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml -- Raphael Sanchez Prudencio Security Technologies | Red Hat, Inc. Scanned by Forcepoint Email Security Gateway To report this email as SPAM, please forward it to spam at forcepoint.com From Brandon.Westover at ellucian.com Thu Feb 16 15:24:18 2017 From: Brandon.Westover at ellucian.com (Westover, Brandon) Date: Thu, 16 Feb 2017 15:24:18 +0000 Subject: [Open-scap] OpenScap Scanner on Windows In-Reply-To: References: Message-ID: 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:rsprudencio at redhat.com] Sent: Thursday, February 16, 2017 9:33 AM To: Westover, Brandon ; open-scap-list at 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 at redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list > -- Raphael Sanchez Prudencio Security Technologies | Red Hat, Inc. From jcerny at redhat.com Mon Feb 20 08:04:50 2017 From: jcerny at redhat.com (Jan Cerny) Date: Mon, 20 Feb 2017 03:04:50 -0500 (EST) Subject: [Open-scap] OpenScap Scanner on Windows In-Reply-To: References: Message-ID: <1644322323.32270980.1487577890173.JavaMail.zimbra@redhat.com> 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: rsprudencio at redhat.com, open-scap-list at 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:rsprudencio at redhat.com] > Sent: Thursday, February 16, 2017 9:33 AM > To: Westover, Brandon ; > open-scap-list at 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 at 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 at redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list > From jcerny at redhat.com Mon Feb 20 08:33:16 2017 From: jcerny at redhat.com (Jan Cerny) Date: Mon, 20 Feb 2017 03:33:16 -0500 (EST) Subject: [Open-scap] Git clone build fails in autogen.sh In-Reply-To: <3634DB8ABD61FB48A0AC3D017E9C37A855E210AB@ORD2MBX09A.mex05.mlsrvr.com> References: <3634DB8ABD61FB48A0AC3D017E9C37A855E2108A@ORD2MBX09A.mex05.mlsrvr.com> <3634DB8ABD61FB48A0AC3D017E9C37A855E210AB@ORD2MBX09A.mex05.mlsrvr.com> Message-ID: <1375764359.32285790.1487579596699.JavaMail.zimbra@redhat.com> 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 at 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 at 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 at redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list From bwallace at ramlabs.com Tue Feb 21 20:07:32 2017 From: bwallace at ramlabs.com (Brooke Wallace) Date: Tue, 21 Feb 2017 20:07:32 +0000 Subject: [Open-scap] Git clone build fails in autogen.sh In-Reply-To: <1375764359.32285790.1487579596699.JavaMail.zimbra@redhat.com> References: <3634DB8ABD61FB48A0AC3D017E9C37A855E2108A@ORD2MBX09A.mex05.mlsrvr.com> <3634DB8ABD61FB48A0AC3D017E9C37A855E210AB@ORD2MBX09A.mex05.mlsrvr.com>, <1375764359.32285790.1487579596699.JavaMail.zimbra@redhat.com> Message-ID: <3634DB8ABD61FB48A0AC3D017E9C37A855E21616@ORD2MBX09A.mex05.mlsrvr.com> I resolved the issue by running ./configure again after installing the missing package. Seems like there should be a better way to enumerate and check for required packages vs. optional features. One other observation I made was that processing one of the OVAL checkers using SCAP consistently resulted in launching the OOM Killer. I was running in A VM w/6GB of memory. My guess is that your using a DOM XML parser instead of a SAX parser which would be much more efficient and not result in OOM conditions. -Brooke ________________________________________ From: Jan Cerny [jcerny at redhat.com] Sent: Monday, February 20, 2017 12:33 AM To: Brooke Wallace Cc: open-scap-list at redhat.com Subject: Re: [Open-scap] Git clone build fails in autogen.sh 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 at 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 at 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 at redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list From rsprudencio at redhat.com Wed Feb 22 10:04:18 2017 From: rsprudencio at redhat.com (Raphael Sanchez Prudencio) Date: Wed, 22 Feb 2017 11:04:18 +0100 Subject: [Open-scap] Git clone build fails in autogen.sh In-Reply-To: <3634DB8ABD61FB48A0AC3D017E9C37A855E21616@ORD2MBX09A.mex05.mlsrvr.com> References: <3634DB8ABD61FB48A0AC3D017E9C37A855E2108A@ORD2MBX09A.mex05.mlsrvr.com> <3634DB8ABD61FB48A0AC3D017E9C37A855E210AB@ORD2MBX09A.mex05.mlsrvr.com> <1375764359.32285790.1487579596699.JavaMail.zimbra@redhat.com> <3634DB8ABD61FB48A0AC3D017E9C37A855E21616@ORD2MBX09A.mex05.mlsrvr.com> Message-ID: <963dc754-1edf-4a7a-509f-6a4f99456ba2@redhat.com> Hi Brooke, I understand your frustration, but that's the way Autotools works, it's not unique to OpenSCAP project but it's a problem for any project, if there is no tool checking for dependencies then you would be guessing what you need and it would be even more frustrating than it is right now. Best Regards On 02/21/2017 09:07 PM, Brooke Wallace wrote: > I resolved the issue by running ./configure again after installing the missing package. > > Seems like there should be a better way to enumerate and check for required packages vs. optional features. > > One other observation I made was that processing one of the OVAL checkers using SCAP consistently resulted in launching the OOM Killer. I was running in A VM w/6GB of memory. My guess is that your using a DOM XML parser instead of a SAX parser which would be much more efficient and not result in OOM conditions. > > -Brooke > ________________________________________ > From: Jan Cerny [jcerny at redhat.com] > Sent: Monday, February 20, 2017 12:33 AM > To: Brooke Wallace > Cc: open-scap-list at redhat.com > Subject: Re: [Open-scap] Git clone build fails in autogen.sh > > 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 at 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 at 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 at redhat.com >> https://www.redhat.com/mailman/listinfo/open-scap-list > > _______________________________________________ > Open-scap-list mailing list > Open-scap-list at redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list > -- Raphael Sanchez Prudencio Security Technologies | Red Hat, Inc. From RM0eTuGyo1R965koXfNi9lxoYnvroiyvvXjL2WDpUcI at outlook.com Sat Feb 25 15:43:03 2017 From: RM0eTuGyo1R965koXfNi9lxoYnvroiyvvXjL2WDpUcI at outlook.com (Lee Wilson) Date: Sat, 25 Feb 2017 15:43:03 +0000 Subject: [Open-scap] OpenSCAP for embedded/network devices Message-ID: Hi Everyone, I've recently come across OpenSCAP after wasting my time with openVAS as a means of improving the way my company does vulnerability and configuration management of our network devices (e.g. Cisco, Juniper, Palo Alto, etc). >From an initial review though, it seems in it's current state to very server focused. Would that be a fair assessment? Back in January 2016 someone posted a similar query on this list where it was suggested to use jovalcm but that is a propriatary product and they have ceased all development on the open source variant. https://www.redhat.com/archives/open-scap-list/2016-January/msg00000.html As far as I can tell there is nothing in the underlying architecture that prevents this from working, the main issue being that it is required for the various scripts to be copied to the device being scanned. This is required even when using the remote SSH scanning option according to the documentation: http://martin.preisler.me/2015/05/scanning-remote-machines-with-openscap/ I came across a presentation which pretty much covers what I'm trying to do: https://scap.nist.gov/events/2011/itsac/presentations/day3/Nunez%20-%20SCAP%20for%20Inter-networking%20Devices.pdf The use of the Script Check Engine intriges me but I believe I'll still be restricted as those scripts still need to be copied to the server but it does mention that environment variables can be passed to the script so that remote checks can be run and then the output saved as check result files as documented: https://www.open-scap.org/features/other-standards/sce/ In essence the steps would be: 1) Specify profile to run and the target(s) to run on 2) Pass target hostname/ip along with (perhaps) login credentials (e.g. username/password or SNMP community) to the script 3) Script runs on the same device as the SCAP workbench, logging into the device via the appropriate method (SSH or SNMP) 4) Results are saved as check-result files to be picked up by the oscap tool forprocessing The only concern I have the moment with this approach is that it would require multiple SSH logins (one for each script run) but I'm sure improvements could be made in the future to batch them during a single login session. Alternatively would it be possible for all the above steps to be run in advance and then just have the oscap tool look as the resulting check-result files, in effect doing something similar to an offline config audit? This would be considered a local scan I guess, no different to a customer handing me a raw cisco cli output/config and saying here audit this. I'd be interested in trying to get something like this working but if anyone has got any experience and can tell me if I'm wasting my time or not, it would be appreciated. Thanks in advance Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: