Hi everyone,
I have a question about the rules execution order. From my testing the execution order is simply the rule order inside a group of a benchmark. It looks like the order simply depends on the directory structure of linux_os/guide.
Is there a way to specify the execution order?
The reason I'm asking is the following. I have 3 rules A, B and C. Rules B and C can only be executed successfully if rule A was executed before.
A) package_X_installed B) service_X_enabled C) set_X_configuration
Sure, this is not a problem during normal evaluation, but the remediation scripts will need the dependency. Otherwise the package is not installed and the script will try to fix something.
An ugly workaround would be to run the remediation twice or three times, but this should be avoided.
Any idea anyone? :)
Regards, Alex~
On Wed, Apr 17, 2019 at 11:48 AM Alexander Bergmann abergmann@suse.com wrote:
Hi everyone,
I have a question about the rules execution order. From my testing the execution order is simply the rule order inside a group of a benchmark. It looks like the order simply depends on the directory structure of linux_os/guide.
Is there a way to specify the execution order?
The execution order is followed per the specification, so you would have to make sure that the rules are ordered correctly in the datastream itself and not the profile.
We will be raising this as an issue that needs to be fixed because it is causing problems.
The reason I'm asking is the following. I have 3 rules A, B and C. Rules B and C can only be executed successfully if rule A was executed before.
A) package_X_installed B) service_X_enabled C) set_X_configuration
Sure, this is not a problem during normal evaluation, but the remediation scripts will need the dependency. Otherwise the package is not installed and the script will try to fix something.
An ugly workaround would be to run the remediation twice or three times, but this should be avoided.
Any idea anyone? :)
Regards, Alex~
-- Alexander Bergmann abergmann@suse.com, Security Engineer, GPG:9FFA4886 SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) _______________________________________________ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
Hi Alex, the situation is only seemingly about ordering. The execution goes this way: 1) whole profile scan, create list of rules that 'fail' 2) run again, iterate over failed rules, remediate, and immediately scan for the rule again (if pass -> result is 'fixed', otherwise 'error')
No matter the order, applicability of the remediation is evaluated based purely on the first scan-only run.
So to solve this, every rule would have to be independent - your C shouldn't check for package installed or service running. Just report if configuration is or isn't there. (But then we are opening the can of worms that is "rule C does not make sense, if profile does not contain B and A").
Other option, if rules are dependent on each other, is to run remediation N-times where N is depth of dependency.
Regards, Marek
On 4/17/19 7:48 PM, Alexander Bergmann wrote:
Hi everyone,
I have a question about the rules execution order. From my testing the execution order is simply the rule order inside a group of a benchmark. It looks like the order simply depends on the directory structure of linux_os/guide.
Is there a way to specify the execution order?
The reason I'm asking is the following. I have 3 rules A, B and C. Rules B and C can only be executed successfully if rule A was executed before.
A) package_X_installed B) service_X_enabled C) set_X_configuration
Sure, this is not a problem during normal evaluation, but the remediation scripts will need the dependency. Otherwise the package is not installed and the script will try to fix something.
An ugly workaround would be to run the remediation twice or three times, but this should be avoided.
Any idea anyone? :)
Regards, Alex~
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://getfedora.org/code-of-conduct.html 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
-
Alexander Bergmann -
Gabe Alford -
Marek Haicman