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:
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 -
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?).
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ā¦
there are multiple issues here. the context for following all about the thunderbird snap in a wayland desktop session
the snap does not create a link/access to the wayland socket. It does this neither on debian nor ubuntu
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
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)
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)
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.
