add service_auditd_enabled ignition remediation

[mrogers950]

I've been testing this out but it's not working yet; First I logged into a node and ran systemctl disable auditd to test this out. The scan runs, but there's no hit for the disabled systemd unit. I poked around for the service disable code, I noticed the following in the jinja macros:

{{%- macro systemd_ocil_service_disabled(service) %}}
    To check that the <code>{{{ service }}}</code> service is disabled in system boot configuration, run the following command:
    <pre>$ systemctl is-enabled <code>{{{ service }}}</code></pre>
    Output should indicate the <code>{{{ service }}}</code> service has either not been installed,
    or has been disabled at all runlevels, as shown in the example below:
    <pre>$ systemctl is-enabled <code>{{{ service }}}</code><br/> disabled</pre>

    Run the following command to verify <code>{{{ service }}}</code> is not active (i.e. not running) through current runtime configuration:
    <pre>$ systemctl is-active {{{ service }}}</pre>

    If the service is not running the command will return the following output:
    <pre>inactive</pre>

    By default the service will also be masked, to check that the <code>{{{ service }}}</code> is masked, run the following command:
    <pre>$ systemctl show <code>{{{ service }}}</code> | grep "LoadState\|UnitFileState"</pre>

    If the service is masked the command will return the following outputs:

    <pre>LoadState=masked</pre>

    <pre>UnitFileState=masked</pre>

{{%- endmacro %}}


{{%- macro systemd_ocil_service_enabled(service) %}}
    Run the following command to determine the current status of the
    <code>{{{ service }}}</code> service:
    <pre>$ systemctl is-active {{{ service }}}</pre>
    If the service is running, it should return the following: <pre>active</pre>
{{%- endmacro %}}

The service_disabled macro checks that the systemd unit is disabled, I was basically expecting the inverse for service_enabled, but it's a running check instead. I thought this might be why the check did not work, so I then tried killing auditd (making systemctl is-active return "inactive"), but no dice. I think I'm missing something else here..
/cc @JAORMX @jhrozek

[yuumasato]

@mrogers950 Do you get pass result during evaluation?

The OCIL macros are instructions for manual checking and verification. They are not strictly exactly what the scanner is doing.

Looking up at the OVAL template for service enabled, it should pass when:

• auditd is installed AND auditd is running AND the service is configured to start (enabled)

and the content does the service checks by using systemdunitdependency_test.

I remember that systemd probe support for offline mode is not implemented.
@evgenyz Do you think this could affect the scan?

[evgenyz]

The probe actually does not support offline mode. It was working in offline mode in 1.3.1 due to an error. Error was fixed in 1.3.2.

[evgenyz]

Probe uses DBus to communicate with systemd about modules status. In pure offline mode this would not work because we don't have the target system running. OpenShift's offline mode is different. I'd say it's a hybrid between online and offline modes, when you have your runtime knobs where they supposed to be (well, almost), but the root filesystem is elsewhere (not in '/').

We are planning to address this issue, but right now the probe is not usable.

[jhrozek]

Probe uses DBus to communicate with systemd about modules status. In pure offline mode this would not work because we don't have the target system running. OpenShift's offline mode is different. I'd say it's a hybrid between online and offline modes, when you have your runtime knobs where they supposed to be (well, almost), but the root filesystem is elsewhere (not in '/').

We are planning to address this issue, but right now the probe is not usable.

Planning where? If there's an internal tracker feel free to reply via e-mail instead of here. It's almost certain that we'd need a variant of this check for other rules, so it would be nice to fix the issue...

[evgenyz]

We are planning to address this issue, but right now the probe is not usable.

Planning where? If there's an internal tracker feel free to reply via e-mail instead of here. It's almost certain that we'd need a variant of this check for other rules, so it would be nice to fix the issue...

We are planning to plan it. It is not yet even formulated. We are going to have some discussion about the whole "offline" approach and how to extend it this week. I'll make an update once we will have something.

[yuumasato]

I have a vague memory of hearing / discussing that the some checks would have to be done via the MachineConfig fetched from the cluster / node. Hence the need for yamlfilecontent probe.

Is it the case that services enabled / disabled fall into this category?

[jhrozek]

I have a vague memory of hearing / discussing that the some checks would have to be done via the MachineConfig fetched from the cluster / node. Hence the need for yamlfilecontent probe.

Is it the case that services enabled / disabled fall into this category?

I don't think so, we don't need to fetch anything from the node to learn that a service is enabled or running.

[jhrozek]

The questions about the probe were discussed separately, it is one of the offline probes that needs fixing. However, the remediation as a whole is OK and we can merge it.

[yuumasato]

Ok, thanks for clarification.

[yuumasato]

@mrogers950 Do you plan to make changes to this PR? As it is marked WIP.

[mrogers950]

@yuumasato I've updated the PR, thanks!