Speaking for myself, such aggregation would indeed be helpful
Two other instances of such that come to mind (from the RHEL7 v3r1 STIG) are:
RHEL-07-021030
RHEL-07-021031
Since indiscriminately changing file or directory ownership is problematic, listing the
paths for which these apply is fine, so they may be adjudicated on a case by case basis.
RHEL-07-010010
Ah, the ever-beloved RHEL-07-010010.
In one particular case, the recommended fix of rpm --setperms did nothing for one
directory, /run/dbus from dbus-daemon, because the permissions for the directory inside
the rpm was flawed and resulted in an open case and later remediation. Listing the items
on which to be taken action in a report of some kind, or even the items on which actions
were taken, apart from the default play output, would be useful. In this case, we already
have the list_of_packages, list_of_files_with_incorrect_ownership, and
list_of_files_with_incorrect_permissions vars already established, it wouldn't be much
to direct those to a flat or JSON output. (I'm undecided about which would be more
useful, the most useful being a report which cross-referenced path, ownership,
permissions, and permissions/ownership on disk, but that might be a bit much.)
For that matter, a callback plugin similar to DISA's stig_xml.py would be useful as
well, which auto-generates the XCCDF content for import into a CKL, but that might me
outside the scope of this specific topic.
--Henry Link
From: Watson Sato <wsato(a)redhat.com>
Sent: Wednesday, December 16, 2020 3:50 PM
To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org>
Subject: [Non-DoD Source] Collecting system info with SCAP rules for manual inspection -
informational rules
Hello all,
Most of the Rules implemented in
ComplianceAsCode/content<https://no-click.mil/?https://github.com/Comp...
(if not all of them) have been focused on checking and remediating a specific
configuration. Typically configurations that are easy to automate.
For example, ensuring that packages installed have the signature verified is implemented
by a rule checking that the repo files have "gpgcheck = 1".
But there are cases where automation is not reasonably achievable, they would require hard
coding parameters or an extensive tailoring harness for the rule.
For example, how to ensure that configured repositories are the ones officially supported
by the distro.
In these cases the check needs to be done by some other process, maybe manually checking
the repositories enabled, or some administrative process guarantees it.
I don't know details of the auditory nor how these non-automatable requirements are
handled.
So I wonder if an Informational Rule that would collect the data for manual analysis would
be of help.
Following the examples, this informational rule would collect the list of repositories
enabled, and present it / aggregate it somehow.
Regards,
--
Watson Sato
Software Engineer
Red Hat
EMEA<https://no-click.mil/?https://www.redhat.com>
<
https://no-click.mil/?https://www.redhat.com>