Greg,

I don't think that it should be too much of a problem migrating the profiles. See https://github.com/OpenSCAP/scap-security-guide/pull/550 for an example.

Gabe

On Thu, May 7, 2015 at 10:42 AM, Greg Elin gregelin@gitmachines.com wrote:

Fend and I are looking at moving a client from AWS Linux to RHEL7.

We are trying to figure how we can help migrate the existing RHEL6 XCCDF profiles to RHEL7?

A number of the baseline profiles available in RHEL6 package (e.g. USGCB and RHEL6-Server are not currently available in either the RHEL7 SSG package or the RHEL7 SSG built from source.

I've skimmed the issues and the wiki pages and did not seen anything exactly on topic for the profiles.

• Can these RHEL6 profiles easily be ported to RHEL7, or is it a big tasks

b/c of significant changes between 6 and 7?

• I'm treating the RHEL7 STIG as a separate baseline project from these

other pre-existing RHEL6 baselines (with some overlap, of course). Is that right way or wrong way to think about it?

• Does it make sense to put together a how to and/or coordination page to

discuss the availability and porting of profiles? Fen and I would like to help, but want tackle the problem efficiently.

• Is there an overall timeline or plan for managing the XCCDF profiles?

Thanks.

Greg

-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/

Hello Greg,

thank you for checking.

----- Original Message -----

From: "Greg Elin" gregelin@gitmachines.com To: scap-security-guide@lists.fedorahosted.org Sent: Thursday, May 7, 2015 6:42:18 PM Subject: Porting RHEL6 XCDDF Profiles to RHEL7

Fend and I are looking at moving a client from AWS Linux to RHEL7.

We are trying to figure how we can help migrate the existing RHEL6 XCCDF profiles to RHEL7?

Gabe provided an example already. Basically the work would be split into two steps: 1) first port the corresponding RHEL-6 profile to RHEL-7 by: * verifying the referenced rule exists for RHEL-7. Some of the rule names might need updating due to changed functionality (grub.conf in RHEL-6 vs grub2.cfg in RHEL-7, gconf in RHEL-6 vs dconf in RHEL-7 etc), * if the RHEL-7 rule doesn't exist yet, determine the reason for it. Possible cases which come to mind: ** rule exists for RHEL-6, but wasn't ported to RHEL-7 yet, ** rule isn't implemented in RHEL-6 yet => needs to be implemented for both RHEL-6 && RHEL-7, ** rule exists for RHEL-6, and also for RHEL-7, but isn't called yet. This needs the RHEL-7 rule to be tested for proper work, and corresponding symbolic link to be created.

Once the reason determined, keep the rule in the ported RHEL-7 profile version, but comment it with possible explanation / reasoning why it was commented (so people can extend on this work, can take rule of their choose, and can create pull request implementing it)

The first step covers porting of profiles. The second step (which I assume to be more time expensive) will be porting of RHEL-6 rules to RHEL-7 / implementing missing rules:

2) For the identified missing RHEL-7 rules port them / implement them to RHEL-7. This includes tasks like determining how the underlying feature / system property changed in RHEL-7, and porting / re-implementation of the existing OVAL check so it would work properly on RHEL-7 system too.

A number of the baseline profiles available in RHEL6 package (e.g. USGCB and RHEL6-Server are not currently available in either the RHEL7 SSG package or the RHEL7 SSG built from source.

I've skimmed the issues and the wiki pages and did not seen anything exactly on topic for the profiles.

It's because porting of the profiles is just part of it. But it's the first necessary step (we to identify the missing rules, identify the reasons why they are missing, and later schedule time to port / implement them).

• Can these RHEL6 profiles easily be ported to RHEL7, or is it a big tasks

b/c of significant changes between 6 and 7?

See the PCI-DSS example and above clarification.

• I'm treating the RHEL7 STIG as a separate baseline project from these other

pre-existing RHEL6 baselines (with some overlap, of course). Is that right way or wrong way to think about it?

Maybe look at it the following way - the regulations / rules / requirements doesn't change that often (of course they do but not the way there would be completely different requirements for newer product versions. There might be rules covering new functionality / new requirements, but I would say the base of the requirements "transits" from one product version to another / from the older to the newer). What changes being the product. So we need to apply / project those existing requirements to new product in addition with implementing the corresponding checks for requirements that have been added since the previous product version. Did this answer your question?

• Does it make sense to put together a how to and/or coordination page to

discuss the availability and porting of profiles? Fen and I would like to help, but want tackle the problem efficiently.

Ad howto - sure, we can create a draft to be evolved during time (maybe there's different way how to perform the port, different than is recommended above and that was used in: https://github.com/OpenSCAP/scap-security-guide/pull/550

Ad coordination page - since it looks there might be more contributors interested in participating on this, I would say we should create such coordination page.

I would be restrained to specify dates / exact SSG versions there (since from my experience during the development it might conclude something will take more time than originally planned [just because new OVAL feature needs to be designed and implemented to mention an example etc.])

But on the other hand, to cooperate effectively it would be nice to have a coordination page where people would select the rules they will be tentatively working at (so other contributors won't step on their feet / two or more people won't be working @ implementation / porting of the same rule leading to doubled effort => time waste && delays).

Having the rules separation (which RHEL-6 rules are working on RHEL-7 too, and which of them need to be ported / implemented yet) information is therefore crucial (and that's why those above suggested profile comments would be of big help if / when being available).

Yet one point - it can be observed the majority of the profiles extend the / inherit from the 'common' profile. Therefore when trying to have as much as possible rules being available in shortest time frame, I would suggest to start porting / implementing rules sitting in the 'common' profile. Since all the variant / flavour profiles derived from the 'common' one would just re-use the implementation.

• Is there an overall timeline or plan for managing the XCCDF profiles?

See above paragraphs why I would be reserved to specify exact dates / timeline for delivering a concrete profile ahead (to mention an example the RHEL-7 product changed the init system from SystemV init scripts to systemd. It took some time till the systemdunitproperty / systemdunitdependency probes have been designed && adopted into the OVAL language. It took some time to implement them in the OpenSCAP scanner. And finally it will take some time till all rules are ported to these new probes). In general the more the underlying system feature differs in Red Hat Enterprise Linux 7 from the corresponding feature in Red Hat Enterprise Linux 6, the harder is to sophistically predict how long it will take till the corresponding checks will be available in Red Hat Enterprise Linux 7.

Thanks.

Hope the above being helpful.

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

Greg

-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/