Disable storing core dumps.

[adelton]

Description:

• Disable storing core dumps.

Rationale:

• A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers trying to debug problems.

[adelton]

Technically the coredump.conf is an ini file, not a plain config file. However, there is only one section, [Coredump] there, so we won't be looking for the value in wrong section. However, if there is no section in that file, me might match and/or add the value outside of the expected section.

Is that a problem?

[ggbecker]

Hi @adelton, thanks for the patch. I have a few requests:

1 - The rule id for the rules you've created need to reflect the meaning of the configuration. I suggest to change coredump_processsizemax_0 to something like coredump_disable_backtraces, same situation with coredump_storage_none -> coredump_disable_storage.

2 - Regarding the ini configuration file, I've made some inline comments. But overall is ok to leave like that because we still don't support ini configuration files in the newly introduced macros/functions. But I'd like to ask @yuumasato if this is ok.

3 - Please add basic path test scenarios so the rules can be easily tested.

[adelton]

I've renamed the rules, added the section to OVAL, added the tests -> 4cf02c2.

[yuumasato]

I think we should treat it like an ini file, and mention correct section in rule.yml

By default /etc/systemd/coredump.conf already exists and [Coredump] section is there.
For this rules, we can state that the supported use case is remediation from default installation state, and remediation when file doesn't exist or doesn't have [Coredump] section is unsupported.
I suggest adding a general warning in the rule.yml, describing supported use case.

For the remediation, I suggest that they don't create the file, and add to end of file.
The ocil text should help remediate manually, so I think the correct section should be listed there as well.

[ggbecker]

I think we should treat it like an ini file, and mention correct section in rule.yml

By default /etc/systemd/coredump.conf already exists and [Coredump] section is there.
For this rules, we can state that the supported use case is remediation from default installation state, and remediation when file doesn't exist or doesn't have [Coredump] section is unsupported.
I suggest adding a general warning in the rule.yml, describing supported use case.

In order to illustrate the warnings attribute:

content/chromium/guide/chromium/chromium_policy_file/rule.yml

Lines 20 to 24 in f7ca4ca

	warnings:
	- general: |-
	If the <tt>.json</tt> file in
	<tt>/etc/chromium/policies/managed</tt> is not formatted correctly,
	no policies will be configured or set correctly.

[yuumasato]

I also suggest creating an issue to track that this rule needs to be updated to use ini capabilities when ready.

[adelton]

I've now rebased on master and added service_systemd-coredump_disabled -> a0ad45d.

[adelton]

Added an explicit commit to add the bits about [Coredump] section and to also not create the file when it is missing (as we would not add that section line) -> bb59ff9.

[yuumasato]

Thanks for the changes.