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. -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
