Permissions checks on config files are all that you really need.

Also, AIDE doesn't really catch much in the way of global config files (again, who cares if it changes as long as it was supposed to change).

If we really want to note that something has changed without getting a bunch of false positives, then all config files from RPMs should be added to the auditd rules. That would also catch permission changes.

We keep our systems within a reasonable amount of drift using Puppet and, if you're actively managing your systems, that is a third data point for critical files.

All that said, auditd would be the best solution for active detection and inotify rules are cheap, right :-P.

Trevor

On Wed, Jan 9, 2019 at 12:36 PM Ted Brunell <tbrunell@redhat.com> 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. 

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.

On Wed, Jan 9, 2019 at 12:00 PM Watson Sato <wsato@redhat.com> wrote:


On Wed, Jan 9, 2019 at 5:39 PM Gabe Alford <redhatrises@gmail.com> wrote:
On Wed, Jan 9, 2019 at 9:09 AM Watson Sato <wsato@redhat.com> wrote:


On Wed, Jan 9, 2019 at 3:28 AM Shawn Wells <shawn@redhat.com> wrote:


The XCCDF currently has language stating that config files are expected to change and should not be a finding.

From following snippet I understand that a configuration file that changed is a finding and should reviewed and fixed/waived.
A "c" in the second column indicates that a file is a configuration file, which
may appropriately be expected to change.  If the file was not expected to
change, investigate the cause of the change using audit logs or other means.

Which if that is the case, changing the OVAL code so that it ignores the config files and passes doesn't make sense.
Because how will you know if you need to investigate a config file that has changed when it wasn't supposed to change?

Well, that is one of my questions.
In practice, are people expecting that configuration files which differ from default shipped in package to be reported?
Won't it just end up creating large amount of findings people don't care?

And if config files should really be checked, why skip /etc in OVAL definition?

 

If the OVAL is flagging config files, wouldn't that would be a bug in the existing OVAL code?

Yes, my suggestion is to stop checking hash of config files in rule "Verify file hashes with RPM".



--
Watson Sato
Security Technologies | Red Hat, Inc
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org


--
Watson Sato
Security Technologies | Red Hat, Inc
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org


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

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