Naming convention for permission related rules

[dodys]

STIG has a bunch of different rule regarding files and directories permissions, owner and groupowner.

In Ubuntu 20.04 STIG we have (hopefullly I'm not missing any):

file_permissions_var_log_audit
file_ownership_var_log_audit_stig
file_group_ownership_var_log_audit
directory_permissions_var_log_audit
file_permissions_etc_audit_rulesd
file_permissions_etc_audit_auditd
file_ownership_audit_configuration
file_groupownership_audit_configuration
file_permissions_audit_binaries
file_ownership_audit_binaries
file_groupownership_audit_binaries
permissions_local_var_log
file_groupowner_var_log
file_owner_var_log
file_permissions_var_log
file_permissions_var_log_syslog
file_groupowner_var_log_syslog
file_owner_var_log_syslog
file_permissions_var_log_syslog
dir_permissions_binary_dirs
dir_ownership_binary_dirs
dir_groupownership_binary_dirs
file_permissions_library_dirs
dir_permissions_library_dirs
file_ownership_library_dirs
dir_ownership_library_dirs
root_permissions_syslibrary_files
dir_groupownership_library_dirs
file_permissions_binary_dirs
file_ownership_binary_dirs
file_groupownership_system_commands_dirs

Some of those rules are easy to understand just by reading its name:
file_permissions_binary_dirs: this is about permissions for file under binary directories, such as /bin/

Now some rules are just hard to understand, e.g.:
root_permissions_syslibrary_files: not sure if it is about directories or files

Therefore, following a naming convention would make it easier, and root_permissions_syslibrary_files can be changed to file_groupownership_library_dirs.

What do you think about having a naming convention and renaming the ones that are not so clear?

[ggbecker]

We have unfortunately allowed some of these new rules being introduced to the project without actually noticing the misleading IDs. On one hand we should definitely try to keep them consistent and concise, but on the other hand, changing rule IDs mean possibly breaking existent tailorings because the old rule ID will cease to exist when we rename it.

It's hard to know exactly the impact that there will be, but if we decide to rename them, we have to accept this risk.

Unfortunately the standard doesn't support a way of deprecating rules, although we could have a duplicated rule in a way that we would start using this new rule but keeping the old one in place to avoid breaking any existing tailorings.

[dodys]

Maybe instead of renaming rules, we could re-create then with the correct name, and make sure that new products are using the new ones instead of the old ones, and they could be removed when all the products using them are also not supported anymore and about to be removed.

[marcusburghardt]

To complement the discussion, there is a deprecation process defined: https://complianceascode.readthedocs.io/en/latest/manual/developer/06_contributing_with_content.html#rule-deprecation