Support tags within policy definition files

[vojtapolasek]

Hello all,
I would like to propose a change to structure of policy definition files, e.g. files within the "controls" directory.
Currently, the structure is revolving around a concept of levels. This works very well for the current use case - ANSSI profiles. But when I tried to use this structure for definition of CIS profiles, I found that it is not flexible enough.
CIS profile does not use hierarchical levels, its scope of rules is more similar to "tags". And that's what I would like to propose. Let's use tags instead of levels. I imagine something like this:

policy: 'Policy name'
title: 'Policy title'
id: policy
version: '1.2'
source: https://some_url
tags:
  - workstation
  - level_1
  - level_2


controls:
  - id: C1
    tags:
      - workstation
      -     - level_2
    title: Minimization of installed services
    description: >-
      Only the components strictly necessary to the service provided by the system should
      be installed.
      Those whose presence can not be justified should be disabled, removed or deleted.
    automated: partially  # The list of essential services is not objective.
    notes: >-
      Use of obsolete or insecure services is not recommended.
      The minimal install is a good starting point, but this doesn't provide any assurance over any package installed later.
    rules:
    - package_dhcp_removed
    #- package_rsh_removed
    #- package_rsh-server_removed
    - package_sendmail_removed
    - package_telnetd_removed
    #- package_talk_removed
    #- package_talk-server_removed
    #- package_telnet_removed
    #- package_telnet-server_removed
    #- package_tftp_removed
    #- package_tftp-server_removed
    #- package_xinetd_removed
    #- package_ypbind_removed
    #- package_ypserv_removed

That means that a control could belong to one or more tags. In case of CIS, it can for example belong to workstation and level_2 tag, as noted in the benchmark.
This offers greater flexibility and I believe that it reduces code duplication, because for example for CIS you don't need to define multiple profiles with duplicate rules.

I imagine that the definition in the profile file could look something like this:

selections:
  - policy:all:workstation,level_2
  - some_extra_rule

ANSSI profiles can be also expressed in this way. Just make levels into labels and then for example ANSSI high profile could be defined as:

  - anssi:all:minimal,intermediary,enhanced,high

I also suggest that current concept of levels and inheritance is dropped and replaced with tags. But I am not pushing on this part.

What are your opinions?

[cipherboy]

Hi @vojtapolasek! I had given some thought to the same here:

#6915 (comment)

Did you get a chance to evaluate whether a nested level structure was possible in addition to/instead of tagging (with no inheritance)? It seems like most controls would benefit from some form of inheritance.

---

Unrelated:

Would you completely deprecate and remove levels in this proposal? Or if not, how would tags and levels interact? You could make it an either/or type deal. Just a thought :)

[alexhaydock]

Did you get a chance to evaluate whether a nested level structure was possible in addition to/instead of tagging (with no inheritance)? It seems like most controls would benefit from some form of inheritance.

I think with CIS I'm finding it helpful to think of it as if it's two different benchmarks: CIS Workstation, and CIS Server.

Level 2 Workstation inherits everything from Level 1 Workstation, and Level 2 Server inherits everything from Level 1 Server. There's a lot of overlap between the Workstation and Server profiles but I've been considering them as mostly two separate things as there are definitely differences in which controls apply (and at which "Level" the controls apply) between Server and Workstation.

Some examples of the variance from CIS's RHEL 8 benchmark:

• 1.1.22 and 1.1.23 disable automounting and USB storage. These apply at Level 1 for Servers but only apply at Level 2 for Workstations
• 1.7.1.6 is about removing SETroubleshoot, and applies only to Level 2 Server and no others.
• 2.2.2 applies only to the Sever profile as the remediation would be to uninstall the X server (clearly unwanted on a Workstation).
• CUPS is a similar story as the X server control above, as control 2.2.16 indicates it is is allowed on Workstations at Level 1.

So I think when it comes to nested levels with inheritance, there's definitely some scope for that to be useful within the context of Workstation Level 2 also inheriting everything from Workstation Level 1, and from Server Level 2 also inheriting everything from Server Level 1.

[cipherboy]

