AppArmor blocks ibus input when IBUS_USE_PORTAL=1

[Anthony Wong]

ibus can't be used in the telegram-desktop snap on Focal, input methods can be changed but any typing will simply be sent directly to the input area.

It's suggested in https://github.com/telegramdesktop/tdesktop/issues/2013#issuecomment-614037383 to use IBUS_USE_PORTAL=1, but it requires other dbus communication to be allowed.

I added the following rules to /var/lib/snapd/apparmor/profiles/snap.telegram-desktop.telegram-desktop, after that ibus works when running with IBUS_USE_PORTAL=1 :

dbus (send)
      bus=session
      path=/org/freedesktop/IBus
      interface=org.freedesktop.IBus.Portal
      member=CreateInputContext
      peer=(label=unconfined),

dbus (send)
      bus=session
      path=/org/freedesktop/IBus/InputContext_[0-9]*
      interface=org.freedesktop.IBus.InputContext
      member={SetCapabilities,ProcessKeyEvent,Reset,FocusIn,SetCursorLocation}
      peer=(label=unconfined),

dbus (receive)
      bus=session
      path=/org/freedesktop/IBus/InputContext_[0-9]*
      interface=org.freedesktop.IBus.InputContext
      member={UpdatePreeditText,CommitText,HidePreeditText}
      peer=(label=unconfined),

[Jamie Strandboge (jdstrand)]

Based on https://github.com/flatpak/flatpak/issues/675, this seems like it would be safe to add to the desktop interface. James Henstridge, can you comment?

[James Henstridge (jamesh)]

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.

[Jamie Strandboge (jdstrand)]

I'll update the desktop interface. Thanks!

[Jamie Strandboge (jdstrand)]

I was able to reproduce the issue and resolve it with the suggested policy with James' suggestions. Thanks!