Fedora 25 to run Wayland by default

Cheers,
Wol

If your goal is security, you either want something as simple as VNC--passing a gigantic buffer over a simple protocol with simple commands--or you want something like X as it was originally conceived--small, declarative drawing commands. Wayland was designed based on the needs of 1) fast and responsive compositing, and 2) getting a proof-of-implementation up as quickly as possible. The former was based on years of experience and headache, the latter looks almost like an after thought, and arguably a poor reaction to the complexity of the modern X protocol.

Another example is something like a SSH connection with X forwarding.
Someone might have access to the remote side's X socket (e.g. the remote system's priviledged user) but not to your local files.

I've been using untrusted X cookies for "less trusted" [1] applications since the first time I read xauth's man page.
Something like: $ xauth generate :0 . untrusted timeout 500

[0] https://www.x.org/releases/X11R7.6/doc/xextproto/security...
[1] For really untrusted stuff I just use a different machine.

Meanwhile, in the real world, we are seeing end-to-end attacks
on ssh from one VM against another running on the same hardware.
And not because of bugs in the hypervisor.

https://www.usenix.org/system/files/conference/usenixsecu...

The idea that under Wayland you can safely run untrusted code is
wishful thinking.

If an attacker is able to own your environment that bad, it's really game-over, regardless of X or Wayland.

As a potentially affected user, why should I care? I've been owned. Worse yet, I've been owned through a very obscure KWin "feature" of a) supporting loadable plugins and b) giving them carte blanche access to everything. The exact attack scenario doesn't matter though. Critical infrastructure linking against a behemoth like Qt is simply asking for trouble no matter what you do. The attack surface becomes so large that it's next to impossible to guarantee security.

> It's a good example of how X's massive insecurity has led to clients becoming complacent toward
> security themselves. It appears that Wayland is fixing that.

I'm not sure Wayland is helping here. A lot of people appear to assert that Wayland will magically get rid of these attack vectors. Martin's approach was different. He took a step back and asked the right question: "Wayland promises protection against key loggers. Does it deliver?" Not everyone would have done that, much less made an attack vector in their own code public.

Perhaps surprisingly, it turns out that at the end of the day Wayland doesn't actually deliver. The attack vector now simply lies elsewhere. As Martin points out, you need to have some of the functionality somewhere to give users the interface they expect. Wayland doesn't provide any facilities to handle global keyboard shortcuts or screen scraping (for legitimate screenshots/screencast). Thus, presently, the complexity is moving where you don't want it: in desktop environment-specific components.

Your response to my comment highlights the bigger issue - a pure "not my fault/problem" mentality isn't going to solve this. As a consequence of Martin's findings our resolution shouldn't be "This isn't Wayland's fault. We just need to harden KWin to mitigate this type of attack.". We should ask the question "How do we fix Wayland (the architecture, not the protocol) to make it impossible in the first place and irrespective of which desktop environment is in use?"

If you're only copying from Linux console to Linux console the Wayland behaviour won't affect you.

FWIW I use gnome-terminal (but I'm guessing that anything that is backed by libvte will behave the same way).