There's a few other ways you could slice this. We're having these discussions upstream in the CIS community at some point, like I mentioned on another ticket, might be nice to have you join :-)

For instance, you could consider a "filesystem-only" based checks. This would be great for image building (new OS installer .iso or containers) -- you could also consider a core "agnostic" check that should hold regardless (container, bare metal, cloud image, &c). If you have arbitrary, specified inheritance, I could see doing something like:

- id: filesystem_core
- id: filesystem_container
  inherits: filesystem_core
- id: filesystem_server
  inherits: filesystem_core
- id: filesystem_workstation
  inherits: filesystem_core
- id: level_1_server
  inherits: filesystem_server
- id: level_1_workstation
  inherits: filesystem_workstation
- id: level_2_server
  inherits: level_1_server
- id: level_2_workstation
  inherits: level_1_workstation

And push most all of your shared rules into filesystem_core. With multi-inherits you could even do:

- id: filesystem_core
- id: filesystem_server
  inherits: filesystem_core
- id: filesystem_workstation
  inherits: filesystem_core
- id: runtime_core
- id: runtime_server
  inherits: runtime_core
- id: runtime_workstation
  inherits: runtime_core
- id: level_1_server
  inherits: filesystem_server,runtime_server
- id: level_1_workstation
  inherits: filesystem_workstation,runtime_workstation
- id: level_2_server
  inherits: level_1_server
- id: level_2_workstation
  inherits: level_1_workstation

Or similar. Just a thought :-)

[alexhaydock]

Oh I really like that approach actually! 😃 I'll definitely have to actually sign into my CIS account and get involved in the upstream discussions!

[vojtapolasek]

These are intereting ideas, I guess I should joint the CIS community too.
I am not sure if the control file is the right place where to differentiate between applicability for containers and bare metal, we already have applicability platforms for that, which should accomplish this at the rule level.
I am also not sure if I get the benefit of having some special profile for image creation... But maybe I am not understanding the use case.

[matejak]

I agree to @vojtapolasek here - the control approach is about being close to the policy when defining a profile. If we want to partition rules in a profile wrt their area(s), we don't need anything of higher-level than rules themselves - the category of a rule doesn't depend on anything else than what the rule itself is about.
Right now, rule partitioning is done by means of groups that are reflected by the rule definition location. This is not super flexible, as rules may be partitioned by different schemes, and there is only one directory tree, so I think that we may end up with rule tags as well.

[vojtapolasek]

Let's take the example of CIS. If there was no inheritance, then in case of rule which is level 2, you would need to specify level_1 as well as level_2 tag. I understand that this would probably bring plenty of unnecessary lines. But the implementation would be easier.
Another approach is to do something like

  tags:
    - level_2
      inherits: level_1
    - level_1

This "inherits" would be optional.The implementation would be a bit more complicated, but I believe not that much.
Would this work better for you?

[vojtapolasek]

@cipherboy could you please elaborate on this? I am not sure I understand. Should I create some POC PR? By profile, are you refering to the example in the initial post?

[cipherboy]

Sorry, meant policy.

In the initial example you only had:

tags:
  - workstation
  - level_1
  - level_2

With no clear indication how inheritance worked. You then went on to say:

If there was no inheritance, then in case of rule which is level 2, you would need to specify level_1 as well as level_2 tag.

