[PATCH 1/3] M1 Incomplete Guidance - Proxy

Kevin Spargur kspargur at redhat.com
Wed Apr 11 16:15:42 UTC 2012


On 04/11/2012 11:52 AM, Spencer R. Shimko wrote:
> On 4/11/12 11:33 AM, "Jeffrey Blank"<blank at eclipse.ncsc.mil>  wrote:
>
>> 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.h
>> tml
>> suggesting one CCE per Rule (as the preferred
>> level of granularity).
>>
>>
>> There are some benefits to this:
>>
>> 1)
>> This will position us (and Mitre) to easily
>> verify the correspondence/agreement between CCE description and XCCDF
>> description.
>>
>> 2)
>> After a set of OVAL checks is run, an
>> admin (or a C&A person) may only see a list of pass/fail results.  When
>> possible, we want to keep these precise to enable well-informed
>> decisions.  This is also relevant to the eventual addition of<fix>
>> tags, which may attempt to tie a remediation action to a particular
>> check's result.
>>
>>
>> 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'll let Michael respond to most points you make above.  I'm just
> concerned with the last point.  You need to perform integrity checks on
> tons of things that will definitely be modified as part of implementing
> the req guidance. The hashes must be generated after any of those
> modifications take place.  The startup scripts themselves do some crazy
> things we patch out for our solutions.  Often these modifications go above
> and beyond these reqs, such as label-based mounting or the devmapper
> operations which requires raw block device access.  Of course reducing
> those modifications to things that provide serious benefit is desirable.
> But I don't think "verify their integrity" should prevent someone from
> enhancing the security of the solution.  If a req is best addressed by
> modifying an init script so be it.  After all, they're just text files ;)

I think the question is more one of how much does this really enhance 
the security.  In some cases such as where permissions were changed from 
the default, they provided little to no real value and merely hampered 
things like rpm -V.  If the security provided is significant I think we 
can all agree its worth the pain.

Thanks,

Kevin


> Thanks,
> --Spencer
>
>>
>> Thanks,
>> Jeff
>> _______________________________________________
>> scap-security-guide mailing list
>> scap-security-guide at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/scap-security-guide
> _______________________________________________
> 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