Support tags within policy definition files #6996
Replies: 6 comments 13 replies
-
Hi @vojtapolasek! I had given some thought to the same here: 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 :) |
Beta Was this translation helpful? Give feedback.
-
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.
This "inherits" would be optional.The implementation would be a bit more complicated, but I believe not that much. |
Beta Was this translation helpful? Give feedback.
-
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
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:
I'd do this rather than the example you suggested of:
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 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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Hi,
The definition in the ".profile" file would stay the same, e.g. for CIS level 2 server:
|
Beta Was this translation helpful? Give feedback.
-
A PR implementing changes is available here: |
Beta Was this translation helpful? Give feedback.
-
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:
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:
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:
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?
Beta Was this translation helpful? Give feedback.
All reactions