GNOME Shell & Mutter Complete Their Migration Away From GTK3

[reza]

Why I originally brought this up is because GNOME offers this integrated search for packages that could be installed. I meant that storing this cache on disk makes sense, even if you don't have a fast NVMe disk.

Makes sense.

I know it's off-topic: Any insights on Windows 10/11 side of things as opposed to Windows 7 and older versions?

[Artim]

Makes sense.

I know it's off-topic: Any insights on Windows 10/11 side of things as opposed to Windows 7 and older versions?

Depends on what your question is about.

If you mean if Windows search shows you apps that aren't installed but available in the Store? I don't think so. The Windows search simply sucks, the only difference with 10 and 11 is that you have to disable Web Search if you don't want half the world to know what you are searching for. Also, Microsoft does it's best that those web search results will always open in Edge and it will always use Bing, no matter what you do.

And of course the search index is stored in your drive, as it had been for many generations of Windows now. But searching the content of files too is still quite bad. Only usable thing to do that with I've seen yet is ripgrep-all.

[reza]

Depends on what your question is about.

Thanks for the reply. So my first post in this thread was about why Windows 10/11 is so slow on HDD as compared to older Windows 7/XP? I hypothesize it's not about RAM, but rather assuming that underlying storage is fast (SSD/NVMe)?

[Artim]

Thanks for the reply. So my first post in this thread was about why Windows 10/11 is so slow on HDD as compared to older Windows 7/XP? I hypothesize it's not about RAM, but rather assuming that underlying storage is fast (SSD/NVMe)?

Most likely. It has been many years since I've run Windows 10 on a HDD, and I've never made the direct comparison between 10, 7 and XP. But Windows definitely has gained a lot of weight over the years. It takes up much more RAM with stuff the user typically doesn't really want or even need. Also, since so much more stuff is running in the background, including an anti virus programm that you hardly can control, of course it's constantly stepping on its own toes. So a big part of the reasons definitely is that 10/11 are much more taxing on CPU and RAM. And having it on a HDD rather than a SSD makes it already slower because of that. More useless stuff wasting RAM in the background means that you have to either compress some of it to make space for the programs users use or swap it to the drive - most likely both. And if you have to swap a lot to a HDD, of course that will be slower. But I don't know how much Windows is generally writing to storage accept for swapping and updates, that could slow it down in comparison to XP/7.

[gotar]

libwsm has nothing to do with what I'm talking about lol Why would I be referring to something that's not part of the Wayland protocol when describing the Wayland protocol?

You were describing alleged Wayland security. If you were are not referring to any security at all, then maybe you simply shoud refrain from taking about things you're not familiar with? Like the Linux desktop inheritent insecurity.

[gotar]

Not quite true. Wayland protocol has refused to implement quite lot features and those features have been pushed out to places like xdg-desktop-portals behind dbus security.

https://subscription.packtpub.com/book/networking-and-servers/9781783989669/10/ch10lvl1sec88/controlling-d-bus-message-flows

Yes dbus you have selinux, apparmor and other linux security module integration.

