Thanks for the reply, Martin.
> Gary, if I got your use case from this (and your subsequent email from
> today)
> correctly,
> the request being as follows:
> * on one hand to have a "profile / checklist" of all rules (grepped by
> their
> uniqueness) that ever existed for RHEL {6,7} products. All rules would be
> selected by default, and
> * to have possibility to score only subset of them during scan
What does 'grepped by their uniqueness' mean here?
Under 'grepped by their uniqueness' have meant more "human perception (IOW
rule names)"
level rather than "automated tool processing perception (IOW unique by rule
ids)" level.
Every single rule is
unique
in an XCCDF because it has to have a unique ID (enforced by XSD and
schematron).
Can 2 rules exist in a benchmark that you would consider not unique?
See above. Maybe my misunderstanding. Of course they would have unique ids, but was
thinking
more they to be unique in the sense for example if there's "Package aide
installed" rule
for both RHEL-6 and RHEL-7 content, the tool would / could recognize they are the same
and
display / offer for selection only one of them. Anyway, it's clear now this
wouldn't be
possible (your explanation above).
If each rule has @selected=true (this is recommended for all SCAP content),
then the default profile serves as such "all rules" profile.
Does openscap allow user to select which rules should be included in the
score
computation? I don't think so. If this feature is desired we have to
implement
it in openscap first.
Is this supported use-case by the standard? Or standard unrelated? If standard
doesn't forbids it, I would file a RFE against openscap for this.
> (feel free to correct me if I didn't the request details properly).
>
> Projected into scap-workbench functionality this means:
> * have possibility to merge various profiles (by grepping various but only
> unique rules),
> * have possibility how to specify the subset of rules (within that
> resulting
> checklist) that should be scored during scan.
>
> scap-workbench (SW) currently supports tailoring (e.g. a way how to select
> subset of rules from particular profile into new one). From that implies
> to me that the first point could be (possibly) reached with currently
> supported SW functionality as follows:
> 1) Select particular profile. Use tailoring. Select all rules from it, and
> save it.
> 2) Load another profile in the "Profile:" field of the SW section, load
the
> previously saved tailoring file, and click customize. Naive view
> suggests
> SW should in that scenario allow to add rules from the selected profile
> to the original tailoring (but didn't try it, so might be wrong)
>
> If not (Cc-ing Martin for hint on this), there should be a SW ticket:
> [1]
https://fedorahosted.org/scap-workbench/newticket
>
> created for this enhancement (please note you need to be logged in to be
> able to file new SW ticket).
I am having trouble understanding the use-case. Right now SW cannot merge
2 existing profiles into 1.
Yeah, was about merging (more exactly try to apply currently implemented functionality
to achieve merging of them).
You can however load a tailoring file and tailor
profiles in it, thus changing the profiles.
Sure (aware it's possible to tune actual profile by selecting only certain rules [IOW
make a subset of profile rules]).
But is it possible also enlarge the original profile with additional rules (those
copied / moved from another profile)?
I believe the latter satisfies
2).
If it allows also adding new rules (not present in the original profile, tailoring
was created from) then yes.
> For what is worthy regarding selecting just of a subset of rules, that
> should
> be scored during the scan, I don't think this is currently supported /
> possible
> in SW (Martin pls correct me here too). => This would need another ticket
> to
> be
> filed to cover this scenario.
I believe that is the case.
Was mainly checking if such use-case is allowed by the standard. If so, will file
a RFE for this (since looks as reasonable request).
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
--
Martin Preisler