Delete first control

[rndmh3ro]

I propose to delete this control since I don't think that it is useful:

1. it's not useful from a security perspective. Actually it would be more secure to have the database stopped. ;)

2. other tests need a running database, so these will fail anyway. there's no gain in another control that tells me that the database isnt running

Signed-off-by: Sebastian Gumprich [email protected]

[chris-rock]

This control was more intended to make sure that the database is up after a system restart.

[schurzi]

Thinking about it, your proposal for not checking that the database is running is correct. But the second part about auto-start is more difficult. Consider automatic system updates where it is favorable to know, that the database starts automatically.

[rndmh3ro]

Consider automatic system updates where it is favorable to know, that the database starts automatically.

Sure, but is this a security control? IMO no
There are also some scenarios where automatic starts aren't desirable, e.g. when running the database with corosync/pacemaker or you need to set a decryption key to start the database.

[schurzi]

I'd argue, that this is what waivers are for. I remember a discussion in the past, where we defined the purpose of our Ansible Collections to be easy to understand and appropriate for a starting to advanced user. Since we use the baseline also for testing our collections this control serves a purpose for me.

Dropping this control would imply, that we should also remove the code from our Ansible Collection and expect the user to add their own Playbooks to make sure the database runs like they desire.

[rndmh3ro]

Dropping this control would imply, that we should also remove the code from our Ansible Collection and expect the user to add their own Playbooks to make sure the database runs like they desire.

We do not install any database with our hardening-collection (neither does the chef implementation). "An existing MySQL installation" is required according to the docs: https://github.com/dev-sec/ansible-collection-hardening/tree/master/roles/mysql_hardening#requirements

So why make sure it is running? There would be no need to change anything on our side.

[schurzi]

I was thinking of this part of our Ansible Collection: https://github.com/dev-sec/ansible-collection-hardening/blob/master/roles/mysql_hardening/tasks/configure.yml#L61-L64

I think my only problem with this change is, that we would reduce our test coverage and I would like to have some alternative. Maybe we can create another baseline that covers basic operations?

[schurzi]

So @rndmh3ro and I hat a longer in person chat.

Basically my argument resolves to "we have always done it this way". This baseline is meant to ensure our implementations stay consistent and since this control has been implemented everywhere it is a recognized standard. Removing this control leads to diverging implementations. This does not lead to a chicken and egg situation, since the baseline is also the leading repository for everything we implement. This means every new control is first implemented here and then in our Puppet/Chef/Ansible repositories. This holds also true for removing controls. So this step is acceptable considering the stated argument.

The next viewpoint was "why are we not managing the mysql service". A parallel could be drawn to our ssh hardening. There we install and manage the service in our implementation. This is not true for MySQL, since there are now many different flavors of MySQL (Oracle, Percona, MariaDB) and we would also have to consider if we use the vendor version, or the distribution provided version. We have opted for letting the user pick a way of installing MySQL, that suits their requirements. Usually the installation methods also manage the service. so our control/implementation seems redundant here.

Regarding our current state, we should remove this control, since it has nothing to with hardening. But we should create an additional check in our Ansible Collection, that keeps a verification of the currently implemented behavior.