[PATCH] Included Manual steps for /tmp checks Sanity checks against, "fix text" (for manual command line checks).

Michael J. McConachie michael at redhat.com
Thu Sep 6 16:56:47 UTC 2012


Jeff,

Thanks for the confirmation.  I agree about the macro idea -- I ran that
by my folks here as well, and I was told that for the time being we'll
shelve it, and move forward.  I'm glad that I'm not the only one that
sees it that way.

As for me, what I thought of doing was matching what OVAL is actually
doing at the OS level for its checks, and align it with the description
text that the user will see.  As you already know, so many people (in
the arenas who'll use this product) may/may not trust the check scripts,
and they may want to do their own checks.

Will commit per this reply of yours.

Thanks.

Mike

> Thanks -- please commit.
>
> It'll probably get some re-write (during a copy editing stage) and
> re-formatted likely even sooner than that (along with lots of other
> text).   We may also want to create some macros for repetitive text
> patterns such as partiton checking, such as was done for the
> sysctl-desc-macro.
>
> This is a good reminder that I need to determine and document where we
> want to put:
> 1) manual audit instructions ("check" -- though has sometimes been in
> the description tag)
> 2) manual remediation instructions (in "description" or "fixtext")
> 3) rationale (what DISA calls "Vuln Discussion")
>
> I need to do a quick survey and determine how best to migrate the
> content to this type of granularity while still achieving all the
> desired outputs.  That said, it's very important that in many cases
> already the_information_is_there, it's just a matter of formatting.
>
> It is not terribly important if we choose one place or the other for
> these, though a definite preference will be to place them where the SCAP
> specifications indicate is most appropriate. For users who need the
> information in a different tag, there's always XSLT to transform it.
>
> The manual audit instructions will be evolved into OCIL when it is
> adequately mature, which may inform its placement.  In general for
> instructive text, it is highly desirable to use broadly-acceptable,
> concise style that is re-usable by a wide audience.  Peculiar or
> Dalek-style speech should be avoided, though it is currently permitted
> in alternate titles files. Such special needs can be worked on a
> case-by-base basis.
>
> In general regarding tone (and I think your commit respects this
> principle well), the project's goal is to provide security technical
> implementation guidance (in a literal sense) for system administrators.
>  While the project is likely to be useful in creating documentation for
> a C&A package, it absolutely must be meaningful to system administrators.
>
> Thanks for the commit!
>
>
> On 09/05/2012 03:07 PM, Michael J. McConachie wrote:
>>
>> _______________________________________________
>> scap-security-guide mailing list
>> scap-security-guide at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide



More information about the scap-security-guide mailing list