upcoming improvements in handling of multiple platforms

[Vojtech Polasek]

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/servi...

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/syste...

https://github.com/ComplianceAsCode/content/blob/master/linux_os/guide/syste...

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:

https://github.com/ComplianceAsCode/content/pull/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.

Best regards,

Vojtech Polasek

Software engineer, security compliance

Red Hat https://www.redhat.com

[e-mail]

https://www.redhat.com

[Matej Tyc]

Thanks for the presentation of the idea, I have two remarks to it:

On 11. 03. 21 10:46, Vojtech Polasek wrote:
> 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.
>
> ...
>
> 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:

I get the benefit, but I see one possible issue - Ansible also has a 
yaml key that may contain a list of conditions, but there is the AND 
relationship between them: 
https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.ht... 
Ansible uses a nice trick to offload conditional handling to jinja2, so 
we could draw inspiration from that.

OTOH, I get that the word "platforms" clearly points towards OR 
relationship of list items, and one would expect "narrow_platform_down" 
for a list joined by AND. Anyway, if there is a more illustrative term 
than "platforms", it would be nice if someone came up with it.
> 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:
>
> https://github.com/ComplianceAsCode/content/pull/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

FTR, we already have "inherited_platforms" key in compiled rules, where 
list items are obviously joined by AND.

The question is whether we should keep "inherited_platforms" and 
"platforms" (maybe renamed to "rule_platforms") separate, or whether we 
should unravel those to simply "platforms" that will feature a list with 
logical expressions. See e.g. the RHEL8-compiled rule file 
build/rhel8/rules/sssd_ldap_configure_tls_reqcert.yml

The question is how would we like this in the future - right now, the 
rule depends on its group that can restrict its platform scope by a 
platform. That sounds logical and generally good, but is this solution 
flexible enough so we won't have to create artificial groups, or to use 
macros to supply complex platforms lists to individual rules because we 
want a specific platform applicability?

[Vojtech Polasek]

Hello Matěj,

thank you for the feedback. Responding inline.

Vojta

Dne 15. 03. 21 v 15:46 Matej Tyc napsal(a):
> Thanks for the presentation of the idea, I have two remarks to it:
>
> On 11. 03. 21 10:46, Vojtech Polasek wrote:
> > 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.
> >
> > ...
> >
> > 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:
>
> I get the benefit, but I see one possible issue - Ansible also has a 
> yaml key that may contain a list of conditions, but there is the AND 
> relationship between them: 
> https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.ht... 
> Ansible uses a nice trick to offload conditional handling to jinja2, 
> so we could draw inspiration from that.

Thank you for pointing this Jinja trick out. I will look into that, 
maybe it can be one of paths we can take in further development.
> OTOH, I get that the word "platforms" clearly points towards OR 
> relationship of list items, and one would expect 
> "narrow_platform_down" for a list joined by AND. Anyway, if there is a 
> more illustrative term than "platforms", it would be nice if someone 
> came up with it.
> > 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:
> >
> > https://github.com/ComplianceAsCode/content/pull/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
>
> FTR, we already have "inherited_platforms" key in compiled rules, 
> where list items are obviously joined by AND.
>
> The question is whether we should keep "inherited_platforms" and 
> "platforms" (maybe renamed to "rule_platforms") separate, or whether 
> we should unravel those to simply "platforms" that will feature a list 
> with logical expressions. See e.g. the RHEL8-compiled rule file 
> build/rhel8/rules/sssd_ldap_configure_tls_reqcert.yml

Hm, complied rules are kinda intermediate format of rules... we could 
possibly change representation of platforms, but personally I like the 
current state, where inherited platforms are connected with AND and 
"platforms" are connected with OR. It follows the XCCDF structure. For 
use of "AND" between platforms on rule level we will have to create 
artificial platforms anyway, if nobody comes with a better solution.
> The question is how would we like this in the future - right now, the 
> rule depends on its group that can restrict its platform scope by a 
> platform. That sounds logical and generally good, but is this solution 
> flexible enough so we won't have to create artificial groups, or to 
> use macros to supply complex platforms lists to individual rules 
> because we want a specific platform applicability?
> _______________________________________________
> scap-security-guide mailing list -- 
> [e-mail]
> To unsubscribe send an email to 
> [e-mail]
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/[e-mail]...
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure