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-boun...@redhat.com [mailto:open-scap-list-
> boun...@redhat.com] On Behalf Of Raphael Sanchez Prudencio
> Sent: Thursday, February 09, 2017 7:39 AM
> To: Calvin Hartwell
> Cc: open-scap-list@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