MDEV-39057: systemd: Add low risk hardening to unit templates

[aquilamacedo]

Adds a handful of conservative systemd hardening defaults to the upstream unit templates (support-files/mariadb.service.in and support-files/mariadb@.service.in). The goal is to improve systemd-analyze security without changing normal MariaDB behavior.

Enabled in this change:

• Kernel/cgroup protections: ProtectKernelTunables=true, ProtectKernelModules=true, ProtectControlGroups=true
• Block realtime scheduling: RestrictRealtime=true
• Lock personality: LockPersonality=true
• Restrict namespace creation: RestrictNamespaces=true (easy to override via a systemd drop-in if someone really needs it)

Intentionally not enabled:

I'm intentionally not touching the knobs that have historically caused regressions across distros / SELinux / PAM setups:

• NoNewPrivileges= (SELinux transition history, refs MDEV-10404)
• capability bounding / aggressive capability tweaks (refs MDEV-36591, MDEV-36681, MDEV-19878)
• PrivateDevices= (PAM/SUID helper history, ref MDEV-19878)

Happy to follow up with a separate PR for NoNewPrivileges=true (and anything else stronger) once this lands and we get broader feedback.

Downstream note (Debian)
This exact set of directives has been carried in Debian for ~1 month with no regressions reported so far. Context: https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/152.

Tested

• systemctl restart mariadb / mariadb@.service
• Checked journalctl -u 'mariadb*' for new errors/denials
• Compared systemd-analyze security mariadb.service before/after

[grooverdan]

Thanks @aquilamacedo.

Due to a limitation of PR, they don't run the full package tests. So https://buildbot.mariadb.org/#/grid?branch=bb-10.11-pr4787-systemd-hardening-safe-defaults-pkgtest is the same thing there where we'll see in the autopkg-install tests how things go on native kernels.

I added a removal of NNP which I was pretty confident about.

Capabilities where cleaned up in c461188.

PrivateDevices=false remove MDEV-36721 680b0cd

[grooverdan]

So much for my NNP confidence. It was in dealing with selinux, however caused the PAMv2 test to fai.

Attempt 2 - https://buildbot.mariadb.org/#/grid?branch=bb-10.11-pr4787-systemd-hardening-safe-defaults-pkgtest2 - which is exactly this PR.

Seems its something in this basic hardening preventing the PAMv2 failures.

Are you able to replicate https://buildbot.mariadb.org/#/builders/599/builds/4510/steps/5/logs/stdio in a local instance:
1.

sudo tee /etc/pam.d/mariadb
auth required pam_unix.so audit
account required pam_unix.so audit

2. using the credentials of a local account that exists in pam_unix instead of buildbot;

sudo mariadb -e 'INSTALL SONAME '\''auth_pam'\''; CREATE USER '\''buildbot'\''@'\''localhost'\'' IDENTIFIED VIA pam USING '\''mariadb'\'''

3. with the user and password

mariadb -ubuildbot -ptest -e 'SHOW GRANTS'

Adjust low risk hardening until there's a SHOW GRANTS that succeeds showing the user.

[gkodinov]

Thank you for your contribution! This is a preliminary review.

LGTM. Please stand by for the final review.

[aquilamacedo]

Thanks @grooverdan. I was able to reproduce locally on a Debian 12 VM (MariaDB 10.11.17-MariaDB-deb12, systemd 257) with the same setup:

• /etc/pam.d/mariadb with pam_unix.so audit
• local account buildbot:test
• INSTALL SONAME 'auth_pam'
• CREATE USER ... IDENTIFIED VIA pam USING 'mariadb'
• mariadb -ubuildbot -ptest -e 'SHOW GRANTS'

With those hardening directives enabled, PAMv2 fails the same way as in buildbot: auth_pam_tool reports Got error 1 from setreuid() and the login is denied.

What stood out is that mariadbd ends up with NoNewPrivs: 1, even though systemctl show still reports NoNewPrivileges=no

I also bisected the directives with a drop-in override. ProtectControlGroups=true keeps NoNewPrivs: 0 and SHOW GRANTS works. ProtectKernelTunables, ProtectKernelModules, RestrictRealtime, LockPersonality, and RestrictNamespaces each flip NoNewPrivs: 1 and break the PAMv2 test.

I just updated the PR to keep only ProtectControlGroups=true for now so the pkgtests pass.

Would it make sense to look at the other knobs separately later, maybe as an opt-in profile for setups that do not use auth_pam or other SUID-helper paths?