Porting RHEL6 XCDDF Profiles to RHEL7

Jan Lieskovsky jlieskov at redhat.com
Thu May 7 18:05:07 UTC 2015


Hello Greg,

  thank you for checking.

----- Original Message -----
> From: "Greg Elin" <gregelin at gitmachines.com>
> To: scap-security-guide at 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 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