DoD refined as requiring audit of all 
success/failed attempts to create/access/delete/modify files [2]

Ugh... this thing *destroys* systems on a regular basis along with the chmod/chown rules. I get it but I've seen *so* many systems tanked by those rules.

On Wed, Jan 9, 2019 at 7:43 PM Shawn Wells <> wrote:

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

> 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



scap-security-guide mailing list --
To unsubscribe send an email to
Fedora Code of Conduct:
List Guidelines:
List Archives:

Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --