Thanks for the hint! We would be happy to this, however we do have a few questions:

• authd is only a dbus client, not the daemon, is it relevant for an apparmor profile?
• do you have example of dbus confinement in such a case (client?).

Is the systemd service confinement not enough already? I’m afraid we don’t have the Apparmor expertise on our team, and so, we would like to have some guidance/help by the security team to unblock us here.

I'm reaching out for AppArmor expertise myself. I'll try to come back with some concrete examples from the AppArmor team.

AppArmor.d may have some useful examples, like polkitd or profiles that use features like nss.

Just to be clear, lack of an AppArmor profile will not block authd's MIR, but will be needed in 24.04.

Thanks for reaching out on guidance! That will really help us getting up to speed. We will still look at examples too (but I’m unsure in particular about the dbus part as we are only client there).

Please keep us posted once you have concrete profile examples we can shamelessly steal from :) That sounds like a perfect post Feature Freeze task.

It is not unusual to have AppArmor profiles for dbus clients, since dbus daemon verifies that bus communication is allowed by an AppArmor policy. Our recommendation is to use the AppArmor tools like aa-genprof and aa-logprof to exercise authd's code and construct the AppArmor policy that way. After you have a working policy, there might be still some denials that might be caught by corner cases, so while the policy is not mature enough, you could have the profile in complain mode. Complain mode allows what is not in policy, but it logs it in your system logs.