snapd

AppArmor blocks ibus input when IBUS_USE_PORTAL=1

Bug #1881232 reported by Anthony Wong
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
snapd
In Progress
High
Jamie Strandboge
snapd (Ubuntu)
Confirmed
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),

Samuele Pedroni (pedronis)
Changed in snapd:
importance: Undecided → High
status: New → Confirmed
Revision history for this message
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?

Samuele Pedroni (pedronis)
Changed in snapd (Ubuntu):
status: New → Incomplete
status: Incomplete → Confirmed
importance: Undecided → High
Samuele Pedroni (pedronis)
Changed in snapd:
assignee: nobody → Samuele Pedroni (pedronis)
Revision history for this message
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.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

I'll update the desktop interface. Thanks!

Changed in snapd:
assignee: Samuele Pedroni (pedronis) → Jamie Strandboge (jdstrand)
status: Confirmed → Triaged
Jamie Strandboge (jdstrand)
Changed in snapd:
status: Triaged → In Progress
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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