In plasma wayland session Xwayland is started with default settings which means it listens on tcp/tcp6 on all network interfaces on port 6000+n (n=display number). Listening on network without user consent is harmful for security. Especially as it's not possible to disable this in config. In X11 session all display managers start xserver with '-nolisten tcp' option which disables above behavior. Considering above I think current Xwayland config is decreasing security in comparison to standalone X11 session and should be adjusted. BTW: This behavior can create specific issues for some users: https://bugs.kde.org/show_bug.cgi?id=394431 Steps to reproduce: 1. Login to plasma-wayland session 2. sudo ss -tunwrap | column -t
Please report to X developers. They should use sane and secure defaults.
FWIW, it's not universal. I've not changed anything and don't have anything listening
@David Edmundson what's is your setup? Mine: Archlinux; Plasma 5.13; sddm
I can reproduce it always with: Starting: 1. kwin_wayland --xwayland 2. sudo ss -tunwrap | column -t |grep -i xwayland System: Distro: Archlinux Linux: 4.17.1 Plasma: 5.13 Frameworks: 5.47 QT: 5.11
(In reply to Martin Flöser from comment #1) > Please report to X developers. They should use sane and secure defaults. This is the upstream answer in related case[1]: "However, if the Wayland compositor enables IP, and you think that is a mistake, then you should report that to the Wayland compositor project in question." Moreover I'm able to override standalone xserver/xwayland defaults but I'm not able to override kwin/xwayland defaults. That's why I think this issue belongs to kde devs. At least if they care about security. Currently kwin starts xwayland as: /usr/bin/Xwayland -displayfd xx --rootless --wm xx To fix this issue it should start it as: /usr/bin/Xwayland -nolisten tcp -displayfd xx --rootless --wm xx [1] https://bugs.freedesktop.org/show_bug.cgi?id=106573#c2 BTW: I have reports from people who can reproduce this.
>It's worth noting that adding -nolisten options from the compositor doesn't work, because if that option isn't available (e.g. '-nolisten tcp6' when you've built without IPv6 support), failure to not listen will be a hard error. From Daniel Stone. So we're definitely not doing that. I will monitor that upstream thread. Please do not reopen it here.
(In reply to David Edmundson from comment #6) > >It's worth noting that adding -nolisten options from the compositor doesn't work, because if that option isn't available (e.g. '-nolisten tcp6' when you've built without IPv6 support), failure to not listen will be a hard error. > > From Daniel Stone. > > So we're definitely not doing that. > > I will monitor that upstream thread. Please do not reopen it here. Option '-nolisten tcp6' doesn't even exist, it should be '-nolisten inet6' but I'm not advising to use it. Option '-nolisten tcp' will work always - it disables both ipv4/ipv6 and doesn't fail hard when ipv6 isn't available (see 'man xserver' for valid options). Actually kwin_wayland hard fails currently when ipv6 isn't available (just boot with 'ipv6.disable=1' kernel arg to test) so we have exactly opposite situation of what you quoted[1]. To conclude we have both: potential security issue and crash and you closing them both and pointing to upstream while upstream points to you while there is no sign they will address it in any way. [1] https://bugs.kde.org/show_bug.cgi?id=394431
I do not get the impression upstream points to us after Olivier analyses what's happening. It's a weird quirk of them putting -listen with the wayland socket which implicitly disables default listeners that you've apparently added when compiling your X. Interestingly I do put -nolisten tcp in SDDM, so I'm more obliged to add it here.
(In reply to David Edmundson from comment #8) > I do not get the impression upstream points to us after Olivier analyses > what's happening. > > It's a weird quirk of them putting -listen with the wayland socket which > implicitly disables default listeners that you've apparently added when > compiling your X. I didn't compile my X. I use official Archlinux package. There isn't any listening option enabled during compilation[1]. The fact is when I start Xserver without '-nolisten tcp' it's listening on network sockets so it's the default behavior. I test this with with xorg 1.20 (the build details are in linked Archlinux site). This may be related to using new meson build system which doesn't even have 'listen' option[2]. > > Interestingly I do put -nolisten tcp in SDDM, so I'm more obliged to add it > here. You didn't put it there. It's in default SDDM configuration[3]. It's in default GDM configuration[4]. It's in default lightdm configuration[5]. Regardless of what the default xorg behavior is, virtually everyone is explicitly disabling listening on tcp sockets just to be on the safe side. The point of this issue is that kwin_xwayland should follow the common practices. [1]https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/xorg-server#n80 [2] https://cgit.freedesktop.org/xorg/xserver/tree/meson_options.txt [3] https://github.com/sddm/sddm/blob/815ee034303d51ce3850a533c2023eaf5eb09cae/data/man/sddm.conf.rst.in#L103 [4] https://github.com/GNOME/gdm/blob/f7bda8dac60eb556709fba085248df5395d09a56/data/gdm.schemas.in.in#L73 [5] https://github.com/CanonicalLtd/lightdm/blob/fe28fb17147611a99c03bf593f10f1fb73d80c59/data/lightdm.conf#L99
This issue was caused by new meson build system with xorg. It's fixed by https://lists.x.org/archives/xorg-devel/2018-June/057142.html . You can still consider if kwin should pass '-nolisten tcp' argument as a precaution, similar to what display managers do.