Which, for one, is backwards (all level1 rules are included in level 2, but rules which are level 2 aren't included in level 1) --- but for two, to me kinda said you implied there to be inheritance. :-)

So I was stating a preference for explicit inheritance, if there is inheritance. I think inheritance in general makes sense.

I'd also be fine calling it levels still instead of tags, with an explicit inheritance chain.

My 2c.

[jan-cerny]

I like the idea of optionally specifying the inheritance between levels. I would also move to explicit inheritance because as we can see from the CIS example there can be situations in which the implicit inheritance would cause troubles. We need to make it flexible because other benchmarks we will encounter in future can have even different structure or concepts.

[vojtapolasek]

Thank you for your insights. I see that inheritance might be good to be kept there, I don't have a problem with that. My idea was to drop it and allow to specify multiple tags in the profile definition. But this would make the inheritance less clear.

[matejak]

The concept of levels assumed that most policies will have this layered structure with occasional exceptions, but that doesn't work well with CIS. The question is whether to solve this problem with tags alone, or whether to introduce support for hierarchical tags that would also deprecate levels, because a level is a simple case of a hierarchical tag.
This is tricky here, because level_1 doesn't make sense on its own - in case of CIS, it is simply Level 1 of Workstation, i.e. something like workstation:level_1 or workstation ∩ level_1. This brings us to another issue - how to define what combination of tags should make it into a profile.
Right now, the syntax is very simple and limited - it is basically <policy>:<control> or <policy>:all for all controls, or <policy>:all:<level> for all controls of at least that level. The best way seems to allow specification of set operations in the profile file. Before you think that this is too complex, don't forget that we will like to use set-like operations for other things in the project too, s.a. rule prodtypes.

[alexhaydock]

CIS profile does not use hierarchical levels, its scope of rules is more similar to "tags". And that's what I would like to propose. Let's use tags instead of levels. I imagine something like this:

Having just gone through the 4 CIS benchmark "sub-profiles" for RHEL 8 as part of #6976, I fully support the idea of a migration to a tag-based system. This would make dealing with CIS in particular a lot cleaner.

Without it, my current solution (also seen in #6976) is to split out the current RHEL 8 monolithic cis.profile into 4 separate profiles which all have a significant overlap.

That means that a control could belong to one or more tags. In case of CIS, it can for example belong to workstation and level_2 tag, as noted in the benchmark.

This I also agree with, though I'm unsure on the usefulness of splitting out the tags that way. It might create more confusion than it solves. This might be more of a CIS-specific point though, but my approach would be to use these tags:

• level_1_server
• level_2_server
• level_1_workstation
• level_2_workstation

I'd do this rather than the example you suggested of:

tags:
  - workstation
  - level_1
  - level_2

The reason I'd do it the way I suggest above is that it'd be hard to express, as an example, RHEL 8 CIS 1.1.22 and 1.1.23. These disable automounting and USB storage, so they apply to both Level 1 and Level 2 when using the Server profile, but when using the Workstation profile they only apply at Level 2. So I think the explicit approach is a cleaner way of ensuring all the rules apply in the right places.

But that's a bit beside the general point you make, of tags being useful, which I fully agree with.

I also suggest that current concept of levels and inheritance is dropped and replaced with tags. But I am not pushing on this part.

I would personally agree with this too but you can take my opinion with a grain of salt as a new contributor who is biased as I mostly only have an interest in CIS.

[jan-cerny]

I also suggest that current concept of levels and inheritance is dropped and replaced with tags. But I am not pushing on this part.

As I mentioned earlier if the inheritance would be optional and you would have to request the inheritance explicitly then you don't need to drop it.

[vojtapolasek]

Hi,
so I would like to do some summary. We will then see if we can delve into implementation or if we need some more discussions.
So What I see now is:

• dropping implicit inheritance among levels
• make level not just a list item, but a new structure
• this structure would have one item sso far: a list called "inherits_from". The list would contain levels.
• a "level" attribute of a control would be list as well. List would show a levels tow chi a control belongs.
  An example inspired by CIS follows:

policy: 'ANSSI-BP-028'
title: 'CIS policy'
id: cis
version: '3.2.0'
source: some_url
levels:
  - workstation_l1
  - workstation_l2:
    inherits_from:
      - workstation_l1
  - server_l1
  - server_l2:
    inherits_from:
      - server_l1

controls:
  - id: 1.1.1.1
    levels:
      - workstation_l1
      - server_l1
    title: Ensure mounting of cramfs filesystems is disabled
    description: >-
      The cramfs filesystem type is a compressed read-only Linux filesystem embedded in small footprint systems. A cramfs image can be used without having to first decompress the image.
    automated: yes
    rules:
    - kernel_module_cramfs_disabled

The definition in the ".profile" file would stay the same, e.g. for CIS level 2 server:

cis:all:server_l2

[alexhaydock]

+1

I think this approach makes a lot of sense, and the policies look like they'd be quite clean and easy to construct using this method.

[vojtapolasek]

A PR implementing changes is available here:
#7072