[PATCH 1/3] M1 Incomplete Guidance - Proxy

Michael Palmiotto mpalmiotto at tresys.com
Wed Apr 18 15:56:14 UTC 2012


>Before we could be ACK'ed (for commit), it needs some changes, primarily
>relating to granularity as noted in
>https://fedorahosted.org/scap-security-guide/wiki/newxccdf .
>The overall goal is to include the relevant information from the RHEL 5
>prose document, but translate it into XCCDF in a way that facilitates
>its re-use by different parties (and straightforward automation).
>
>There was also some discussion in
>https://fedorahosted.org/pipermail/scap-security-guide/2012-April/000185.html
>suggesting one CCE per Rule (as the preferred
>level of granularity).

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

>The software also could have changed since RHEL 5, and we should not
>assume that there are no errors in the RHEL 5 document to begin with.  I
>noticed that there is a squid user as the owner (of presumably a
>sub-task) of the squid service.  In your testing, does the product now
>do (out of the box) what the lower_privileges Rule suggests configuring
>for RHEL 5 (for the most part)?  If so, we can drop that.  I'm also
>generally a bit more reluctant now to suggest things like altering
>system startup scripts; this affects our ability to verify their integrity.

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.

--Mike

>Thanks,
>Jeff
_______________________________________________
scap-security-guide mailing list
scap-security-guide at lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/scap-security-guide


More information about the scap-security-guide mailing list