[Open-scap] When to expect OVAL probes for OpenShift?

[Steve Grubb]

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