Feature: AppArmor Profile

[eslerm]

Please add an AppArmor profile. This will require a profile in main and it would be great if Authd could provide this directly.

Please take care to confine D-Bus.

Security is happy to review.

[didrocks]

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.

[eslerm]

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.

[didrocks]

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.

[gegarcia]

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.

[stendler-mlpa]

Not sure if this warrants a separate issue, so I report this here for now: the apparmor profile of fusermount3 needs adjustment for authd as well -- similar to the issue with fusermount3/flatpak on ubuntu 25.10 and polkit/unix_chkpwd + authd.

Current workaround is to add /etc/apparmor.d/local/fusermount3 with:

# Rules required if authd is used
@{run}/authd.sock rw,

[3v1n0]

Yeah, but the thing is that any application that can have user access (so that tries to get user information) should basically allowed to access to this socket.

So we should maybe just make our NSS library to fork to another process that does the proxy and give to that only access the authd socket?

[adombeck]

An AppArmor abstraction which profiles can include seems like the right solution to me. There's also /etc/apparmor.d/abstractions/nss-systemd.