[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