Live data from Hacker News

Wayland Keylogger

github.com

101–110 of 121 posts

Re: Wayland Keylogger

#101
post #96

Earlier quoted context omitted.

The X11 protocol doesn't enable this, even if the most widely used X11 implementation does. An implementation could isolate clients by dropping events and returning blank rectangles for GetImage calls.

IMO the main problem there is that the UX around dropping events and returning blank rectangles is bad. We have the tools to design other protocols centered around a real security architecture that can communicate intent properly and doesn't need to return fake data.

It's probably a better idea to throw BadWindow or BadDrawable when an untrusted client queries about windows or pixmaps it doesn't own.

As for dropping events... the idea is to isolate clients, such that it's as if X resources not owned by the client do not exist to the client. If the UX of the client depends on violations of that rule, then it's either a program like a window manager that should go on a trusted whitelist, or it's up to something nasty.

Note that Firejail does this by using Xpra as a proxy to the real X server.

Re: Wayland Keylogger

#102
post #50

Earlier quoted context omitted.

> 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…

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 d…

Firejail uses Xpra as a sandboxing X proxy to the real server.

It can also be configured to use Xephyr.

Re: Wayland Keylogger

#103
post #64

The position of the Wayland project is that security isolation requires sandboxing. Otherwise, applications can do whatever you can do, including changing all your personal config files and scripts. The security considerations in Wayland are primarily aimed at not being a weak link undermining sandboxing efforts, which is the case with X11. Without sandboxing, writing to e.g. ~/.profile would in most cases be enough…

> The position of the Wayland project is that security isolation requires sandboxing. which is not really a step forward since now I have do go and sandbox every app.

No.

It's a step forward because you can, but it's ultimately up to you. You're still better off with Wayland, but no matter what you use, there's a huge glaring security hole if things are not sandboxed.

Re: Wayland Keylogger

#104

Earlier quoted context omitted.

IMO the main problem there is that the UX around dropping events and returning blank rectangles is bad. We have the tools to design other protocols centered around a real security architecture that can communicate intent properly and doesn't need to return fake data.

It's probably a better idea to throw BadWindow or BadDrawable when an untrusted client queries about windows or pixmaps it doesn't own. As for dropping events... the idea is to isolate clients, such that it's as if X resources not owned by the client do not exist to the client. If the UX of the client depends on violations of that rule, then it's either a program like a window manager that should go on a trusted whit…

IMO, X11 is practically unusable without NX/Xpra, but it has other UX issues and it still doesn't do exactly what you'd want. Throwing a protocol error is also bad UX. There's no way to present that to the user other than saying "hey this didn't work, go fix it in some other system-dependent place that I may or may not know about."

Re: Wayland Keylogger

#105
post #6

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 a…

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?

Re: Wayland Keylogger

#106
post #18
post #5

I do use Linux (almost) exclusively, but I'm well aware of the security limitations. Forget this keylogger. All you need is to somehow write a single line into .profile or .bashrc, which basically every executed program can do, and you own the user account. You can intercept every program with wrappers by changing PATH or adding desktop entries in .local/share/applications, extract all data from applications, use LD_…

I would love to see a real permission system on Linux, where applications have to explicitly ask me before accessing things deemed important. It's never been a problem for me, but it would give me some comfort.

It's interesting to see how the "we must protect users from each other on a multi-user system using permissions" need has shifted to "we must protect the often single user from multiple potentially evil applications using permissions".

Re: Wayland Keylogger

#107
It's just anoter LD_PRELOAD key logger not really a wayland keylogger.

Let's be honest with LD_PRELOAD you can currently get pretty much anything.

Through you can setup SeLinux to make such attacks impossible or at least much harder needing other vulnerabilities/insecure design to succeed.

But some programs abuse LD_PRELOAD for various reasons.

Also there are so many other ways to undermine security that once you locked everything down Linux became supper hard to use.

The funny think is, non of this attack vectors are a major problem for server/embedded or similar non-desktop Linux use cases. As in them you can normally run a hardened Linux, where such attacks simple are not possible.

It hints to how Linux is not really designed as a desktop system. And IMHO is fundamentally unsuited to become a modern desktop (or handy) OS without changing it so much, that's not really Linux anymore. This is also why I never had much hope for the libre phone.

Re: Wayland Keylogger

#108
post #65

Earlier quoted context omitted.

yes but you're getting downvoted because HN doesn't like people actually realizing stuff.

No one who understands wayland was under the delusion that wayland would protect against an application which has full access to your user directory. Wayland becomes secure when combined with an application sandbox using SELinux/flatpak. Previously you could sandbox the app and X would provide an escape.

Yes, I am aware about this.

Yet the most common way to denigrate Xorg is to assert that Xorg is basically a keylogger. Which might be true, but as this post shows just switching to Wayland doesn't offer any additional protection under the key-logging point of view.

You might combine a sandboxing technique with Xorg too, by the way.

Re: Wayland Keylogger

#109

If we’re being honest, this keylogger is not exploiting a weakness in wayland. So it’s a bit clickbait to call it a “wayland keylogger”

It doesn't exploit a Wayland weakness but it's written specifically for Wayland. Maybe "Wayland keylogging patch" will have been better.

Re: Wayland Keylogger

#110
post #2

Windows is arguably more secure because it has the secure desktop that isn’t controlled by user applications. Unfortunately it doesn’t help with all kinds of password entry.

So does Android , but the same security is what creates a “walled garden”. To limit what malicious software that runs as one's user can do, one must limit what the user can do, and that's exactly what they attempt to do. I personally præfer that the user be trusted to be wise enough to run software that he does not trust in a contained environment, and he be given the freedom to control his own environment as he plea…

That’s not what the secure desktop is.

Windows has the normal desktop that shows your programs and separate desktops for special purposes. There is a desktop where your screensaver runs. So if your screensaver crashes it is not possible for your screen to show up.

Another desktop is where the login screen is on. Normal programs can’t connect to that desktop so they can’t capture your keystrokes as you type your password.

This isn’t about ‘walled gardens’.

Post reply on HN