For some content, such as verify_default_secure_settings, the CCE's are each tied to an individual line in the same file. This level of granularity would require creating a rule for each line: ftp_passive on ftp_sanitycheck on check_hostnames on request_header_max_size 20 KB reply_header_max_size 20 KB cache_effective_user squid cache_effective_group squid ignore_unknown_nameservers on
Correct. But if there are any of these for which there is not a solid case for including it in a compliance-checking regime, then don't include it.
I think this should be a wake-up call to would-be contributors: we are not seeking a hurried copy-paste from the RHEL 5 prose guide. This project is designed to produce SCAP content that is modular, granular, and flexible.
Related: Regarding OVAL content, I might create a Rule for cache_effective_user, but I might make the OVAL check succeed if the line is not found at all, since the default is sane. Interestingly, based on http://www.squid-cache.org, the default for the squid project is "nobody," but Red Hat uses "squid" (likely for better accountability and to grant some privilege when needed).
I don't believe it does, or at least the lines in /etc/init.d/squid and /etc/squid/squid.conf are not the way that the prose recommends them to be.
I meant only /etc/init.d/squid, and for rpm-based verification. As Spencer pointed out, this quickly turns into a question about use-case. It might be reasonable to expect that init scripts have not been altered for systems in a general-purpose use-case. But not for a more specialized system.
Config files are always expected to change (and rpm flags them as such).