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:
- 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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide