Possibility of Fedora SCAP content to be served by SCAP security guide repository (either as subdirectory or via separated branch)?

Shawn Wells shawn at redhat.com
Tue Sep 3 16:22:50 UTC 2013


On 9/3/13 9:26 AM, Jan Lieskovsky wrote:
> Hello Jeff, Shawn, SCAP security guide people,
>
>    [Sorry if this is not the appropriate place to discuss the topic
> below. If so, kindly direct me to proper contact people. Thank you.]
The public mailing list is *absolutely* the desired location! Thanks for 
moving this discussion to on-list!



>    {Sorry for such a long post, but got much information to share.}
>
> We have internally discussed possibility to start creating SCAP content
> for Fedora distribution. Snippet of previous conversation(s) below:
>
> Subj = 	Fedora SCAP content adoption [was: Re: Challenges in SCAP adoption]:
> ============================================================================
> Hello guys,
>
>    please find below draft we have agreed upon so far how
> Fedora SCAP content next steps should look like (from discussion
> at #openscap):
>
> #1 Create Fedora subdirectory (preferably with Fedora version subdirectory yet)
>     in the upstream SSG git repository,
> #2 Create new Fedora package (to be posted for review and maintained by
>     me) to be generated based on the content of that directory,
> #3 Content provided by this package should be the primary source of
>     content, when doing oscap scans on Fedora hosts in the future.
>
> For the content of that Fedora directory itself:
> - Red Hat Security Technologies Team point of view:
>    * to have 3-rd party standardized content, which would be subset
>    of content we currently have for RHEL-6 to be possible to scan Fedora hosts
>    too,
> - Red Hat Product Security Team point of view:
>    * to have content / policy / rules to check issues interesting from
>    security point of view (like the recent Amazon rootpw kickstart issue was)
>
> The standardized Fedora content would be generated and maintained by me.
> For the security issues content the maintainer needs to be agreed upon yet
> (probably Dhiru will take this responsibility?)
>
> Questions / comments welcome.
>
> Thank you && Regards, Jan.
> --
> Jan iankko Lieskovsky / Red Hat Security Technologies Team
>
> Shawn Wells has replied to this with the following (selected only relevant bits
> from the reply):
> ================================================================================
>> For the content of that Fedora directory itself:
>> - Red Hat Security Technologies Team point of view:
>>     * to have 3-rd party standardized content, which would be subset
>>     of content we currently have for RHEL-6 to be possible to scan Fedora hosts
>>     too,
> As a starting point, the "common" profile from RHEL6 may be of interest.
> It reflects rules we've found to be consistent across all baselines
> (STIG, USGCB, FISMA) however has generic refine values for things like
> password length. Code:
>    https://git.fedorahosted.org/cgit/scap-security-guide.git/tree/RHEL6/input/profiles/common.xml
>
> Below is my proposal regarding initial Fedora directory content, as sent to Shawn in
> private message:
> ====================================================================================
> * Part #1 regarding repository content:
>
> I have had brief look at the common profile (thank you for that
> direction Shawn):
> [1] https://git.fedorahosted.org/cgit/scap-security-guide.git/tree/RHEL6/input/profiles/common.xml
>
> but prior proposing any actual content changes in the SSG repository,
> wanted to check "how things works / are expected to work" (mainly
> in the sense of relation with scap-security-guide mailing list people)
> with you.
>
> I can create Fedora package spec / src.rpm proposal - when creating
> this one i think Fedora subdirectory should follow the common directory
> structure, i.e.:
> * distro/
>      * input
>      * output
>      * references
>      * transforms
>      * utils
>
> subdirectories, the Makefile and README files.
>
> For the beginning i would say the 'input' subdir should have at least 'intro'
> subdir, and guide.xml && guide.xslt files (of course 'profiles', 'checks' etc.
> to come later).
>
> These are all technical things, i should be able to handle (submit that
> Fedora package for review, when it's time comes etc.).

Directory structure makes sense, and would provide consistency for 
existing content authors.

Currently there is a single RPM which deploys content for both JBoss and 
RHEL6. Is it preferred to have a unique Fedora content RPM, or should 
the existing RPM be modified to include Fedora content? Given the 'EPEL' 
nature of the existing RPM, I'm OK with combining things though I don't 
know the subtleties of the Fedora packaging regulations.


> But what i mainly wanted to check with you being how i am expected to communicate
> these changes on scap-security-guide mailing list. Should we first communicate this /
> schedule a meeting with Jeffrey Blank regarding this? Will you communicate this with
> Jeffrey? Or should these intentions be communicated on SSG mailing list first? Shawn,
> your guidance here would be appreciated.
Jeff & I are certainly stakeholders, but we're part of a much larger and 
active community. Personally, I'd much prefer to have transparent 
conversations in the open wherever possible.

> I think once this skeleton of Fedora directory is agreed upon, we can follow up
> with discussion wrt to upcoming content (assuming to be based on subset of 'common.xml'
> profile checks).
>
> To summary:
> ===========
> * after internal mailing communication we agreed on it's time to start creating
>    Fedora SCAP content,
>
> * the current proposal is this content to live in SCAP security guide repository
>    under dedicated Fedora subdirectory (or under dedicated git branch),
We thought about creating branches for the various content platforms 
(e.g. RHEL6, RHEVM, JBossEAP) though the added complexity didn't seem 
worth it. Right now we have a single git branch, vs a "dev," "stable" 
etc setup. This shouldn't be thought of set in stone... best practice 
ideas from your dev perspective would be most welcome!


> * we can / will handle the technical issues (provide content for the subdirectory
>    [which after common SSG patch approval process would be committed into SSG repo],
>    create directory structure, create package for Fedora distribution, handle it's
>    review process etc. when it's time comes etc.,
>
> * but prior actual sending of initial patch (realizing the above proposals),
>    wanted to communicate these intentions with you to see if you / SSG members
>    would have some objections against this to be realized. If so, please let us
>    know (also in case there is different procedure expected to be pursued,
>    when proposing such changes, let us know which one that is).
With the RHEL6 content there are several people trusted with ack'ing 
patchsets. How is Fedora patch sign-off envisioned?

Meaning, do you envision "community signoff" -- e.g. standard 3rd party 
review process, but anyone in the community can ack -- or should ack's 
be received through yourself/Josh/Dhirendrea before a push?


More information about the scap-security-guide mailing list