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).