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

[John Johansen]

On 11/10/21 12:25 PM, Simon Deziel wrote:
> 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.
> 

correct. We are working on fixes/improvements but they are not available yet.