[apparmor] what is the best way to write apparmor dbus rules

[John Johansen]

On 11/7/23 03:34, Alexandre Pujol wrote:
> Hi all,
> 
> I am working on rewriting dbus rules for the apparmor.d [0] projects.
> And it let me to the general question on what is the best way to write
> dbus rule in apparmor.
> 
> The current implementation could be summed up as simply adding to a
> profile whatever dbus rule has been raised in the log. It is simple as
> it is mostly automatic (thanks to `aa-log -r`). However, it can generate
> a lot of rule [1] and, it is not maintainable.
> 
> I had a look at how dbus are managed on flatpak [2] and snap [3], and I
> was wondering if a similar construction could be used in apparmor profile.
> 
> For instance, the profile polkitd [4] owns the interface
> org.freedesktop.PolicyKit1*, so the rules in the polkitd profile could
> be setup as:
> 
> ```
>     dbus (bind) bus=system name=org.freedesktop.PolicyKit1,
> 
>     dbus (send,receive) bus=system
>          interface=org.freedesktop.PolicyKit1*
>          peer=(name=:*),
> ```
> 
> while program sending request to polkitd could have rules such as:
> ```
>     dbus send bus=system
>          interface=org.freedesktop.PolicyKit1*
>          peer=(name=:*, label=polkitd),
> ```
> 
Indeed this is actually what should be done. The issue is so far
its mostly Ubuntu using dbus (yes, my fault, kernel issues ... but it is
finally coming), and Ubuntu has chosen so far to not even loosely confine
the end points. If the end points even just do

   profile polkitd { allow all, }

then at least we have end point labeling and can use that to simplify
some. The other part of the intention is that dbus rules would get
grouped into include files, so common sets of rules become

   include <abstraction/PolicyKit/XXX>

where if you want all PolicyKit access you could do a dir inclue


> 
> I am not an expert in dbus at all, therefore I was wondering if such a
> setup could be useful. Do we need more/less restriction in the rule? Do
> any of you have other recommendations on how these dbus rules should be
> managed.
> 
what we need is to get the endpoints labeled with something more than
unconfined (you have a good start at that), and then we need to start
creating abstractions.

Some of the rules could be like you proposed with
> ```
>     dbus send bus=system
>          interface=org.freedesktop.PolicyKit1*
>       

but there are services that you may not want to grant all methods,
and we should have a set of abstractions for. The issue is then
figuring out which rule need to be grouped together for an abstraction
and how fine grained the abstractions should be.

> Regards,
> Alex
> 
> [0]: https://github.com/roddhjav/apparmor.d
> [1]:
> https://github.com/roddhjav/apparmor.d/blob/4df3f2e52f846d66dd9bf0e45dce4063e315005d/apparmor.d/groups/gnome/gnome-shell#L59-L462
> [2]: https://docs.flatpak.org/en/latest/sandbox-permissions.html#gvfs-access
> [3]: https://forum.snapcraft.io/t/the-dbus-interface/2038
> [4]:
> https://github.com/roddhjav/apparmor.d/blob/4df3f2e52f846d66dd9bf0e45dce4063e315005d/apparmor.d/groups/freedesktop/polkitd
> 
>