[apparmor] AppArmor denies access, when systemd namespace used by hardening directive (e.g. ProtectHome)

[Cedric Müller]

Hi,

in the last weeks, I tried to find a configuration set to harden the MQTT message broker Mosquitto. Therefore, I want to use properly configured permissions for discretionary access control and an AppArmor profile for mandatory access control. In addition, I want to apply systemd sandboxing and security hardening directives to complete the configuration set.

For more context: Systemd provides a socket /run/systemd/notify, where it listens for messages such as whether a service (e.g. Mosquitto) is ready (in which case systemd will transition the status to started).
This socket is owned by root and the permission set is 777. Also, Mosquitto's AppArmor profile allows write access to this socket.

With these setting, everything is working fine. No Deny-messages in auditd because of AppArmor. The Mosquitto service could report his status to the socket and systemd shows it when using systemctl status mosquitto.service.

For my last step, using systemd sandboxing and security hardening directives, I added the directive ProtectHome=yes (see https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectHome=) to Mosquitto's unit file and restarted the service. Now, auditd logs a denied message from AppArmor for the Mosquitto binary for /run/systemd/notify and systemd does not update the status of the Mosquitto service.

See the kernel message output: [644.118984] audit: type=1400 audit(1635945247.591:33): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mosquitto" name="run/systemd/notify" pid=452 comm="mosquitto" requested_mask="w" denied_mask="w" fsuid=107 ouid=0

What I found out so far: When ProtectHome is activated, systemd starts the binary in a new mount namespace. When started in this mount namespace, AppArmor denies access, otherwise not.

Now some additional information. I'm using the Debian based distribution Apertis (see https://apertis.org) with Systemd 241-7, AppArmor 2.13.2-10 and Mosquitto 1.5.7-1.

A different but more high-level discussion would be, if these systemd boolean directives should be used at all, when I'm using AppArmor anyway, because some of these systemd directives are overlapping to features from AppArmor. I'm very interested in your opinions and I'm sure, some of you can help me with these issues and thoughts. This is my first e-mail on a mailing list, do not hesitate to contact me in case of any questions.

Best regards,

Cedric