Could anyone speak to SSG support for check content written for SCE (vs. OVAL)? The developer's guide (section 7 intro) implies XCCDF check content is not required to be in OVAL, but in fleshing out support for checks later in that section it's hard to see how anything but shorthand OVAL could be supported. If not SCE directly, might it be possible to somehow use raw XCCDF snippets to incorporate SCE check content?
I'm on the hook to support some custom content for an internal need, and have found OVAL to be a bit inflexible (unless I want to propose extensions to OVAL itself which is a bit beyond the scope I can take on at the moment). One example is retrieving additional metadata from an RPM beyond what OVAL's rpminfo supports.
Admittedly, since my effort is internal, I'm misusing SSG in the sense that I wouldn't be contributing the custom content back to the SSG repo. SSG still offers an excellent framework for my isolated situation though, except that without support for non-OVAL checks, I'm not sure if I can author the content i need with it.
Ugh - sorry about the title on the thread - I meant to say Support for SCE checks, but didn't see a way to fix it after posting.
Hello,
as far as I know, SSG content currently does not support SCE checks. Our users seem to prefer standardized check language, in this case OVAL.
However, SCE engine can be installed as part of Openscap scanner. So if you manage to create a datastream which contains SCE checks, you can use Openscap to scan your systems.
If there is a need, I believe there could be implemented a change into build system which would allow to include SCE checks into the resulting datastream.
At the same time I think that there is a low chance of including such checks into upstream project. So you would probably have to create a fork and develop your SCE checks there.
Does that help?
Best regards,
Vojta
Dne 31. 07. 20 v 21:35 N B napsal(a):
Could anyone speak to SSG support for check content written for SCE (vs. OVAL)? The developer's guide (section 7 intro) implies XCCDF check content is not required to be in OVAL, but in fleshing out support for checks later in that section it's hard to see how anything but shorthand OVAL could be supported. If not SCE directly, might it be possible to somehow use raw XCCDF snippets to incorporate SCE check content?
I'm on the hook to support some custom content for an internal need, and have found OVAL to be a bit inflexible (unless I want to propose extensions to OVAL itself which is a bit beyond the scope I can take on at the moment). One example is retrieving additional metadata from an RPM beyond what OVAL's rpminfo supports.
Admittedly, since my effort is internal, I'm misusing SSG in the sense that I wouldn't be contributing the custom content back to the SSG repo. SSG still offers an excellent framework for my isolated situation though, except that without support for non-OVAL checks, I'm not sure if I can author the content i need with it. _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
Thanks for the reply. I guess there is not a way to include raw XCCDF in SSG either, then? If not, do you think it likely that inclusion of support for raw XCCDF would be of interest in the upstream project?
Hello,
I am not entirely sure what is your goal. From the previous mail I remember that you would like to use SCE checks because they offer you more flexibility than OVAL checks. And I remember that you would like to use them in your internal systems, therefore not propose them to the upstream. Am I right?
After your goal is clarified, we can try to come up with some technical solution.
Best regards,
Vojta
Dne 03. 08. 20 v 21:12 N B napsal(a):
Thanks for the reply. I guess there is not a way to include raw XCCDF in SSG either, then? If not, do you think it likely that inclusion of support for raw XCCDF would be of interest in the upstream project? _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
The specific content I am creating is not able to be proposed upstream. I was thinking though that the infrastructure to support it (the ability for SSG to support other SCE and/or raw XCCDF content) might be of interest upstream to provide future flexibility for content.
I brought up raw XCCDF since that would be another way to smuggle SCE content in without explicit support for SCE in the build scripts.
I can see an advantage here for the project as a whole - if we have e.g. Python checks, we could use them to to cross-test OVAL checks, that are less flexible and are more likely to be buggy.
I think that a rule sub-directory "python" or "shell", analogously to the current "oval" would provide a compatible way to supply the SCE content. Then, we would need the to extend the build system to pick it up and to deliver it to the datastream. And last but not least, we would need a mean how to disable it, as we probably want to be sure that we don't ship datastreams with SCE content to customers.
I don't see an easy way how to do it ATM, as the process of creating datastreams is quite complex. We in Red Hat don't plan to work on this in the foreseeable future. But I think that upstream would accept those contributions if the implementation was good enough.
On 04. 08. 20 16:51, N B wrote:
The specific content I am creating is not able to be proposed upstream. I was thinking though that the infrastructure to support it (the ability for SSG to support other SCE and/or raw XCCDF content) might be of interest upstream to provide future flexibility for content.
I brought up raw XCCDF since that would be another way to smuggle SCE content in without explicit support for SCE in the build scripts. _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
scap-security-guide@lists.fedorahosted.org
-
Matej Tyc -
N B -
Vojtech Polasek