this seems completely miss the point of wayland security.
Of course if you run the programs under same account you can keylog them. You can also connect to Chrome and steal the cookies directly, wrap terminal to install pty loggers, backdoor ssh and so on.
The real point of wayland security is you can safely run multiple user accounts on the same desktop. And the LD_PRELOAD tricks (or PATH tricks etc..) do not work across accounts, unless you are doing something stupid.
I wish people would stop saying silly things like "But for any possible way to break it, I could add countermeasures as well. Applications could use 'getenv' ....". That's not how you break keyloggers! You break them with privilege separation. The least-code version would be:
1. Create a separate user for web browsing, with its homedir and all
2. Create "/etc/sudoers.d" entry to launch browser which does not require password, but also does not allow any arguments, enforces HOME and only passes through a small subset of env vars
3. Launch your browser with "sudo -H -u browser-user firefox". Make it a desktop shortcut or something so you are not tempted to enter your password if someone messes with the shortcut.
that's it -- this will stop this attack, and many others, cold. And will not require any SELinux.
Hi I am currently using this method in X11, but would like to switch to Wayland eventually. But I can't seem to figure out how I would then give the browser-user access to the wayland socket.
In X11 I can just make use of 'xhost si:localuser:browser-user'. But it seems that I would need to give full access to my main user's XDG_RUNTIME_DIR (/run/user/1000/), so that it can access the 'wayland-1' socket from the browser user. Is there a better way to do this?
> this seems completely miss the point of wayland security.
The point is that Wayland security is useless because the security boundary on Unix is fundamentally the user account:
> Of course if you run the programs under same account you can keylog them. You can also connect to Chrome and steal the cookies directly, wrap terminal to install pty loggers, backdoor ssh and so on.
> The real point of wayland security is you can safely run multiple user accounts on the same desktop. And the LD_PRELOAD tricks (or PATH tricks etc..) do not work across accounts, unless you are doing something stupid.
If this indeed be the point, then I ask you to come with a single official Wayland reference that promotes it as such and phrases it as such, as that is not the point the advocates make at all, and they phrase it simply as “One can no longer be keylogged by malware.”, which is a very dubious claim.
Once malicious software has been executed as one's user, that is the end of it, and one's entire account can now be treated as forfeit, and Wayland does nothing, and cannot do anything due to the fundamental designs of Unix to stop that.
Furthermore, there are already quite a few mechanisms on X11 to achieve what you illustrated. — that does not mean that Wayland is useless, it simply means that it does not provide a solution to any existing problem in this specific field that is not provided elsewhere.
There are two common claims that are very frequently made by official sources such as GNOME that are false:
- X11 cannot be sandboxed.
- With Wayland, one cannot be keylogged.
> that's it -- this will stop this attack, and many others, cold. And will not require any SELinux.
Yes, never running malicious code with the privileges of one's user would stop it from gaining access to said user, but the promises of Wayland are protections even if the former have happened. — this is false advertisement.
I think you are mixing "official wayland reference" and some "advocates".
The offical Wayland reference does not talk about malware at all, as this is not not something that windowing protocol can solve. The best they can do is to promise "client isolation" -- which means that one client cannot affect other via wayland protocol
I am sure there are some Wayland advocates somewhere who are making dubious claims. This does not mean the Wayland security is useless -- this just means that specific systems are not secure yet. People on the internet can claim all sorts of crazy things, and you should not hold what random bloggers say against the whole system.
Re X11 sandboxing, from my reading, the general opinion is that X11 is impossible to secure. They did SECURITY extension, but it apparently does not work well, see this wonderful quote from Debian's ssh manpage [0]
> Debian-specific: X11 forwarding is not subjected to X11 SECURITY extension restrictions by default, because too many programs currently crash in this mode.
What other X11 isolation mechanisms are there? Xnest breaks seamless window switching, things like VNC introduce a ton of latency.
So before the Wayland we did not have a desktop with solid client isolation, so not one cared about process isolation either. What's the point of running browser from trusted account if any random desktop app can steal its keystrokes? The best one could do was Quebes OS, and this had plenty of its own overhead.
Now with more people switching to Wayland this should help. It's far past the time that people stop assuming that
"one human user" == "one entry in /etc/passwd" and start separating services by account.
Of course if you run the programs under same account you can keylog them. You can also connect to Chrome and steal the cookies directly, wrap terminal to install pty loggers, backdoor ssh and so on.
The real point of wayland security is you can safely run multiple user accounts on the same desktop. And the LD_PRELOAD tricks (or PATH tricks etc..) do not work across accounts, unless you are doing something stupid.
I wish people would stop saying silly things like "But for any possible way to break it, I could add countermeasures as well. Applications could use 'getenv' ....". That's not how you break keyloggers! You break them with privilege separation. The least-code version would be:
1. Create a separate user for web browsing, with its homedir and all
2. Create "/etc/sudoers.d" entry to launch browser which does not require password, but also does not allow any arguments, enforces HOME and only passes through a small subset of env vars
3. Launch your browser with "sudo -H -u browser-user firefox". Make it a desktop shortcut or something so you are not tempted to enter your password if someone messes with the shortcut.
that's it -- this will stop this attack, and many others, cold. And will not require any SELinux.