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

Jeffrey Blank blank at eclipse.ncsc.mil
Wed Sep 4 02:31:23 UTC 2013


Hi Jan,

This is great to hear!   A subdirectory in SSG project would be most
welcome for Fedora content.  I am curious if you find the
scripts/transforms useful.  I have not tried scap-workbench lately,
but it is another way to create SCAP content.   At some point, we will
want to separate the common tooling from content.  But until then, I
guess we'll see where this goes!

I assume that a separate RPM for Fedora could be generated from the
toplevel Makefile in scap-security-guide.

When Shawn initially tried branching, it was not really adopted since
open development continued primarily for the RHEL content.  We would
need to update the wiki immediately if we started using branches.

As you have noticed, there are too many Rules/checks for RHEL, and I
would agree that you will want a smaller set for Fedora.  Removing
some of the Rules/checks for RHEL may have to wait for a RHEL version
change (7), since others are already using many of them.  With Fedora,
you have freedom to do what makes sense.

Jeff





On Tue, Sep 3, 2013 at 1:04 PM, Jan Lieskovsky <jlieskov at redhat.com> wrote:
> 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
> _______________________________________________
> 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