On Friday, October 31, 2014 10:47:37 AM Shawn Wells wrote: > On 10/31/14, 10:31 AM, Steve Grubb wrote: > > I think there is a problem in the SSG content. I think that the current > > content is intended to check the system configuration. This would be done > > by examining the files on disk to warn about changes or thing that are > > misconfigured. There is also another category of testing that is > > forensics which checks the ephemeral / current values being enforced. > > Both are necessary and useful, but they should not be mixed.
<snip> > I've opened tickets to track mount vs fstab, sysctl, and service vs > chkconfig: Thanks! > As/if you identify additional sections which need better separation, > please bring them to our attention! Well, in a very brief look, the selinux label check in /dev is wrong, it should be: find /dev -context *:device_t:* \( -type c -o -type b \) I think the guide should get a thorough review. > > This really needs to be addressed before anyone else uses SSG as the basis > > of their own recommendations. Again, forensic checking is useful and I > > would say content should be specifically designed with that in mind. But > > it is not what should be in a baseline. > > That's a bit strong of language. SSG represents a catalog of controls, > from which agencies make selections for formal baselines that we turn > into profiles. Often (e.g. with the STIG) the agency wishes to include > capabilities for static/persistent configuration (e.g. sysctl.conf) > *and* ephemeral system state (sysctl -a). In retrospect, I agree. I am concerned that people not with a strong Linux background don't grok the difference or perhaps learn the wrong thing. -Steve -- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
