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.html
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 --
scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to
scap-security-guide-le...@lists.fedorahosted.org
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/scap-security-guide@lists.fedorahosted.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
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/scap-security-guide@lists.fedorahosted.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
