SLE AIDE periodic check and remediation via systemd timer

[teacup-on-rockingchair]

Description:

• For SLE15 consider the possibility to enable AIDE periodic checks via systemd timer

Rationale:

• Modify oval shared check to include also option via systemd service and timer
• Add bash and ansible remediations for aide periodic checking via systemd timer

[github-actions]

Start a new ephemeral environment with changes proposed in this pull request:

sle12 (from CTF) Environment (using Fedora as testing environment)

Fedora Testing Environment

Oracle Linux 8 Environment

[marcusburghardt]

Nice. I wonder if other distros already use or tend to use systemd timer with AIDE. If so, it would be interesting to extend the existing remediation so other distros can also benefit on this. I will take a look in Fedora and RHEL. @dodys @freddieRv @Xeicker FYI

[dodys]

Nice. I wonder if other distros already use or tend to use systemd timer with AIDE. If so, it would be interesting to extend the existing remediation so other distros can also benefit on this. I will take a look in Fedora and RHEL. @dodys @freddieRv @Xeicker FYI

I wonder if this should be a new rule instead.
We aren't offering a way for people to choose one of the two solutions: cron or systemd timer. Instead in SUSE's bash they are choosing it for their users.
Also the name of the rule implies cron.

[teacup-on-rockingchair]

Nice. I wonder if other distros already use or tend to use systemd timer with AIDE. If so, it would be interesting to extend the existing remediation so other distros can also benefit on this. I will take a look in Fedora and RHEL. @dodys @freddieRv @Xeicker FYI

I wonder if this should be a new rule instead. We aren't offering a way for people to choose one of the two solutions: cron or systemd timer. Instead in SUSE's bash they are choosing it for their users. Also the name of the rule implies cron.

Well my motivation with the sle15 specific files was exactly this not to imply SLE policy and not make too many conditions in the shared files.

On the other hand, putting is as totally different rule in my opinion would duplicate too much of the logic. I agree the name is confusing, but if you say cron these days, I personally do not understand it as exact package or service, rather than type of functionality for scheduled execution of tasks.

[marcusburghardt]

Nice. I wonder if other distros already use or tend to use systemd timer with AIDE. If so, it would be interesting to extend the existing remediation so other distros can also benefit on this. I will take a look in Fedora and RHEL. @dodys @freddieRv @Xeicker FYI

I wonder if this should be a new rule instead. We aren't offering a way for people to choose one of the two solutions: cron or systemd timer. Instead in SUSE's bash they are choosing it for their users. Also the name of the rule implies cron.

Well my motivation with the sle15 specific files was exactly this not to imply SLE policy and not make too many conditions in the shared files.

On the other hand, putting is as totally different rule in my opinion would duplicate too much of the logic. I agree the name is confusing, but if you say cron these days, I personally do not understand it as exact package or service, rather than type of functionality for scheduled execution of tasks.

Thanks for the more context you both provided. I just tried to investigate this case and didn't find any package defining the aidecheck.service and aidecheck.timer by default, which is kind of expected since there is nothing similar for cron in the context of aide. For me, I feel that creating new systemd units is something a little bigger than including cron rules. Anyway, they are valid files but optionally defined by the user.

After thinking more about it, I am more inclined to agree with @dodys in creating a new rule for this.
This case you brought is pretty valid @teacup-on-rockingchair and I believe it deserves its own rule.
The hard work is basically done as I see in this PR. A new rule should not be difficult.
It could be called similarly, something like aide_periodic_checking_systemd_timer, for example. But the name I keep up to you. : )

As the benefits of creating this new rule I see:

• Both rules much simpler, which makes them easier to understand and maintain
• More granularity for profiles. Profiles can select both or only one of these two rules depending on each case

If in the future, for example, CIS drops cron approach in favor of systemd timer, we can simply update the profile by removing the cron rule. Otherwise, the rule would demand changes again and likely be split in any case.

[marcusburghardt]

Nice rule. I believe it might be useful for other products in the future. Besides some minor suggestion to descriptions, I only have some comments to make its adoption easier and some considerations in the Ansible remediation.

[marcusburghardt]

@teacup-on-rockingchair , this PR is almost ready to be merged, but cause of failures in CI tests should be fixed:
ValueError: The rule 'aide_periodic_checking_systemd_timer' isn't mapped to any component! Insert the rule ID to at least one file in '/__w/content/content/components'.

You should include this new rule in the components mapping, in the aide.yml file.

[codeclimate]

Code Climate has analyzed commit c9da482 and detected 0 issues on this pull request.

The test coverage on the diff in this pull request is 100.0% (50% is the threshold).

This pull request will bring the total coverage in the repository to 53.2% (0.0% change).

View more on Code Climate.

[marcusburghardt]

LGTM. Thanks

[marcusburghardt]

Overriding CODEOWNERS as @teacup-on-rockingchair can't approve his own PR.

[marcusburghardt]

I double-checked the failed CI tests and confirmed they can be waived. Tests successfully passed in my local VMs.