[PATCH 1/3] M1 Incomplete Guidance - Proxy
Jeffrey Blank
blank at eclipse.ncsc.mil
Sun Apr 22 19:38:23 UTC 2012
> 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).
More information about the scap-security-guide
mailing list