People should avoid Wayland environments which use wlroots as the compositor

Site Development
1

People should avoid Wayland environments which use wlroots as the compositor such as Sway, since wlroots adds many of X11 weaknesses back including the ability for apps to record each other without prompting for permission.

2

I was hoping to actually research this or come across someone else who has. Unfortunately nobody has really shown any examples of it, a blog article or anything really concrete examining how it compares to say GNOME or KDE.

Which of course something I’d love to read.

3 Likes
3

if I understand correctly, here’s Sway’s permission model. It relies on a Wayland protocol that lets sandboxing tools like flatpak identify their apps. Sway only gates the screen recording and keyboard input APIs from those processes.

1 Like
4

Do you have a source for this? I’d like to read up on it.

1 Like
5

I remembered first seeing this claim on PrivSec.dev and went to check out their Linux articles but couldn’t seem to find it. I was curious so I took a look at the archives and it turns out Tommy Tran had this claim included in their “Choosing Your Desktop Linux Distribution” article for about 6-7 months from January 28 to at least June 26 (though probably till the end of July), only to finally remove it recently on July 31st. I don’t have the time to check for myself, but maybe they discussed why they made this claim (and later removed it) on their GitHub?

1 Like
6

Thanks so much for the links (and for digging into the details),

edit: this is the commit where it was removed, no mention of why, The only note was “Remove KDE mentions & Reorganize images”

1 Like
7

It is discussed here Remove KDE mentions & Reorganize images in the "Choosing your distro" post by TommyTran732 ¡ Pull Request #267 ¡ PrivSec-dev/privsec.dev ¡ GitHub

@xe3

1 Like
8

2 posts were split to a new topic: Linux desktop environment security wrt screenshot privileges

9

PrivSec has an unfortunate habit of presenting their criticisms as factual instead of a matter of opinion.

I’m happy with the improvements made in Linux desktop environment security wrt screenshot privileges - #3 by redoomed1 which cover GNOME’s design without discouraging the use of sway or others.

The reality is that the way this is currently handled in most DEs is no different than how it’s handled in mainstream operating systems like Windows, nor how it’s always been handled in Linux, where I have not heard of any real-world attacks where this has been exploited. Thus I see no reason to essentially start fearmongering about wlroots/sway/kde.

I’m okay to mark this proposal as rejected unless anyone has something else to add @team

4 Likes
10

I’m also okay with this, considering that I have not come across…

which I find to be a hard requirement to make bold claims like the one in the title of this thread.

2 Likes
11

Couldn’t resist chiming in here. Being interested in rust version of wayland compositors, I actually have investigated wlroots a bit, and pieces of it are problematic. So there are 3 pieces to the puzzle here:

  1. wlroots currently does not have (and has emphasized they are not focusing on) a security policy (source). This is a bit wild as currently no one has a way to actually point out vulnerabilities in a responsible manner. So its hard to actually find any investigation of its problems.
  2. The devs seems to not consider that memory corruption attacks and bugs are a huge attack surface (part of the reason why hardened_malloc by Graphene OS is such a good attack surface reduction tool). But wlroots is actually quite known for experiencing these memory corruption problems. The lack of proper documentation and security policy also means developers are not given enough guidance to implement wlroots well. (source, although take it with a grain of salt. Since the dev quoted has a history with freedesktop, although he is a very gifted dev). Pay special attention to the “why” portion.
  3. Now since the compositor is a critical piece of software (source :laughing: ), it should ideally not be undocumented, developer-unfriendly, or ignored in terms of security testing and reporting.

So, I still think this warrants a discussion and not a dismissal. Although to be fair, I actually am not aware if these problems persist outside of compositors using wlroots too. Would be happy if someone else can chime in.

4 Likes
12

Thanks for adding this here! My knowledge of this isn’t up to speed to argue well enough about this but i did hear parts of what you wrote here.

We definitely need more input on this.

13

Realistically what are the alternative compositors people can choose from? They are all written in memory unsafe languages.

  • Mutter (GNOME): C
  • KWin (KDE): C++
  • Hyprland: C++, also based on wlroots anyways
  • ?

There’s a handful of compositors like Niri written in Rust that use Smithay instead of wlroots, but it seems silly to tell people that’s the only environment they should use.

Interestingly, System76’s COSMIC DE looks very promising, but it is still not even considered Alpha I don’t believe.

14

Very excited for COSMIC here :slight_smile:

I think we can go by process of elimination:

  1. C++ has way more footguns for developers compared to C (example), especially for projects that lack proper documentation.
  2. Mutter is definitely actively working on security (example), and has clear documentations and guidance for developers (mutter docs vs wlroot docs).
  3. Finally, because of RHEL, Mutter also gets more eyes on it usually, leading to quick detections and fixes (example)

Do I think this means we should recommend non-wlroot wayland compositors only? I am not sure. But if we go by the idea of leading users away from potential footguns rather than the idea of only informing them of clear-cut, well-defined footguns (sounds funny :joy:), I think its fine to recommend non-wlroots compositors (mostly Gnome honestly).

Its also tied in my mind to the idea of how PG does not recommend 1500 distros of linux, and instead only recommends a few. Similarly, we should just recommend one (preferably Gnome) and not try to cover all compositors/DEs/whatever else.

1 Like
15

Well that is different than what the OP is asking for. I’m not really sure what you’re suggesting we actually change on the website?

