----- Original Message ----- > From: "Jan Cerny" <[email protected]> > To: [email protected], "open-scap-list" <[email protected]> > Sent: Tuesday, February 7, 2017 10:33:22 AM > Subject: Re: [Open-scap] Windows Support > > Hi, > > ----- Original Message ----- > > From: "Raphael Sanchez Prudencio" <[email protected]> > > To: [email protected] > > 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 > [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
