[RFE] Please provide "Remediate Dry Run" button / checkbox

[iankko]

Upon a system's feature failure reported by scan SCAP Security Guide users are faced the need to perform the remediation. Since this might seem like risky operation on the production system (till the moment a trust into correctness of the remediation scripts provided by SSG is obtained), there's often a need / request to have an in advance ability to see, what (which actions / code) would be actually executed when performing online remediation of the system.

Though openscap provides xccdf generate fix option, this possibility requires the users to be more familiar with the underlying SCAP standards concept (read like there might be initial barrier the users to be able to generate the fixes at their own, prior performing the actual remediation itsefl). We should lower this entry barrier by introduction of a new button / checkbox to the SCAP Workbench GUI, namely Remediation Dry Run (or use alternative name. Will leave the final decision at your own consideration).

The purpose of the new `Remediation Dry Run`` button / checkbox would be to:

• internally call oscap xccdf generate fix,
• and display the dialog containing list of scripts, that would be actually executed, when remediation is performed (another option is to export the generated fixes into text file and ask the user via dialog if they want to save such file - where and under which filename).

The expectation: The newly added Remediation Dry Run button / checkbox should be smart enough to be able to generate fixes in both cases:

• unmodified / not tailored benchmark - in that case oscap xccdf generate fix would be called for all rules that are by default selected for the specific chosen profile,
• modified / tailored benchmark - should a subset of rules be selected from the benchmark (IOW tailoring has been performed), in this case oscap xccdf generate fix would create text form of the remediation scripts only for rules present in that tailoring file.

Thank you, Jan

[ybznek]

Maybe I haven't understood well your idea.

Do you want to "only" show scripts?

I understand "Dry Run" rather like "run it on fake environment and show real changes."

You said that it is risky operation - it is easier to validate real changes than validate script - even for non programmer. I don't know possibilities, but we could run the scripts on some overlay FS over / - user will see real changes. - It isn't good for binary files, but for configuration it could be helpful.

What do you think?

[iankko]

Maybe I haven't understood well your idea. Do you want to "only" show scripts?

Yes, just show the corresponding script that would be actually executed for that rule.

I understand "Dry Run" rather like "run it on fake environment and show real changes."

Maybe "dry run" wasn't chosen well. Basically it should be "test" (like. e.g. authconfig's --test option:

--test                  do not update the configuration files, only print new settings

Applied to SCAP Workbench case, we wouldn't perform the remediation itself, just show the script)

You said that it is risky operation

It was rather meant it might be perceived like risky operation. Not like SSG remediation scripts aren't trustworthy :) (if there's some issue with them, we will fix that). But system administrators might want to have a look what would be executed, before they run the remediations.

• it is easier to validate real changes than validate script - even for non programmer. I don't know possibilities, but we could run the scripts on some overlay FS over / - user will see real changes. - It isn't good for binary files, but for configuration it could be helpful.

The original idea was just to print out the scripts forms (basically supply some GUI for oscap xccdf generate fix). But I like the dry run idea too. Just would make it another step in handling this (like first implement the "Test" checkbox / button, then the "Dry Run" checkbox / button).

What do you think?

Thanks, Jan

What do you think?

[ybznek]

Yes, implementing this like two different features is a good solution, because we could have problem with not supported file systems in rhel6, etc.. So "Test" will be available everywhere and "Dry Run" only on supported platforms.

[mpreisler]

No way this is happening in 1.1.3...

[BobBagwill]

IMHO, remediation should be a second step anyway and each remediation should be individually selectable and editable.