Thunderbird snap can access X11 although not plugged (debian 11)

snapd
#1

hi,

when I started my debian 11 system i noticed, that the thunderbird snap was suddenly using X11 instead of wayland. I noticed it because I have a xeyes running and it was reacting to the mouse position.

So i checked and disconnected thunderbird from the slot:

$ snap connections thunderbird
...
Interface                 Plug                                  Slot                             Notes
wayland                   thunderbird:wayland                   :wayland                         -
x11                       thunderbird:x11                       -                                -

Restarting thunderbird did not change anything. xeyes still gets the input from thunderbird.

In the end I want to run thunderbird again on wayland, but the more important issue is that the snap should not have been able to communicate with X11. I think this should not happen. I want to prevent the apps from accessing X11.

Thunderbird snap version installed: 102.0.1-2 (228) 105MB -

This is inside a gnome wayland user session.

~$ snap version
snap    2.56.2
snapd   2.56.2
series  16
debian  11
kernel  5.10.0-16-amd64

$ snap connections thunderbird
Interface                 Plug                                  Slot                             Notes
audio-playback            thunderbird:audio-playback            :audio-playback                  -
avahi-observe             thunderbird:avahi-observe             -                                -
browser-support           thunderbird:browser-sandbox           :browser-support                 -
camera                    thunderbird:camera                    -                                -
content[gnome-3-38-2004]  thunderbird:gnome-3-38-2004           gnome-3-38-2004:gnome-3-38-2004  -
content[gtk-3-themes]     thunderbird:gtk-3-themes              gtk-common-themes:gtk-3-themes   -
content[icon-themes]      thunderbird:icon-themes               gtk-common-themes:icon-themes    -
content[sound-themes]     thunderbird:sound-themes              gtk-common-themes:sound-themes   -
cups-control              thunderbird:cups-control              :cups-control                    -
desktop                   thunderbird:desktop                   :desktop                         -
desktop-legacy            thunderbird:desktop-legacy            :desktop-legacy                  -
gpg-keys                  thunderbird:gpg-keys                  -                                -
gsettings                 thunderbird:gsettings                 :gsettings                       -
home                      thunderbird:home                      :home                            -
network                   thunderbird:network                   :network                         -
network-control           thunderbird:network-control           -                                -
opengl                    thunderbird:opengl                    :opengl                          -
removable-media           thunderbird:removable-media           -                                -
system-files              thunderbird:etc-thunderbird-policies  :system-files                    -
u2f-devices               thunderbird:u2f-devices               -                                -
wayland                   thunderbird:wayland                   :wayland                         -
x11                       thunderbird:x11                       -                                -
#2

bump. Anybody can please advise me where to bring this up? Should i open an issue for debian or snapd?

#3

update: i did put up a bug report against snappy in launchpad but it seems nobody had a look https://bugs.launchpad.net/snappy/+bug/1981576

i later found out that the wayland socket is not linked in the thunderbird snap, so thunderbird falls back to X11

note that i think the correct behaviour without that socket is to crash (which happens on ubuntu)

next step: will put up a bug report against snapd in debian

#4

The underlying issue seems that there is only support-level:partial for apparmor on debian (which is poorly documented).

It seems expected that network support etc to may be be fixed kernel-side in 2023 (after LSM stacking is merged?). So maybe that is necessary to stop access to the X11 socket? I do not know how long it would take to be available after that in debian.

If possibly it would be good to point out that a plug does not matter when running snap connections if the underlying capacity is missing (Maybe in the Notes column?).

#5

Did you actually force wayland usage in thunderbird at all ? Iā€™m pretty sure it will always default to x11/xwayland unless you force it to by setting the env variable it needs for thisā€¦

Under a wayland session it will use xwayland which will at least restrict its access to only be able to read I.e. keystrokes from other x11 apps, but not wayland onesā€¦ both of this is completely unrelated to snap confinement thoughā€¦

#6

there are multiple issues here. the context for following all about the thunderbird snap in a wayland desktop session

  1. the snap does not create a link/access to the wayland socket. It does this neither on debian nor ubuntu
  2. if i remove the x11 connections on ubuntu (i have MOZ_ENABLE_WAYLAND=1 set), starting ubuntu fails as long as i do not create the link to the wayland socket
  3. if i remove the x11 connection on debian, thunderbird still works (but should not) - this is what the OP was about. After investigating i blame this on debian just offering partial support for apparmor. Which makes snap as a sandbox mostly useless for me on debian

The question for me is not if thunderbird uses wayland or X11. Using wayland is not enough. The question is the sandbox issue. The snap should not be able to use/talk with X11. (And at least on ubuntu i have the MOZ_ENABLE_WAYLAND=1 set if I snap run --shell thunderbird)

#7

Ah, right, it is less Debians fault then it is the lack of having the final two apparmor patches upstream ( indeed you could blame Debian for insisting to never add patches on top of the upstream source of the kernel, but after all all distros using plain upstream will have this problem until the remaining patches are merged in the kernelā€¦ ubuntu simply ships these by default)

1 Like
#8

i had another look the discussions about current state of upstreaming. So if i get it right, besides a compatible kernel the distribution needs to support #apparmor v3 . The next stable #debian ā€œbullseyeā€ which is expected to land next month provides apparmor (3.0.8-3), so I guess for bookworm it should be possible.

Maybe OS support for apparmor v3 that wonā€™t be not necessary anymore with snap 2.6 ?

New in snapd 2.60:

  • Support for dynamic snapshot data exclusions
  • Apparmor userspace is vendored inside the snapd snap

AFAIU the userspace part was missing, so with that included only the kernel needs to support it

bookworm and sid (the ā€œunstableā€ development version) only provide 2.57.6-1 Buuut on debian snapd is able to bootstrap itself/use newer snapd installed via snap (ā€˜re-execā€™ support in snapd), so in principle it could also work on older debians.

Not a solution for #fedora though, will have to ask for a newer snapd build.

As far as i get it the missing upstream kernel feature is connected to LSM stapling. Current work for LSM stapling happens in https://github.com/cschaufler/lsm-stacking/branches/active ; current branch is https://github.com/cschaufler/lsm-stacking/tree/syscalls-6.3-rc7-v10-e ). Some more detail: the missing feature is network mediation support for local/AF_UNIX sockets (which very much sounds like my original issue). I could not find where that work/progress gets tracked besides the patch sets of e.g. ubuntu kernels or the kernel maillinglist.

1 Like
#9

Just an update. Debian bookwarm has apparmor v3 via apt package. So the last missing piece is AF_UNIX socket mediation support in the kernel.

Current work for LSM stapling: https://github.com/cschaufler/lsm-stacking/commits/lsm-syscalls-6.4-v12

2 Likes