Anyone using rhel6 ssg for centos6?

Jeremiah Jahn jeremiah at goodinassociates.com
Fri Aug 22 15:19:33 UTC 2014


LOL. This was from a strictly coding point of view and I'm well aware
that this would probably never happen.   My general thinking in life
is to put all of the commonalities in the parent, and the
modifications in the child. This would let RHEL, Cent et al focus on
the commonalities, while any differences between them would go in each
special derivative.  At the same time I realise it's next to
impossible for RedHat to keep track whatever crazy things the Cent
folks have decided to change.  I'd fully expect RH to plop everything
they do into the parent section, and their derivative to make no
changes whatsoever.  Right now, it seems we have the following
unix->Linux->RHEL. I don't really see a lot of checks in Linux or
Unix.  So it would be nice to move as many checks up the tree to their
highest level. RH and debian are LSB derivatives, and obviously many
things derive even further from them. I'm not even sure where fedora
fits in all of that. So please don't take that part of my comments too
seriously, it was just food for thought.

On Fri, Aug 22, 2014 at 7:06 AM, David Smith
<dsmith at secure-innovations.net> wrote:
> One major thing in Jeremiah's comment really stood out to me:
>
>> In a perfect world I'd even suggest that RHEL is treated as a specific
>> RHEL_derivitive, just like SL or Cent.
>
>
> I'm not sure how it would make any sense to treat the original product
> (RHEL) exactly the same as the two major derivatives (CentOS and Scientific
> Linux).  The notion of treating a thing as a derivative of itself  just
> seems...odd.  There's naturally going to be something of a barrier to entry
> when one uses something developed for one thing and expects it to flawlessly
> work for that thing's derivatives.  RHT engineering and development have
> contributed significant time and resources to SSG to help ensure the
> guidance and content work perfectly with their product.  They cannot (and
> reasonably wouldn't) attempt to guarantee the supportability and
> applicability of SSG for derivative offerings, as the CentOS and SL dev
> teams could - at any point - alter something from the upstream.
>
>
> On Tue, Aug 19, 2014 at 9:51 AM, Jeremiah Jahn
> <jeremiah at goodinassociates.com> wrote:
>>
>> I understand the no government certification thing and not going to
>> argue with it. But as someone who uses Scientific linux most of the
>> time. I'd like to propose that we either add sl and cent or a generic
>> rhel derivative, perhaps by simply using a tailoring var. In a perfect
>> world I'd even suggest that RHEL is treated as a specific
>> RHEL_derivitive, just like SL or Cent. But I can only imagine the pain
>> that would cause.   I think what would be nice is if we make some
>> centos and sl generic profiles, and fix the platform check in the OVAL
>> definition. In a way that the derivative producers  wouldn't have to
>> mess with, but a specific user/ admin could with a simple tailoring
>> file.
>>
>> The problem as I see it right now, is that there is a pretty big
>> barrier to entry for admins of derivative systems.  Which means that
>> there won't be a lot of eyes on the guide except for the die hards,
>> who also happen to have the time.  And that doesn't seem like a good
>> long term thing.
>>
>>  I also get the sense that some of this cent os stuff is changing a
>> "little" bit  with RH pulling cent in under it's wing, but they'd be
>> foolish to get Cent certified in any official way. If you want true
>> certification, you should probably pay.
>>
>> just my 2 cents,
>> -jj-
>>
>>
>> On Fri, Aug 15, 2014 at 6:09 PM, Shawn Wells <shawn at redhat.com> wrote:
>> > On 8/15/14, 6:30 PM, Greg Elin wrote:
>> >> Shawn,
>> >>
>> >> Really interesting points.
>> >>
>> >> Can you also speak to Fedora vs RHEL and why Fedora is included?
>> >>
>> >> I think a CentOs generic is a smart approach.
>> >
>> >
>> > We've been very careful to not claim any gov baseline compliance with
>> > the Fedora content. Currently there is a generic/common profile:
>> >
>> >
>> > https://github.com/OpenSCAP/scap-security-guide/tree/master/Fedora/input/profiles
>> > --
>> > SCAP Security Guide mailing list
>> > scap-security-guide at lists.fedorahosted.org
>> > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>> > https://github.com/OpenSCAP/scap-security-guide/
>> --
>> SCAP Security Guide mailing list
>> scap-security-guide at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>> https://github.com/OpenSCAP/scap-security-guide/
>
>
>
>
> --
> SCAP Security Guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> https://github.com/OpenSCAP/scap-security-guide/


More information about the scap-security-guide mailing list