Hello Shawn, On Wednesday, February 13, 2019 3:59:30 PM EST Shawn Wells wrote: > On 2/11/19 7:38 PM, Steve Grubb wrote: > > On Thursday, February 7, 2019 1:23:58 PM EST Shawn Wells wrote: > >> So then, to rephrase the question, when will there be OVAL > >> tests/subjects/states/items for OpenShift, akin to how there are for > >> systemd and SELinux? > > > > Those were created specifically to address problems in drafting content > > for the USGCB settings a long time ago. They were created because there > > was no other good way of getting the information. > > > >> Would be extremely surprising to learn this process hasn't been started > >> already, but getting the sense it hasn't been. Not really sure who to > >> direct the question to.... likely Marek and Matej? > > > > Things aren't created until there's a demonstrated need. What are the > > underlying configuration that you are trying to read? What parts of the > > config are needed? Where is this information kept? > > Seems like there is a ever growing backlog of probes that need creation.
Maybe and maybe not. OVAL tests fall into 2 categories, static and dynamic. The static tests are preferred because they scamper across a hard drive and gather information. These probes work even if you are examining the hard drive from another system. And they do not affect system state in any way. This safety of use has been something the OVAL editorial board liked. And this is also the reason why a scripting option has never been approved. The dynamic probes require that the system is booted and operational. In this mode it queries interfaces, makes various system calls to query internal information the kernel has, or maybe even dbus calls to systemd. These probes are problematic because you cannot assess a system that is "down". You cannot check processes, mounts, or network interfaces unless the system is up. There is also a danger that somehow this can be abused and cause a change of system state. Checking a mount point can cause the automounter to do a mount. In that case scanning changed the system. So, it all depends on what you want to check. Generally what is expected is to check the file system for configuration. I realize now that there is a mistake in the systemd probe because it actually calls systemd. What I had intended it to do is parse the file just like systemd does with shipped config in /usr/lib and overrides in /etc. This would have made it generic enough to use for other daemons that are using that same scheme. But it was more expeditious to just call systemctl and parse its output. In any event, checking the files for configuration should be do-able today. Are there some kind of dynamic tests that you are thinking of? Generally dynamic tests are used for CyBox where static tests are used for XCCDF. > Quick examples of polling dconf db, and parsing "oc get" commands for > OpenShift settings. Neither keeps their state in config files so need to > use those commands specifically. dconf db probably would have used the parser I thought we were getting. As for "oc get", typically content should check what the config would be for next boot. Dynamic tests are not suited to that because what's on disk may not match how the system is running right now. And this causes content to be written where it mixes checking current state vs what it would be for next boot with people not realizing these two things are getting mixed together. For example, you can check if sshd is configured to spit out a banner. That is a next boot check. You have no idea what its currently doing. You can also check what services are running now. You have no idea what it will be on next boot because the content checks systemd and not the files. > At this point, getting the impression there's been zero work on creating > OpenShift probes though. If there's no content that needs them, they won't get created just in case they're needed one day. To specify a new test means asking 20 or so companies to implement the code and take it through certification. So normally things are only asked for when they are truly needed. HTH... -Steve _______________________________________________ Open-scap-list mailing list Openfirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/open-scap-list