Yes, exactly. It was just a means of logical organization; there's
nothing else to it. And some choices were arbitrary/arguable.
Here was the basic thinking:
A service (rc script) that's tied to truly essential system-wide
functionality (such audit, logging, and network), and which also has
other configuration discussion, can go into input/system. All the
others can go into Services. (One could argue cron either way, of
course, but looks like it landed into services.)
I noticed that a duplicate or two may have sneaked into
services/base.xml (like auditd). That one (and any other dups) should
be removed from there. "Base services" was really just a means of
grouping potpourri that may not call for lengthier discussion (due to
limited configuration options, or limited importance).
If you think something should be placed elsewhere, lemme know. The idea
is that the resulting document order (whether prose or a table) should
group semantically-related things together.
On 03/20/2012 04:18 PM, Kevin Spargur wrote:
On 03/20/2012 03:40 PM, Michael Palmiotto wrote:
>>> It looks like if we want to achieve the "prose guide, with desktop
>>> and server profiles
>>> and content" milestones, content needs to be added to a couple of
>>> places:
>>>
>>> 1) The prose and rationale need to be added to
>>> rhel6/src/input/services or
>>> rhel6/src/input/system, depending upon what's being addressed.
>> Yes, this meets the M1.1 objective to have a "human-readable prose
>> guide, with level of completeness and quality similar to the NSA SNAC
>> RHEL 5 guide" as well as the M1.3 objective to have rationale for all
>> rules in the desktop and server profiles.
> Just for clarification:
> If a service Group has a Rule with system settings (ie Group:
> "Configure Squid"
> and Rule: "Configure iptables to Allow Access to the Proxy Server")
> should the Group
> be added to both rhel6/src/input/service and system?
>
> Or would the Rule just be added to service? It seems like we'd want
> some way of
> relating system settings prose back to the service that necessitates it.
I'd only add the group and rule to the service. We definitely want to
avoid duplication of rules in different sections. Remember that the
files in the service and and system directories are all merged together
into a single xccdf via make at the end state. The breakdown into
various folders and files is really just a means to facilitate
collaboration.
-Kevin
>
> --Mike
>
>> -Kevin
>>> --Mike
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/scap-security-guide