Hello,
Regarding rule "Verify file hashes with RPM", which files resides here: https://github.com/ComplianceAsCode/content/tree/master/linux_os/guide/syste...
From description in rule.yml I understand that altered files should be reported and, altered configuration files should be reported analyzed individually. 1. Is this the intended action? To evaluate altered configuration files?
Looking at the OVAL check, it mostly cares about altered files under /bin, /sbin ,/lib ,/lib64 or /usr (mainly executables and libraries according to comment). 2. Is this restriction only to optimize for search of libraries and binaries? I see a slight misalignment between check and description. This way we won't be catching much changes in config files.
Personally, I think that anything marked as %config should not be checked because they are allowed to vary anyway.
On Tue, Jan 8, 2019 at 8:52 AM Watson Sato wsato@redhat.com wrote:
Hello,
Regarding rule "Verify file hashes with RPM", which files resides here:
https://github.com/ComplianceAsCode/content/tree/master/linux_os/guide/syste...
From description in rule.yml I understand that altered files should be reported and, altered configuration files should be reported analyzed individually.
- Is this the intended action? To evaluate altered configuration files?
Looking at the OVAL check, it mostly cares about altered files under /bin, /sbin ,/lib ,/lib64 or /usr (mainly executables and libraries according to comment). 2. Is this restriction only to optimize for search of libraries and binaries? I see a slight misalignment between check and description. This way we won't be catching much changes in config files.
-- 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.fedor...
On Tue, Jan 8, 2019 at 2:57 PM Trevor Vaughan tvaughan@onyxpoint.com wrote:
Personally, I think that anything marked as %config should not be checked because they are allowed to vary anyway.
I'm leaning towards ignoring config files in OVAL check, and making it explicit in rule description. And add a note with command that would output list of config files that do not match their rpm hash, in case you would like to review altered config files manually.
On Tue, Jan 8, 2019 at 8:52 AM Watson Sato wsato@redhat.com wrote:
Hello,
Regarding rule "Verify file hashes with RPM", which files resides here:
https://github.com/ComplianceAsCode/content/tree/master/linux_os/guide/syste...
From description in rule.yml I understand that altered files should be reported and, altered configuration files should be reported analyzed individually.
- Is this the intended action? To evaluate altered configuration files?
Looking at the OVAL check, it mostly cares about altered files under /bin, /sbin ,/lib ,/lib64 or /usr (mainly executables and libraries according to comment). 2. Is this restriction only to optimize for search of libraries and binaries? I see a slight misalignment between check and description. This way we won't be catching much changes in config files.
-- 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.fedor...
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information -- _______________________________________________ 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.fedor...
Makes sense to me.
It was always irritating to have to explain why I changed the config file...that I had to change.
On Tue, Jan 8, 2019 at 9:08 AM Watson Sato wsato@redhat.com wrote:
On Tue, Jan 8, 2019 at 2:57 PM Trevor Vaughan tvaughan@onyxpoint.com wrote:
Personally, I think that anything marked as %config should not be checked because they are allowed to vary anyway.
I'm leaning towards ignoring config files in OVAL check, and making it explicit in rule description. And add a note with command that would output list of config files that do not match their rpm hash, in case you would like to review altered config files manually.
On Tue, Jan 8, 2019 at 8:52 AM Watson Sato wsato@redhat.com wrote:
Hello,
Regarding rule "Verify file hashes with RPM", which files resides here:
https://github.com/ComplianceAsCode/content/tree/master/linux_os/guide/syste...
From description in rule.yml I understand that altered files should be reported and, altered configuration files should be reported analyzed individually.
- Is this the intended action? To evaluate altered configuration files?
Looking at the OVAL check, it mostly cares about altered files under /bin, /sbin ,/lib ,/lib64 or /usr (mainly executables and libraries according to comment). 2. Is this restriction only to optimize for search of libraries and binaries? I see a slight misalignment between check and description. This way we won't be catching much changes in config files.
-- 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.fedor...
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information -- _______________________________________________ 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.fedor...
-- 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.fedor...
On Tue, Jan 8, 2019, at 9:08 AM, Watson Sato wrote:
On Tue, Jan 8, 2019 at 2:57 PM Trevor Vaughan tvaughan@onyxpoint.com wrote:
Personally, I think that anything marked as %config should not be checked because they are allowed to vary anyway.
I'm leaning towards ignoring config files in OVAL check, and making it explicit in rule description. And add a note with command that would output list of config files that do not match their rpm hash, in case you would like to review altered config files manually.
I think it's fine to ignore hash for config files, but permissions and ownership should still be verified, though that may be a separate rule.
V/r, James Cassell
I'd only go with permissions if the permissions are *weaker*.
I've tightened down various config items and they show as issues which makes for a slew of false positives.
Ownership makes sense.
On Tue, Jan 8, 2019 at 1:38 PM James Cassell fedoraproject@cyberpear.com wrote:
On Tue, Jan 8, 2019, at 9:08 AM, Watson Sato wrote:
On Tue, Jan 8, 2019 at 2:57 PM Trevor Vaughan tvaughan@onyxpoint.com wrote:
Personally, I think that anything marked as %config should not be
checked
because they are allowed to vary anyway.
I'm leaning towards ignoring config files in OVAL check, and making it explicit in rule description. And add a note with command that would output list of config files that
do
not match their rpm hash, in case you would like to review altered config files manually.
I think it's fine to ignore hash for config files, but permissions and ownership should still be verified, though that may be a separate rule.
V/r, James Cassell _______________________________________________ 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.fedor...
On Tue, Jan 8, 2019 at 7:08 AM Watson Sato wsato@redhat.com wrote:
On Tue, Jan 8, 2019 at 2:57 PM Trevor Vaughan tvaughan@onyxpoint.com wrote:
Personally, I think that anything marked as %config should not be checked because they are allowed to vary anyway.
I'm leaning towards ignoring config files in OVAL check, and making it explicit in rule description. And add a note with command that would output list of config files that do not match their rpm hash, in case you would like to review altered config files manually.
This isn't a great fix and is more of a bandaid. It would be better for us to open BZs and fix this in the troublesome RPMs spec files.
On Tue, Jan 8, 2019 at 8:52 AM Watson Sato wsato@redhat.com wrote:
Hello,
Regarding rule "Verify file hashes with RPM", which files resides here:
https://github.com/ComplianceAsCode/content/tree/master/linux_os/guide/syste...
From description in rule.yml I understand that altered files should be reported and, altered configuration files should be reported analyzed individually.
- Is this the intended action? To evaluate altered configuration files?
Looking at the OVAL check, it mostly cares about altered files under /bin, /sbin ,/lib ,/lib64 or /usr (mainly executables and libraries according to comment). 2. Is this restriction only to optimize for search of libraries and binaries? I see a slight misalignment between check and description. This way we won't be catching much changes in config files.
-- 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.fedor...
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information -- _______________________________________________ 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.fedor...
-- 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.fedor...
On 1/8/19 1:39 PM, Gabe Alford wrote:
On Tue, Jan 8, 2019 at 7:08 AM Watson Sato <wsato@redhat.com mailto:wsato@redhat.com> wrote:
On Tue, Jan 8, 2019 at 2:57 PM Trevor Vaughan <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com>> wrote: Personally, I think that anything marked as %config should not be checked because they are allowed to vary anyway. I'm leaning towards ignoring config files in OVAL check, and making it explicit in rule description. And add a note with command that would output list of config files that do not match their rpm hash, in case you would like to review altered config files manually.This isn't a great fix and is more of a bandaid. It would be better for us to open BZs and fix this in the troublesome RPMs spec files.
The XCCDF currently has language stating that config files are expected to change and should not be a finding.
If the OVAL is flagging config files, wouldn't that would be a bug in the existing OVAL code?
On Wed, Jan 9, 2019 at 3:28 AM Shawn Wells shawn@redhat.com wrote:
On 1/8/19 1:39 PM, Gabe Alford wrote:
On Tue, Jan 8, 2019 at 7:08 AM Watson Sato wsato@redhat.com wrote:
On Tue, Jan 8, 2019 at 2:57 PM Trevor Vaughan tvaughan@onyxpoint.com wrote:
Personally, I think that anything marked as %config should not be checked because they are allowed to vary anyway.
I'm leaning towards ignoring config files in OVAL check, and making it explicit in rule description. And add a note with command that would output list of config files that do not match their rpm hash, in case you would like to review altered config files manually.
This isn't a great fix and is more of a bandaid. It would be better for us to open BZs and fix this in the troublesome RPMs spec files.
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.
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".
_______________________________________________
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.fedor...
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:
On 1/8/19 1:39 PM, Gabe Alford wrote:
On Tue, Jan 8, 2019 at 7:08 AM Watson Sato wsato@redhat.com wrote:
On Tue, Jan 8, 2019 at 2:57 PM Trevor Vaughan tvaughan@onyxpoint.com wrote:
Personally, I think that anything marked as %config should not be checked because they are allowed to vary anyway.
I'm leaning towards ignoring config files in OVAL check, and making it explicit in rule description. And add a note with command that would output list of config files that do not match their rpm hash, in case you would like to review altered config files manually.
This isn't a great fix and is more of a bandaid. It would be better for us to open BZs and fix this in the troublesome RPMs spec files.
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?
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".
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.fedor...
-- 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.fedor...
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".
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.fedor...
-- 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.fedor...
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.fedor...
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".
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.fedor...
-- 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.fedor...
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.fedor...
-- 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.fedor...
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".
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.fedor...
-- 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.fedor...
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.fedor...
-- 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.fedor...
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.fedor...
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/syste...
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 shawn@redhat.com 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 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/syste...
[2] https://www.niap-ccevs.org/MMO/PP/424.CANX/ _______________________________________________ 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.fedor...
On 1/9/19 8:54 PM, Trevor Vaughan wrote:
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.
Way the current Configuration Annex is written is that CNSSI 1253 and DoD systems will need to audit every file I/O.
They have a reasonably responsive team behind these. Can open a ticket through GitHub, or even submit a PR, to start the conversation to have these changed:
https://github.com/commoncriteria/operatingsystem/blob/master/input/configan...
On Thursday, January 10, 2019 11:24:20 AM EST Shawn Wells wrote:
On 1/9/19 8:54 PM, Trevor Vaughan wrote:
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.
Way the current Configuration Annex is written is that CNSSI 1253 and DoD systems will need to audit every file I/O.
It is almost the same as what is called out for by OSPP-4.2. Which you can see here:
https://github.com/linux-audit/audit-userspace/blob/master/rules/30-ospp-v42...
AFAICS, CNSSI 1253 also wants accesses of configuration files. I would say that is ill-advised. You may want failures due to permissions in accessing files. But with a lot of subsystems putting configuration in /usr/lib/ how do you tell what to monitor and what is applications? I'd say treat config files as any other file because they are too spread out and accessed constantly, like $HOME/.bashrc
-Steve
They have a reasonably responsive team behind these. Can open a ticket through GitHub, or even submit a PR, to start the conversation to have these changed:
https://github.com/commoncriteria/operatingsystem/blob/master/input/configa nnex.xml#L212#L223
On 1/10/19 12:56 PM, Steve Grubb wrote:
On Thursday, January 10, 2019 11:24:20 AM EST Shawn Wells wrote:
On 1/9/19 8:54 PM, Trevor Vaughan wrote:
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.
Way the current Configuration Annex is written is that CNSSI 1253 and DoD systems will need to audit every file I/O.
It is almost the same as what is called out for by OSPP-4.2. Which you can see here:
https://github.com/linux-audit/audit-userspace/blob/master/rules/30-ospp-v42...
Those look like a good starting point! Prior to shipping, to meet OSPP, those rules will need to also audit successful events (not just unsuccessful).
Ref "Audit File and Object Events" from OSPP Config Annex: https://www.niap-ccevs.org/MMO/PP/424.CANX/
AFAICS, CNSSI 1253 also wants accesses of configuration files. I would say that is ill-advised. You may want failures due to permissions in accessing files. But with a lot of subsystems putting configuration in/usr/lib/ how do you tell what to monitor and what is applications? I'd say treat config files as any other file because they are too spread out and accessed constantly, like $HOME/.bashrc
Unfortunately there's no distinguishing between config vs other file types. Currently *all* file and object events need to be audited for:
File and Objects events: (1) Create (Success/Failure) (2) Access (Success/Failure) (3) Delete (Success/Failure) (4) Modify (Success/Failure) (5) Permission Modification (Success/Failure) (6) Ownership Modification (Success/Failure)
On Thursday, January 10, 2019 1:12:40 PM EST Shawn Wells wrote:
On 1/10/19 12:56 PM, Steve Grubb wrote:
On Thursday, January 10, 2019 11:24:20 AM EST Shawn Wells wrote:
On 1/9/19 8:54 PM, Trevor Vaughan wrote:
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.
Way the current Configuration Annex is written is that CNSSI 1253 and DoD systems will need to audit every file I/O.
It is almost the same as what is called out for by OSPP-4.2. Which you can see here:
https://github.com/linux-audit/audit-userspace/blob/master/rules/30-ospp-%3E > v42.rules
Those look like a good starting point! Prior to shipping, to meet OSPP, those rules will need to also audit successful events (not just unsuccessful).
Ref "Audit File and Object Events" from OSPP Config Annex: https://www.niap-ccevs.org/MMO/PP/424.CANX/
Right. Look at the section for File events, first column:
Audit File and Object Events (Unsuccessful) AU-2a.
Specifically, unsuccessful.
And I would go farther and say unsuccessful because of permission and not because the file is missing or any other (useless) reason.
AFAICS, CNSSI 1253 also wants accesses of configuration files. I would say that is ill-advised. You may want failures due to permissions in accessing files. But with a lot of subsystems putting configuration in/usr/lib/ how do you tell what to monitor and what is applications? I'd say treat config files as any other file because they are too spread out and accessed constantly, like $HOME/.bashrc
Unfortunately there's no distinguishing between config vs other file types. Currently *all* file and object events need to be audited for:
File and Objects events: (1) Create (Success/Failure) (2) Access (Success/Failure) (3) Delete (Success/Failure) (4) Modify (Success/Failure) (5) Permission Modification (Success/Failure) (6) Ownership Modification (Success/Failure)
To quote from it:
Together, the combination of a baseline and applicable overlay(s) represents the initial security control set prior to system-specific tailoring.
IOW, its asking for capabilities that can be refined later. What I would like to point to is an old Industrial Security Letter for NISPOM that I think captures something important:
https://fas.org/sgp/library/nispom/isl0101.htm
-------- 55. Question: Paragraph 8-602a(1)(c) can generate upwards to 100 audit entries for each successful access to security-relevant objects and/or directories. From a security standpoint, is this information of enough importance to generate voluminous amounts of auditing data?
Answer: No. Only unsuccessful accesses need to be audited. --------
Requirement in question is:
8-602a(1)(c) Successful and unsuccessful accesses to security-relevant objects and directories, including creation, open, close, modification, and deletion.
I think this ISL refinement is still generally correct. And I would also say that you will should limit it to USER activity and not normal system operation.
-Steve
That is all amazingly useful information to have!
We really need to make a FOSS mind map of this stuff somewhere.
On Thu, Jan 10, 2019 at 2:09 PM Steve Grubb sgrubb@redhat.com wrote:
On Thursday, January 10, 2019 1:12:40 PM EST Shawn Wells wrote:
On 1/10/19 12:56 PM, Steve Grubb wrote:
On Thursday, January 10, 2019 11:24:20 AM EST Shawn Wells wrote:
On 1/9/19 8:54 PM, Trevor Vaughan wrote:
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.
Way the current Configuration Annex is written is that CNSSI 1253 and DoD systems will need to audit every file I/O.
It is almost the same as what is called out for by OSPP-4.2. Which you can see here:
https://github.com/linux-audit/audit-userspace/blob/master/rules/30-ospp-%3E
v42.rules
Those look like a good starting point! Prior to shipping, to meet OSPP, those rules will need to also audit successful events (not just unsuccessful).
Ref "Audit File and Object Events" from OSPP Config Annex: https://www.niap-ccevs.org/MMO/PP/424.CANX/
Right. Look at the section for File events, first column:
Audit File and Object Events (Unsuccessful) AU-2a.
Specifically, unsuccessful.
And I would go farther and say unsuccessful because of permission and not because the file is missing or any other (useless) reason.
AFAICS, CNSSI 1253 also wants accesses of configuration files. I would say that is ill-advised. You may want failures due to permissions in accessing files. But with a lot of subsystems putting configuration in/usr/lib/ how do you tell what to monitor and what is applications? I'd say treat config files as any other file because they are too
spread
out and accessed constantly, like $HOME/.bashrc
Unfortunately there's no distinguishing between config vs other file types. Currently *all* file and object events need to be audited for:
File and Objects events: (1) Create (Success/Failure) (2) Access (Success/Failure) (3) Delete (Success/Failure) (4) Modify (Success/Failure) (5) Permission Modification (Success/Failure) (6) Ownership Modification (Success/Failure)
To quote from it:
Together, the combination of a baseline and applicable overlay(s) represents the initial security control set prior to system-specific tailoring.
IOW, its asking for capabilities that can be refined later. What I would like to point to is an old Industrial Security Letter for NISPOM that I think captures something important:
https://fas.org/sgp/library/nispom/isl0101.htm
- Question: Paragraph 8-602a(1)(c) can generate upwards to 100 audit
entries for each successful access to security-relevant objects and/or directories. From a security standpoint, is this information of enough importance to generate voluminous amounts of auditing data?
Answer: No. Only unsuccessful accesses need to be audited.
Requirement in question is:
8-602a(1)(c) Successful and unsuccessful accesses to security-relevant objects and directories, including creation, open, close, modification, and deletion.
I think this ISL refinement is still generally correct. And I would also say that you will should limit it to USER activity and not normal system operation.
-Steve
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.fedor...
Sounds a bit like
* Permissives * Protection * Interlocks * Acquisition & Audit * Etc
From: sgrubb@redhat.com Sent: January 10, 2019 12:56 PM To: scap-security-guide@lists.fedorahosted.org Reply to: scap-security-guide@lists.fedorahosted.org Cc: shawn@redhat.com Subject: Re: Rule rpm_verify_file_hashes and config files
On Thursday, January 10, 2019 11:24:20 AM EST Shawn Wells wrote:
On 1/9/19 8:54 PM, Trevor Vaughan wrote:
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.
Way the current Configuration Annex is written is that CNSSI 1253 and DoD systems will need to audit every file I/O.
It is almost the same as what is called out for by OSPP-4.2. Which you can see here:
https://github.com/linux-audit/audit-userspace/blob/master/rules/30-ospp-v42...
AFAICS, CNSSI 1253 also wants accesses of configuration files. I would say that is ill-advised. You may want failures due to permissions in accessing files. But with a lot of subsystems putting configuration in /usr/lib/ how do you tell what to monitor and what is applications? I'd say treat config files as any other file because they are too spread out and accessed constantly, like $HOME/.bashrc
-Steve
They have a reasonably responsive team behind these. Can open a ticket through GitHub, or even submit a PR, to start the conversation to have these changed:
https://github.com/commoncriteria/operatingsystem/blob/master/input/configa nnex.xml#L212#L223
_______________________________________________ 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.fedor... THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.
One-size-fits-all vs tailored Are the config-file-validation-engine’s config files under RPM control? ;-)
From: Watson Sato [mailto:wsato@redhat.com] Sent: Wednesday, January 9, 2019 11:59 AM To: SCAP Security Guide scap-security-guide@lists.fedorahosted.org Subject: Re: Rule rpm_verify_file_hashes and config files
On Wed, Jan 9, 2019 at 5:39 PM Gabe Alford <redhatrises@gmail.commailto:redhatrises@gmail.com> wrote: On Wed, Jan 9, 2019 at 9:09 AM Watson Sato <wsato@redhat.commailto:wsato@redhat.com> wrote:
On Wed, Jan 9, 2019 at 3:28 AM Shawn Wells <shawn@redhat.commailto: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".
_______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.orgmailto: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.fedor...
-- Watson Sato Security Technologies | Red Hat, Inc _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.orgmailto: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.fedor... _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.orgmailto: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.fedor...
-- Watson Sato Security Technologies | Red Hat, Inc THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.
scap-security-guide@lists.fedorahosted.org
-
Brent Kimberley -
Gabe Alford -
James Cassell -
Shawn Wells -
Steve Grubb -
Ted Brunell -
Trevor Vaughan -
Watson Sato