Closed iankko closed 8 years ago
Taking this one (unless someone bits me to it), I will implement this change somewhere during next month.
Do we have a use-case for this that's common enough to warrant the extra complexity? I think we shouldn't implement this at all.
I agree with Martin on this. What is the use case?
@mpreisler
Do we have a use-case for this that's common enough to warrant the extra complexity? I think we shouldn't implement this at all.
Suppose a use case when independent / 3-rd party certification authority is requesting to provide the benchmark in the form it to contain one concrete profile (they don't want to see the overall form of the default benchmark. They just want to see how the benchmark looks like for one concrete profile).
Another use case might be federal / government vs business environment company orientation. The former might want just the federal requirements included (e.g. USGCB, DISA STIG etc.) , the latter just the business requirements included (e.g. PCI DSS).
As the count of the available profiles per product will raise, IMHO it's just question of time, when this request will be officially expressed by the users.
Also, the implementation of this feature won't change the default benchmark form -- we would still include the all possible profiles into the benchmark when building the checklist for official distribution.
But would just provide a way how to create a restricted benchmark, when desired.
Suppose a use case when independent / 3-rd party certification authority is requesting to provide the benchmark in the form it to contain one concrete profile (they don't want to see the overall form of the default benchmark. They just want to see how the benchmark looks like for one concrete profile).
Can't we just cut it out manually and not have this additional complexity? It's easy to do and this action doesn't need to be performed often.
I haven't heard any user complain that we have too many profiles :-)
@mpreisler
Can't we just cut it out manually and not have this additional complexity? It's easy to do and this action doesn't need to be performed often.
Noticed, there oscap provides something like xccdf generate custom --stylesheet transform.xslt --profile ID --output_file new_xccdf.xml
. Will try that one instead of changing SSG build process (since it's less work :)).
I haven't heard any user complain that we have too many profiles :-)
Hopefully not yet (because as of right now there truly aren't that many of them). But /me hopes to we to reach this state one day :).
Thanks!
Will describe current situation for
RHEL/6
product below (the situation for other products is similar / analogous). As of right now the determination which profiles, available for the specific product, will be included in the produced benchmark is performed by specifying the list of profiles to be included in the:<product>/input/guide.xslt
XSLT transformation.The current form of this file for
RHEL/6
product (listing only issue interesting part of this transformation):Since during the build process it might be desired the users building the content to be able to specify the final list of profiles to be included in the benchmark, the build process should be modified / enhanced to allow this functionality.
The expectation being issuing a build command like the following:
make content PROFILES=C2S, desktop,usgcb-rhel6-server
(IOW calling
make content
target with `PROFILES=`` variable set to list of profile ids, split by comma)would produce a benchmark containing only these profiles included.
Side note:
PROFILES
is explicitly set,make content
would include just those profiles into the benchmark.