Via dbus you cannot reliably get user capabilities (it's racy to seek for the data). Something like SCM_CAPABILITIES could have been provided by kdbus, but as this effort has been shattered, there's currently no (fully featured) security-oriented bus communication for Linux.

Wayland protocol has done a reduced attack surface compared to X11. So not quite the same as please don't do bad things.

The surface was reduced in two ways:
1. missing features (screenshots, virtual inputs) that eventually need to be implemented somehow in a secure manner,
2. stripping network transparency.

The first is obviously not a ready solution for a desktop, the second was easily obtainable (or even default -nolisten) in X.

What is usually talked about X11 insecurity is breaching application separation in two cases:
1. intermixing X clients input/output on the host (considering app running with elevated privileges that can be controlled by any other client on the same X server),
2. intermixing X clients input/output between the host and remote X clients (networked apps and local ones are free to interact with each other).

The second case is closed when X networking is disabled (obviously).

The first one however ...is not resolved by Wayland at all. The owner of display server/compositor can easily intercept all the communication to and from every app using it, despite the origin DAC, no meaningful difference to X11. This is simply a different path - rather than using X protocol directly, attacker can target the Wayland and there are no countermeasures. Wayland doesn't provide any app separation, it only doesn't provide app interaction. This is of course a step in the right direction, but way too less for 2013 (Snowden), and we have 2023 now.
To be more precise - the kind of sandboxing I'm taking about would be the job for display server. But as we need to assume - users code can't be trusted (meaning: no user should trust the code he starts), we must conclude that display server must be run from user-inaccessible realm (remember this?).

In a funny way, for such attack vector, one could say that root-ful Xserver with X-SECURITY would be more secure than Wayland...

[Myownfriend]

You were describing alleged Wayland security. If you were are not referring to any security at all, then maybe you simply shoud refrain from taking about things you're not familiar with? Like the Linux desktop inheritent insecurity.

Maybe listen to your own advice, champ. That post sucks. Your last sentence reads like a Gene Shalit joke but there's no joke lol

When people are talking about Wayland's security they're referring to the fact that applications can't listen in on any and all input and they can't see and control other application's windows. These things aren't crazy levels of security (though many have said that) but it does make them more secure than X11.

[Myownfriend]

The owner of display server/compositor can easily intercept all the communication to and from every app using it, despite the origin DAC, no meaningful difference to X11. This is simply a different path - rather than using X protocol directly, attacker can target the Wayland and there are no countermeasures. Wayland doesn't provide any app separation, it only doesn't provide app interaction. This is of course a step in the right direction, but way too less for 2013 (Snowden), and we have 2023 now.

This is all anybody is saying but the "boycott Wayland" herbs keep on thinking we're saying that Wayland is the be-all and end-all of security on Linux but nobody is actually saying that. We're just comparing it to X11 and that's it.

[oiaohm]

Via dbus you cannot reliably get user capabilities (it's racy to seek for the data). Something like SCM_CAPABILITIES could have been provided by kdbus, but as this effort has been shattered, there's currently no (fully featured) security-oriented bus communication for Linux.

dbus-broker does not have the racy problem of dbus-deamon. kdbus developers moved over to dbus-broker once they were talking to the Linux kernel core developers and they were told by the kernel developers how to do all those operations in a non racy way using existing kernel functionality.

The first one however ...is not resolved by Wayland at all. The owner of display server/compositor can easily intercept all the communication to and from every app using it, despite the origin DAC, no meaningful difference to X11. This is simply a different path - rather than using X protocol directly, attacker can target the Wayland and there are no countermeasures. Wayland doesn't provide any app separation, it only doesn't provide app interaction. This is of course a step in the right direction, but way too less for 2013 (Snowden), and we have 2023 now.
To be more precise - the kind of sandboxing I'm taking about would be the job for display server. But as we need to assume - users code can't be trusted (meaning: no user should trust the code he starts), we must conclude that display server must be run from user-inaccessible realm [/URL]).

Notice you only looked at DAC. You have completely forgot MAC.

https://bugzilla.redhat.com/show_bug.cgi?id=1571328

The claim of no counter measure is not true. Correct selinux policy or other equal Linux LSM Mac policy and the attacks against Wayland compositors are dead in the water. Yes you can prevent a user from debugging or preloading into an application running as their own user by Linux MAC policies. Fun right that a MAC policy can say unless application was started and run exactly this right way it cannot connect open this socket.

Also https://bugs.freedesktop.org/show_bug.cgi?id=84817 Wayland protocol design does not forbid Wayland compositor running as a different user to the applications. Just DAC on the Wayland socket has to be setup to allow it.

KDE is moving in the direction of cgroup/namespace sandboxing. Lets take all those so called Wayland attack plans. Lets say attacker got into firefox running in flatpak from there can the attacker restart the Wayland compositor to use preload or debug the wayland compositor no they cannot they have to find another exploit. Yet flatpak firefox and wayland compositor is running as the same user..

In a funny way, for such attack vector, one could say that root-ful Xserver with X-SECURITY would be more secure than Wayland...

This is not true. This is comparing Xserver with security turned on against Wayland without security turned on. Wayland selinux profiles by redhat preload attack and debugging attacks are normal users don't work. Root-ful Xserver is always more insecure because any flaw in Xserver that allows code to turn allows root privillage operations.

gotar something to remember selinux and other solutions mac policies can apply rules that even run as root you cannot override.

Discretionary access control (DAC) is weaker by massive amount than Mandatory Access Control and Cgroups/namespaces. The idea of security by run as a different user is from a time when systems only had DAC when MAC and Cgroups/namespaces did not exist.

Sandboxing is not the job of the display server. Sandboxing is the job of the MAC or whatever running applications. MAC at kernel level already provide the tools not to trust any application user starts.

Yes lots of people fail to notice that a Linux kernel MAC can block LD_PRELOAD or running ld.so/ld-linux.so with different options to alter application behavior. Yes LSM MAC item can tell the difference between the Linux kernel calling ld-linux.so when starting a dynamic application and a user doing ld-linux.so application so allowing the first one work and the second one fail.

By the way any time glibc preloader sees AT_SECURE set LD_PRELOAD does not work along with many other override options. Default when you apply MAC policy to application with selinux AT_SECURE gets turned on you have to put noatsecure in policies with selinux so this does not happen. Yes SUID GUID bit and capabilities on applications also turn on AT_SECURE. To stop LD_PRELOAD you don't need to run as a different user you just need to get AT_SECURE turned on and there is more than 1 way todo that. Stopping elf loader replacement that option with MAC as well. Stopping debugging MAC has that option as well.

[gotar]

When people are talking about Wayland's security they're referring to the fact that applications can't listen in on any and all input and they can't see and control other application's windows.

Of course they can. Just "beyond the scope of Wayland" protocol (like any of the missing features).

These things aren't crazy levels of security (though many have said that) but it does make them more secure than X11.

X11 has backdoors built in. Wayland does not, but doesn't define any security model to circumvent enabling custom one.

You call it "more secure". I disagee - it's only "less insecure". But still insecure.

We're just comparing it to X11 and that's it.

I'm not trying to compare to X11 usually. Noone sane thinks X11 model can be kept. I'm waiting for replacement ...since 25 years actually, there were always tons of awful issues among the few nice features. 10 years ago I hoped for Wayland to quickly grow into modern replacement. Wayland guys did great job doing graphic stack. Only.
Unfortunately they forgot about overall desktop UX and security. After all, this is post-Snowden (2013) era, and Wayland is already obsoleted.

Maybe it is possible to build sandboxes around Wayland display servers, but I can't even find any research on the subject. I'm worried about their DMA-BUFs (Wayland) and libinput (remember the good old Xkb?) - ...exactly the same threat as in X11 (X11 + XInput).

The status quo is, Wayland doesn't help running untrusted applications.


I got this proof of concept scenario for X11:
- start X11 server on workstation (the machine that should be secured against malicious code),
- set up dumpster machine for untrusted app (the best as separated bare metal, but the experiment can go with VM or even some container),
- run untrusted@dumpster with remote (network transparency) DISPLAY=@workstation.

In this case the untrusted cannot interfere directly (system level, IPC etc.) with my apps@workstation (which is good), but X11 breaks all the fences (which is the deal breaker).

How does Wayland help? It doesn't - the protocol doesn't expose my apps to untrusted one, but I can't run the untrusted code remotely (entirely external system, xauth, X11 forwarding, different user etc.) with system-level separation.