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

[Simon Deziel]

Hi Cedric,

On 2021-11-09 05:05, Cedric Müller wrote:
> 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.

As you found out, using systemd mount namespace features causes those 
"disconnected path" denials. AFAIK, the current workaround is to set the 
"attach_disconnected" flag like this:

profile mosquitto /usr/sbin/mosquitto flags=(attach_disconnected) {
   ...
}

This is generally not desirable due to the security implications as 
explained in https://gitlab.com/apparmor/apparmor/-/issues/125. There is 
AFAIK no other way to get mount namespaces and Apparmor so I use those 
more often then not.

HTH,
Simon