AppArmor blocks ibus input when IBUS_USE_PORTAL=1

Bug #1881232 reported by Anthony Wong on 2020-05-29
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
snapd
High
Jamie Strandboge
snapd (Ubuntu)
High
Unassigned

Bug Description

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),

Changed in snapd:
importance: Undecided → High
status: New → Confirmed
Jamie Strandboge (jdstrand) wrote :

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?

Changed in snapd (Ubuntu):
status: New → Incomplete
status: Incomplete → Confirmed
importance: Undecided → High
Changed in snapd:
assignee: nobody → Samuele Pedroni (pedronis)
James Henstridge (jamesh) wrote :

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) wrote :

I'll update the desktop interface. Thanks!

Changed in snapd:
assignee: Samuele Pedroni (pedronis) → Jamie Strandboge (jdstrand)
status: Confirmed → Triaged
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.