Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFE] Implement universal replace_or_append() remediation function #611

Closed
iankko opened this issue Jul 14, 2015 · 3 comments
Closed

[RFE] Implement universal replace_or_append() remediation function #611

iankko opened this issue Jul 14, 2015 · 3 comments
Labels
enhancement General enhancements to the project. help-wanted This PR/Issue needs help to go forward. Infrastructure Our content build system

Comments

@iankko
Copy link

iankko commented Jul 14, 2015

As already mentioned in:
#572 (comment)

the majority of existing remediation scripts is performing the following tasks:

  • search some concrete text / configuration file for occurrence of a particular keyword,
  • verify if value for that keyword / config key is set to expected value,
  • if not, update the value of that key to the requirement,
  • if the key isn't found at all in the configuration file, append new line having the proper format
  key = new_value

Therefore this ticket is to propose introduction / implementation of new universal remediation function, which would hide the aforementioned tasks into its input arguments.

The proposed declaration is as follows (RFC):

replace_or_append($config_file_location, $key_to_search_for, $new_value)

with the explanation of arguments being as follows:

  • all of them would be required,
  • $config_file_location - the concrete configuration / text file remediation script to act on,
  • $key_to_search - the configuration file key, that should be searched for,
  • $new_value - new value of that key in the config / text file (where new value could be either plain string or some already known variable content).

After some review, there might be another optional parameters be necessary like:

  • $follow_symlinks = (yes|no) for the cases when remediation target is just symlink, but instead of updating it, we should update the target of the symlink,
  • etc. (further enhancements might be added once initial version is created)

Example calls of such a routine would be:

  • replace_or_append('/etc/sysconfig/prelink', 'PRELINKING', 'no') for the disable_prelink remediation,
  • replace_or_append('/etc/login.defs', PASS_MAX_DAYS, '$var_accounts_maximum_age_login_defs') for the accounts_maximum_age_login_defs remediation script,
  • replace_or_append('/etc/audit/auditd.conf', '^admin_space_left_action', "$var_auditd_admin_space_left_action") for the auditd_data_retention_admin_space_left_action remediation script
    ...

IMHO this approach could simplify the way we currently develop and maintain remediation scripts (it's easier to fix bug in one function, than to fix multiple remediation scripts). Also it's scalable (by adding benchmarks for new products we could develop remediation scripts more quickly). And the proper work of the script is verifiable via upstream test (we could provide selected input file to it, and compare via diff -s with expected output).

Comments / feedback / patches / PR welcome.

Thanks, Jan.

@iankko iankko added enhancement General enhancements to the project. help-wanted This PR/Issue needs help to go forward. Infrastructure Our content build system labels Jul 14, 2015
@shawndwells
Copy link
Member

This makes a lot of sense and would simplify the process of writing remediations.

Two initial thoughts:

#1: How would different name-pair values be set when the syntax is different, e.g.

VARIABLE ${some_value}

vs

``` VARIABLE=${some_value}````

#2: WRT to symlinks, we should normalizing using --follow-symlinks with sed during initial version, else we risk breaking end points.

@iankko
Copy link
Author

iankko commented Jul 15, 2015

This makes a lot of sense and would simplify the process of writing remediations.

Two initial thoughts:

#1: How would different name-pair values be set when the syntax is different, e.g.

VARIABLE ${some_value}

Was thinking of this and looks another optional $format_spec argument would be required. E.g. if not specified, the produced output would have the default format key = value (one space around the equal sign). When $format_spec defined, any format could be reached using the format specifiers for the printf bash routine. E.g. the example you quote above could be reached as follows:

replace_or_append("file.conf", "VARIABLE", "some_value", "%s \${%s}")

This way any of the output formats (supported by the bash's printf routine could be reached). Have verified bash on RHEL6 already supports the -v options (assigning output to variable instead of printing to stdout), so it should be possible to do something like:
printf -v formatted_output "%s \${%s}" "VARIABLE" "some value"

and then just replace any row in the "file.conf" containing "VARIABLE" with the value of $formatted_output.

vs

#2: WRT to symlinks, we should normalizing using --follow-symlinks with sed during initial version, else we risk breaking end points

Agree with this approach too. Maybe when performing the remediation we could check if "$config_file" is actually a symlink via test command, and if it is, update the target of the symlink automatically.

@redhatrises
Copy link
Contributor

When fixing this ticket, #548 should be fixed as well.

redhatrises added a commit to redhatrises/scap-security-guide that referenced this issue Dec 2, 2015
- Adds universal replace_or_append function to remediation_functions
- Provide a couple of examples of usage in existing remediation scripts
- Fixes ComplianceAsCode#611
- Fixes ComplianceAsCode#548
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement General enhancements to the project. help-wanted This PR/Issue needs help to go forward. Infrastructure Our content build system
Projects
None yet
Development

No branches or pull requests

3 participants