Hi, ----- Original Message ----- > From: "Raphael Sanchez Prudencio" <rspruden...@redhat.com> > To: open-scap-list@redhat.com > Sent: Friday, February 3, 2017 5:28:17 PM > Subject: [Open-scap] Windows Support > > Hello, > > I'm planning some effort towards Windows support for OpenSCAP and I'd > like to discuss a few topics so we can have an architecture that pleases > both users and developers.
That's great. I think Windows support will be highly appreciated, because we often receive requests for this on mailing lists and issues on GitHub reporting that "SCAP Workbench cannot scan my Windows machine" etc. Idea of Windows support is here for a long time, just nobody was brave enough to start working on it :-) It is even a topic for a diploma thesis with Red Hat see https://diplomky.redhat.com/topic/show/267/ms-windows-support-for-openscap-project I would like to help you with this effort on "upstream Fridays" if you want. > > 1) Change probe architecture: > > Currently our probe system have individual binaries for each OVAL > object, making it more complex and harder to maintain/debug due to IPC, > the historical reasons to this is to be able to use tailored SELinux > policies for each probe, which makes sense but sadly we never > implemented those policies. Actually, we used to have SELinux policy in upstream, and there was a package called openscap-selinux in RHEL, but we decided to remove them, because OpenSCAP needs to access a lot of paths in the operating system and therefore SELinux policy would be a huge pain and therefore oscap and probes run as unconfined processes. See discussion in https://bugzilla.redhat.com/show_bug.cgi?id=1209969 and https://github.com/OpenSCAP/openscap/commit/a827637ecbb661d1767236b413c1678d13184df6 My opinion is that SELinux is no longer a reason to have probes separately. I think that another reason for separate processes for probes was a future possiblity of parallelism, in order to scan faster. To be honest, I think that it's almost impossible to start implementing parallel scanning, because there will be too much synchronization problems and we would end in hell of memory issues. Notice that oscap and probes are separate processes and each probe consists of multiple threads. TLDR I don't see any reason now to have the probes as separate processes. > My proposal is to avoid having multiple > binaries for Windows environments and make object collecting easier with > a single probe which handles all objects. > * Extra: Changing Linux to a single-probe would be interesting too, feel > free to comment on this topic too! I think this is a good idea. Actually I would start with Linux probes first. Firstly, I suggest removing the multi-process architecture in master branch. This way we could get rid of SEXPs, caches, pipes and all those things that are the biggest pain for me as a developer. While removing be able to test that we don't break anything. I think we will be able to remove and refactor a huge part of the code. After we have a single-process system, it should be easier to start implementing support for new Windows OVAL objects. I would like to avoid having a mixed architecture, where some OVAL objects will evaluated by oscap process and some other objects will be evaluated by separate processes. That would be harder to maintain and harder to orient for other contributors. Moreover, some probes are defined as independent in the OVAL specification, so it should be possible to implement them in a portable way. I would like to avoid having duplicate code for Linux and Windows. I think if we make it easy for people to add new probes, we can have more contributors, and not only for Windows, but also for Android and other operating systems. > > > 2) Make it possible to implement/extend object collecting with Lua > > My idea here is to make it easier to implement new (custom) objects or > to extend/modify existing ones using Lua, interfacing it with all needed > underlying API for Windows probes like WMI-related objects. Also would > enable remote scan features such as making extended probes that would > report only Pass/Fail like Thin Results, which would be really > interesting for a remote scan in a big infrastructure. > Lua Virtual Machine is around 100-200kb, it would be really light and > easy to send it through the network along with Lua probes for remote > scanning with dissolvable agents which is another plus, not needing > openscap installed on target machines and deleting the agent after scan. On the other hand, Lua would be another dependency. We try to have as least dependencies as possible. That could be a problem for downstream packagers, and QE of Linux distributions. Maybe C++ could be also a possible way, and we already have some C++ code in our codebase, specifically in dpkg_probe. > > > I think these are huge and audacious changes that would be more > interesting than just simply implementing Windows probes in the current > probe system as is. I'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@redhat.com https://www.redhat.com/mailman/listinfo/open-scap-list