We don’t have a page recommending DEs at all, because most people just stick with what comes preinstalled with their distro. Do you think we should add one?

16

My bad, I am not that great at these explanations. Let me rephrase the two different things I am talking about:

  1. The request to avoid Wayland environments which use wlroot as compositor is slightly reasonable in my opinion. All the above examples were given to support this hypothesis.
  2. The final paragraph is me wondering about what you just said: Instead of making it complex for the end-users by adding stuff about “avoiding wayland environments which use wlroots as compositor”, we should just directly recommend a DE or two which we feel is better for security by default. (Also, apparantly secureblue also recommends Gnome for the same reasons? (link))

These are the two different points I was trying to make. Please let me know if this is still not clear :cry:

17

Hi, I wasn’t even on this forum but joined to comment on this topic. I have recently returned to Linux for my workstation OS and have been researching WMs / DEs. I don’t have specific expertise in Wayland / X11 beyond an overview and historical understanding. However, I do have expertise in C/C++ including low-level software and bitmap/DirectX.

I notice that this post refers to wlroots as a compositor. Sway and Labwc are compositors, wlroots is an API. Like any API, it may have abilities that can be misused, which should be minimized, but the compositors themselves can wrap/use the API in a secure manner. It’s the compositors’ responsibility at runtime to ask permission for, or provide settings for, specific user activity, not an API! An API may provide hooks to manage/monitor user activity, but it’s the runtime, window manager in this case, that handles these issues. That’s why it’s called a window “Manager”!

So, at the outset, this topic author doesn’t distinguish between the API and window manager.

Secondly, the post refers to weaknesses of X11. Well, X11 has been in use for decades - has anyone been raising this issue?

Thirdly, the idea is to be helpful. If someone sees improvements that an API could benefit from, or is aware of an issue, suggest an improvement to the API. wlroots is open source and, as mentioned, window managers that use it can either use it securely or add their APIs, layered above or alongside of, wlroots to address security issues.

Fourthly, I smell FUD here. Of course security is important, but any hoax can prey on security concerns. Because of the prevalence of hoaxes today, one must be equally careful to not fall prey to hoaxes as well as to address real security concerns.

So,

A blanket statement that anything that uses a particular API is necessarily insecure, is unreasonable, because the runtime that uses the API can address any deficiencies and/or bypass any parts of the API that have weaknesses (as clearly described above).

So, this is not a reason to avoid Sway or Labwc, because as window managers they can control permission requests for screen recording.

In fact, I think I will post the issue raised by the OP here to the Sway and Labwc repos/forums and let’s get to the bottom of this right of away. And the fact that the OP brought this issue to this forum instead of the Sway and Labwc teams, is more evidence that this is FUD.

Didn’t Steve Ballmer say that Linux used their IP? Didn’t Mr. Torvalds respond that it was nonsense and if you believe we have any of your IP, show us and we’ll correct it? That’s the difference between FUD and solving issues - FUD makes general claims - solving security issues involves offering details that can be addressed by the developers.

So, should people avoid Labwc and Sway? Of course not! Many issues in Labwc, Sway, Mutter, KWin, … are fixed/enhanced with each release, and this issue (which we don’t even know is an issue) would be no different!

Were people avoiding Windows when it became inundated with viruses? No. Why not? Because better alternatives were not well established/marketed. Now, we have an alternative, and whatever this recording permission issue is, at least the OS that it runs on (Linux) has historically been much less susceptible to viruses than other virus-inundated OS that people kept using regardless. How well would a statement like “avoid Windows” have been received in the late 1990s and early 2000s when your desktop was basically unusable because of virus popups?

3 Likes
18

This is probably why we’ve made no changes to the website regarding wlroots. I have similar thoughts about Privacy Guides should recommend against using Electron-based desktop apps - #42 by jonah

1 Like
19

OK, so I asked the sway, labwc, and wlroots experts on IRC chat including a sway developer and key labwc developer:

The issue has nothing to do with wlroots. A compositor chooses what abilities to expose to applications. The security/privacy domain in play here applies to malicious applications in general, and has nothing to do with screen recording in particular. For example, on most OSes in general, a malicious application could delete your files.

So, in terms of priority, this is basically a yawn issue. Friends, if you’re installing malicious applications, your concerns go far beyond screen capture! In that light, this issue is unreasonably narrow/selective to window operations. Also, the general claim that compositors that use wlroots are a problem is proven false.

Even still, the swaywm and labwc teams are aware of this. I even added issue on labwc and note on a related swaywm issue.

And as I surmised, any window compositor that uses wlroots can add protections against screen recording and access to other wayland capabilites if needed. Swaywm already doesn’t allow sandboxed (e.g. flatpak) apps to screen record . Third-parties can even use protocol proxies if this is a concern.

But again, I repeat, that to point to wlroots or one specific issue among many that things that an untrusted application could do, whether to files, devices, or windows, etc. is unfair, inappropriate, and misleading. This whole question unfairly puts labwc and swaywm on the defensive. The entire Linux ecosystem can work on fine-grained application trust, not merely window managers. All systems will grow in this area as Linux becomes more prevalent on the desktop and window managers will be no different. In the meantime, if you don’t trust an application, don’t install it (or consider sandbox [flatpak]), but don’t blame your window manager. :slight_smile:

2 Likes