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

Jan Lieskovsky jlieskov at redhat.com
Tue Sep 3 17:04:03 UTC 2013


Hi Shawn,

  thank you for your reply.

> 
> 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!

Ok, good (wasn't sure not to leak something prematurely). But transparency
is definitely welcomed.

> 
> 
> 
> >    {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.

To be consistent was the intention (not to put another blocks wrt to
existing understanding / quick start up).

> 
> 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.

Separate RPM would be preferred afaics (RHEL and Fedora have different
release cycles. Right now not definitely sure this might be a problem
in the future, but better to start as separate content for any case).

> 
> 
> > 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.

Sure, understandable (was just afraid not to leak something - still new
to this list).

> 
> > 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 have talked (within our team) about this a bit yesterday. While subdirectory
approach might seem easier, git branch way could simplify cloning the future
RHEL-6 content (would merge instead of copy manually). Again, right now
not completely sure a moment in the future will come the subdirectory
approach to show as bottleneck. More trying to think what can go wrong
if we use subdirectory approach, than truly stand on it needs to be a git branch
based way.

> 
> 
> > * 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?

To be honest this is not clear yet. Maybe it would help if you could
clarify why they are trusted for RHEL-6 - like they are approved by 3-rd party
or they have proven to understand the underlying RHEL-6 environment in a way,
they can be considered authorities?

Once this is clear, we can sketch how to manage the same for Fedora content.

> 
> 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?

I am not that far in understanding SCAP / OVAL / XCCDF content yet, I would
propose myself to do the review. Of course, something else is validity / correctness
of OVAL definitions taking into account the nuances of a Fedora system
(IOW how to get some test to work correctly for Fedora system) - I could offer my
help here.

But for what is worthy regarding general XCCDF validity, (I think) we would
definitely welcome SCAP security guide community help here.

> 

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team


More information about the scap-security-guide mailing list