Introducing upcoming improvements to handling of multiple platforms

[vojtapolasek]

Hello all,

I would like to introduce a planed improvement within the area of applicability of rules / groups / profiles for specific platforms. I would like to ask you to provide feedback, especially with regards to content authoring experience.

Currently, you can use the "platform:" keyword to mark a part of SSG content as applicable for a given platform. This can be done in scope of profile, group and rule.

Notice that these three scopes are listed in the specific order, as they go in hierarchy from profile (highest level) to rule (lowest level).

Currently, platforms propagate through this hierarchy. So if you specify that some profile is applicable only to "machine" platform, all rules within this profile will be applicable only to the "machine" platform. The same is true for groups; all rules within a group will inherit a platform specified for the group.

These platforms are connected with implicit AND. Please note that currently you can specify only ONE platform per profile / group / rule.

But what if you want to make rule applicable to combination of platforms? For example there is a rule for ntpd OR chrony:

https://github.com/ComplianceAsCode/content/blob/master/linux_os/guide/services/ntp/chronyd_or_ntpd_set_maxpoll/rule.yml

This is currently not possible.

Or what if you want to make rule applicable to conjunction of platforms, e.g. rule should be applied if Grub2 is installed and UEFI is used.

https://github.com/ComplianceAsCode/content/blob/master/linux_os/guide/system/bootloader-grub2/group.yml

https://github.com/ComplianceAsCode/content/blob/master/linux_os/guide/system/bootloader-grub2/uefi/group.yml

This is currently possible, but it involves creating groups and abusing the fact that group applicability is connected with AND with rule applicability (XCCDF specification).

We would like to change this and make applicability more flexible. Changes are planed for profile, group and rule definitions.

The first change should allow to define multiple independent platforms. A new keyword "platforms" will be added. It will expect a list of platforms. All platforms in the list will be connected with "OR". For example, for the rule about ntpd and chrony, you could specify:

platforms:
  - ntp
  - chrony

The change is backward compatible, it is still possible to specify single platform through

platform: platform_name

This change is already being implemented here:

#6661

We chose this approach because it is easy to implement. XCCDF specification already allows to specify multiple platforms per group/profile/rule and they are implicitly connected with OR.

The next step will be implementing of support for specification of multiple combined platforms (joining platforms with AND).

The specification would utilize the previous syntax but additionally it could include a special character, e.g. &.

To specify applicability only for cases when Grub2 and UEFI are present at the same time, it could be:

platforms:
  - grub2 & uefi

To specify platform for Zipl or Grub2 bootloader but only if UEFI is used, it could be:

platforms:
  - zipl & uefi
  - grub2 & uefi

This change would start using CPE applicability language to define new platforms which would be created at build time.

What do you think about this initiative? Awaiting your feedback.

[cipherboy]

Hi @vojtapolasek :-)

Thanks for the discussions today on the call!

For my experiments with variable-based applicability, I ended up introducing an explicit not form:

  - var_chrony:
      name: "cpe:/a:var_chrony"
      title: "Chrony is selected"
      check_id: var_time_synchronization_daemon_is_chrony
      variable: var_time_synchronization_daemon
      value: chrony
      negated: false

  - not_var_chrony:
      name: "cpe:/a:not_var_chrony"
      title: "Chrony is not selected"
      check_id: var_time_synchronization_daemon_is_not_chrony
      variable: var_time_synchronization_daemon
      value: chrony
      negated: true

(Note that these are pseudo-CPEs and not actually put into the CPE Dictionary XML at build time).

package_chrony_installed then takes a var_chrony platform and package_chrony_removed takes a not_var_chrony. I figured an explicit negation form was better than trying to hack an implicit form (as the check will need to be negated properly anyways).

How would logic like or and and be applied? Would you pre-compute all scenarios used by CaC and generate checks for each scenario based on the existing CPE entry's check?

Don't get me wrong, I like the idea, I'm just not sure how this actually translates to XCCDF XML.

---

Also, asking about this point in particular:

We chose this approach because it is easy to implement. XCCDF specification already allows to specify multiple platforms per group/profile/rule and they are implicitly connected with OR.

What's the reference for this? I don't quite see it in my copy of the 1.2 XCCDF spec. I ask because I recently ran into this test -- this seems to me that an assumption baked into this test and the rest of CaC is that platforms apply via AND conjunction, i.e., all platforms must match instead of OR conjunction, where any one or more platforms may match.

Concretely, I think:

group/group.yml: platforms: machine
group/rule/rule.yml: platforms: chrony

If you update rule.yml to have both machine, chrony as platforms, if the above about OR conjunction holds, the rule would still execute if the platform was machine AND chrony package wasn't present.

[cipherboy]

@vojtapolasek I think the logical conclusion of this is that any CPE-joining logic would need to mint its own CPEs based on which platform conjunctions were in use and then add only a single <platform /> element onto the XCCDF element, to ensure that the desired result is achieved, independent of what implementations take <platform /> to mean, because the XCCDF standard doesn't have complex-check-type logic for <platform />.

You'd probably accomplish this with a build-system generated CPE name and several extend_definition with criteria's operators chosen by this.

It'd be doable I think and we could standardize a criteria in CaC and change it independent of the build artifacts, but requires a bit of hacking to get working correctly. (You'd need CPE generation to walk the rules to see which auto-gen'd CPEs you'd need to write out, but it wouldn't be too bad.)

@jan-cerny or @evgenyz Do you know if OpenSCAP will cache OVAL probe data? i.e., if we have a bunch of CPE checks like:

<criteria>
 <extend_definition id="..." negate="true">
</criteria>

And heavily reuse extend_definitions across say, 30+ parent checks, will each concrete OVAL check only get evaluated once or will they greatly slow down evaluation? Just curious :-)