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: [email protected] [mailto:open-scap-list-
> [email protected]] On Behalf Of Raphael Sanchez Prudencio
> Sent: Thursday, February 09, 2017 7:39 AM
> To: Calvin Hartwell <[email protected]>
> Cc: [email protected]
> 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
> > <[email protected] <mailto:[email protected]>> 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
> >     [email protected] <mailto:[email protected]>
> >     https://www.redhat.com/mailman/listinfo/open-scap-list
> >     <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: [email protected]
> > <mailto:[email protected]>*
> >
> 
> --
> Raphael Sanchez Prudencio
> Security Technologies | Red Hat, Inc.
> 
> _______________________________________________
> Open-scap-list mailing list
> [email protected]
> https://www.redhat.com/mailman/listinfo/open-scap-list

_______________________________________________
Open-scap-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/open-scap-list

Reply via email to