On 1/9/19 12:36 PM, Ted Brunell wrote:
I agree with not checking the hash for configuration files. There
are
other checks that look at the permissions for all files in an RPM
package. I think those would suffice to ensure that configuration
files cannot be accessed or changed by unauthorized users.
All of this traces back to SI-7 [0] which relates to employing
"integrity verification tools to detect unauthorized changes" to software.
To meet SI-7 we created three configuration checks [1]:
(1) rpm_verify_hashes
(2) rpm_verify_ownership
(3) rpm_verify_permissions
rpm_verify_hashes was created to align with SI-7(6), which "implements
cryptographic mechanisms to detect unauthorized changes to software."
The intent was to use the hash values to detect when the binaries are
changed.
The other concern should be someone who does have access making
unnecessary or unauthorized changes to configuration files. I think
AIDE can track those changes and rules exist to configure it to do so
already.
Alterations to configuration files are covered through the base NIAP and
DoD Configuration Annex requirements. Specifically the "Audit File and
Object Events" requirement, which DoD refined as requiring audit of all
success/failed attempts to create/access/delete/modify files [2].
It's not that config file alterations aren't being evaluated -- it's
that other rules take care of those events. No need to duplicate in
rpm_verify_file_hashes.
[0]
https://nvd.nist.gov/800-53/Rev4/control/si-7
[1]
https://github.com/ComplianceAsCode/content/tree/master/linux_os/guide/sy...
[2]
https://www.niap-ccevs.org/MMO/PP/424.CANX/