Item 4.2.1.5 from RHEL8 CIS is not fully automatable / should not be enabled

[alexhaydock]

Description of problem:

Since the introduction of rsyslog_remote_loghost into the RHEL8 CIS benchmark by #7692, the rule (which was previously not being applied) will start being applied again.

https://github.com/ComplianceAsCode/content/blob/e7110e97c808b82a8d6d91c9da42f6c5422747cf/controls/cis_rhel8.yml#L1457-L1464

I'd like to make the case that this rule isn't sufficient and probably shouldn't be applied at all, on the basis that it risks causing more disruption than benefit if applied by admins who don't review every rule individually.

This rule works by referencing the rsyslog_remote_loghost_address variable:

https://github.com/ComplianceAsCode/content/blob/296e63458c924f34376ac44dbde1eee9731696c3/linux_os/guide/system/logging/rsyslog_sending_messages/rsyslog_remote_loghost_address.var#L13-L14

In this scenario, what will happen is that rsyslog will be configured to send all syslogs from the system over UDP 514 to any host on the local network which the bare logcollector hostname resolves to.

While this does technically satisfy the bare wording of the control, I'm not sure this is a sensible approach. The spirit of the rule can only be satisfied by this rule in its default config if the profile is being applied in an environment where there is a syslog server in the environment resolvable as logcollector.

The rule does acknowledge this at the very bottom of the description field:

https://github.com/ComplianceAsCode/content/blob/296e63458c924f34376ac44dbde1eee9731696c3/linux_os/guide/system/logging/rsyslog_sending_messages/rsyslog_remote_loghost/rule.yml#L27

At best, this control is very opinionated and requires an admin applying the rule to either set up their logging infrastructure to match this logcollector pattern (given the way variable selectors work in CaC, it's not even the case that an admin can provide a tailoring file which replaces the logcollector variable with an alternative freeform entry).

At its worst, this adds a significant leak vector. Anyone who controls the host that resolves to logcollector on the network of the hardened host can effectively put themselves in a position to receive syslog events from misconfigured systems. Bearing in mind that this control also applies to the CIS Workstation benchmark, there's a chance that some of the systems hardened with the profile may roam between networks.

We can argue that a diligent admin should be reading through what the hardening profiles they apply actually do, and should spot this one and follow-up on its configuration by making sure they edit the rsyslog config to match their collection infrastructure. I don't disagree, but at that point the admin has essentially just overwritten anything this rule actually did which means the rule arguably didn't do anything useful.

(As a realist I'd also be willing to place a bet on there being systems out there where hardening has been enabled to meet a compliance requirement without anyone actually checking what that process involves. :laughing:)

Anyway, this is just my opinion. I'm not really sure what the appropriate approach is here. I notice #8000 is a similar ticket and the status of that rule is set to partial and a comment has been added. I'm not sure if that would work here since my understanding is that partial would still apply it, and the notes field is only visible to people reading the raw profile file and isn't reflected in end-user tooling like SCAP Workbench.

Does anyone have any opinions around this?

SCAP Security Guide Version:

master

[marcusburghardt]

Hi @alexhaydock ,

Good catch on that. I agree that a likely invalid and certainly undesired value should be not be "blindly" set for remote host in this context, for the reasons you already mentioned.

I think we can split the issue here in assessment and remediation for better discussion.

Regarding the assessment, the rule looks reasonable to me because when the administrator don't properly set this variable accordingly to the environment, the scanner will report a "find". The natural approach in this case is to investigate the issue, which ultimately would trigger actions to properly set this variable. In short, the admin will be informed that something is not as expected by the assessment, so we ensure awareness. The only thing should be fine to change here is the default value. Maybe change to something much more explicit than logcollector, like change-me-to-a-valid-and-safe-logcollector-fqdn. : )

Regarding the remediation something indeed should be changed. Fortunately, we have more flexibility to adapt remediation since they are written in Bash Script or Ansible playbooks. I can think in some approaches and controls: 1 - Adjust the remediation to firstly try to resolve the informed host. 2 - Make sure the variable is not using the default value, which logically assumes it was changed by the admin.

Maybe more options could be interesting, but looks that one (or all) out these two are enough to keep the assessment valuable and the also offer a safer option to remediate the system based on context conditions. If the conditions fail, we can abort the remediation and show an explicit message in the remediation report.

Do you see any other point with this suggestion?

[alexhaydock]

Hi @marcusburghardt,

I think I agree with that. It's useful to keep the rule around for assessment, and I think remediation can be treated more carefully. I think the idea of making the default value more explicitly "default" is a good one, but I think I'm still of the opinion that there'll be quite a few admins out there in the world who are applying these hardening options as part of a Kickstart to meet compliance requirements and not really delving into the complexities of what's actually going on. So functionally I don't think it would change too much about the threat here.

I like the idea of the remediation refusing to apply itself if it detects it is using the default value, meaning it will only get applied if the logcollector hostname has been overridden by the admin applying the controls. However, my understanding of the way the structure of the content works in CaC is that an admin can't really do a free-text override of a variable's value using a tailoring file and instead all we can do is give them a list of potential values to select from. So that might be difficult to implement in practice.

I think broadly my view here is that this control is fine for assessment, but can't be automated in a sensible way.