Comment 2 for bug 1881232

This looks like a good candidate for the "desktop" interface. Security is significantly better than the traditional IBus communication method, since access to IBusContexts are restricted to their owner:

https://github.com/ibus/ibus/blob/master/portal/portal.c#L354-L370

... and IBusContext signals are unicast to the owner rather than broadcast:

https://github.com/ibus/ibus/blob/master/portal/portal.c#L408-L414

Further more, IBus's non-portal communication method goes over a separate socket connection. So any session bus rules we add should not inadvertently provide access to the insecure API.

I would also consider merging the last two proposed rules into one like so:

dbus (send, receive)
      bus=session
      path=/org/freedesktop/IBus/InputContext_[0-9]*
      interface=org.freedesktop.IBus.InputContext
      peer=(label=unconfined),

It doesn't look like there is any methods with different level of privilege on the interface, and this avoids incompatibilities if IBus evolves in future.

We probably also want to allow communication with peer=(name=org.freedesktop.portal.IBus) for the base CreateInputContext API, since the service file does not contain an AssumedAppArmorLabel field that would allow service activation to succeed otherwise.