Unless you're doing SELinux or using some tool like firejail, absolutely nothing?
The average desktop is completely insecure, regardless of the display protocol. If a program is running as your user it's already game over: it can do whatever it likes. For example, I can simply change your shell profile to add an LD_PRELOAD shim, hook some libc syscall wrapper and run arbitrary code in any user process. There's no need to log key presses.
Keep in mind that X11 is a protocol, so the client might not be running as your user on your local machine, it could be a dedicated machine that's only running the client.
In this case, again it's not important because in our timeline X11 is old, you might proxy the clipboard feature, with a trusted and untrusted connection, the untrusted connection needs to be careful because it's exposed to arbitrary nastiness from potentially hostile untrusted clipboard-using software - the trusted one talks to everybody else. So an example is you might decide to sanitize text, strip out invisible control characters, and exclude "rich" text formats that might conceal attacks. Or you might allow some images but only after previewing them and constraining their properties, no 18GB GIFs please, yes it's technically possible to encode a huge truecolor image as a single GIF no I don't want that in my clipboard.
Is this something we should try to implement? Probably not, but in a world where people try to kite surf across the English channel it's nowhere close to the craziest hobby.
> Keep in mind that X11 is a protocol, so the client might not be running as your user on your local machine, it could be a dedicated machine that's only running the client.
For an X server to be network exposed, you first have to either SSH forward it or remove the nowadays-default "-nolisten TCP", and then either get the xauth secret or have the user do 'xhost +'.
At that point I'm gonna say the attacker earned their keylogger access.
And you or your distro might consider patching out the TCP variant.
Saying 'xhost +menger' and being able to run graphical apps from my university's Sun server -- OPEN LOOK apps at that -- on my local Linux machine was peak 1990s computing.
It is not an attack if there is no privilege boundary in the first place. One could argue that should be, but then X's security would have also worked which is the point of the article. The problem was that Wayland propaganda pretended actual users would benefit from improved security immediately because there was a gaping security hole. The point of the linked repo is that this is nonsense and typical Linux users do not benefit at all.
I really don't know this is the best place to ask, but I don't know anywhere to ask you, so... Is C2Y getting any generic programming features? I'd really love the one with _Type as a new type that stores a type.
I hope so. WG14 seems to like it (but not everybody), but it is not existing practice. So it will mostly depend on me creating a prototype and doing a lot convincing.
you're right, but sec is about threat profiles. there's a point where selinux, firejail, etc. aren't enough either. even a virtual machine may as well be wet rice paper to an alphabet soup agency. you should very much assume that even airgapping isn't enough, unless it's inside of a faraday cage.
xorg security measures are a different matter from stopping any random program from writing to your filesystem. broaden the conversation to be about all security across all attack surfaces under all conditions and nothing is safe. i'm still not gonna run everything as root.
There is no threat profile where the attacker can run an XNextEvent() loop and log your password, but somehow cannot alter the .desktop file for your browser, or your login profile and LD_PRELOAD something.
Edit: other than sandboxing, but I'm targeting this at the Great Wayland Security Theater.
This is why need need app sandboxing as the mobile platforms already do. Snaps and Flatpak both suuport this, but their critics resist without providing an alternative.
X11's SECURITY extension was its long-forgotten stab at sandboxing: flip a bit and every client is either trusted or untrusted. It does kill trivial key-logging, but it also breaks the clipboard, disables GLX and makes various apps fall over, leaving the desktop unusable while Firefox somehow works just fine. A cool reminder that X11 could've had proper sandboxing 25 years ago, but the UX cost sank it and Wayland is the lifeboat now.
It's worth mentioning that the X11Libre fork of X.org has recently added the Xnamespace extension [1], which is inspired by this. Instead of a single bit trusted/untrusted it allows to isolate clients into containers where interactions are restricted to be within the same container only.
Plan 9 had this all sorted out, didn't it? It didn't use X11, it used something called 8½ which became the Plan 9 display server, and used 9p as the communication protocol.
What was clever about it was that each window got its own view of the keyboard and mouse. Literally their own virtual devices in /dev. Each window only saw what went on when that window was in focus, and for the mouse, it only saw what the mouse was doing when the mouse was within the boundaries of the window and that window was directly under the cursor (no windows between the cursor and the window in question.)
9P isn't encrypted, so these remote sessions weren't encrypted, but the Bell Labs folks knew that X11 security wasn't good and seem to have evolved it well. I wonder what things would be like if we didn't latch onto 40 year old operating systems like our lives depended on them.
If we can't get a useful Plan9 going (one that has a web browser and to which applications can easily be ported) maybe we can bring X11 forward a bit with inspiration from Plan 9. Wayland has been "2 years away" for about 15 years, and that shows no signs of changing.
I'm told that the entire source code for Plan 9 can be held in the mind of a single person, and that any skilled C developer can read what's going on with ease. I don't know if that's true, but if such a display server has semi-obvious improvements over X11, maybe we can come up with an X12 which adopts these improvements. We do not need to maintain backwards compatibility, we only need to support X11 and X12 at the same time, I imagine.
Yeah me too, though in college. There was even a program called "xbl" (or "blast" on some platforms) that would turn your mouse pointer into a crosshair and when you clicked somewhere it would make a round hole in the window. Which wouldn't go away until you killed the app. In fact they could even stay after it quit! It was so funny. https://man.freebsd.org/cgi/man.cgi?query=blast&sektion=1&ma...
Also running xfishtank on someone's root window. So many things you could do.
To me it seems the security extension is more useful for protecting elevated prompts (such as running an application as admin) than actually sandboxing between applications.
> It's widely known that X11 has a problem with, for example, keyloggers. The issue is not that keyloggers are possible through security holes -- but keyloggers are trivial on X11, as they are part of normal operation and don't require exploits. It is one of the reasons why people push for Wayland.
Sorry, but did I miss news about a keylogger epidemic? On Linux?
In all seriousness, is this solving an actual problem or an imagined one?
And even assuming a 'Yes': A problem that isn't better solved elsewhere? How did the keylogger get access to the system and its desktop session? What else does it have access to?
Firejail discusses this briefly in their X11 guide:
The sandbox replaces the regular X11 server with Xpra or Xephyr server. This prevents X11 keyboard loggers and screenshot utilities from accessing the main X11 server.
It's not a common issue, but obviously a security concern to make it so easy for keyloggers to record your keypresses or screen. I currently prefer X11 to Wayland, and I'd love if this problem was possible to address without Firejail. I use Firejail for other sandboxing tasks, but sandboxing X11 is too impractical.
That's not an answer. Yes, I can run xev on my machine against my X session and see my keystrokes. It is not obvious that this is a problem. A more plausible angle would be that if an attacker compromises one application - say, a web browser - then they could keylog passwords. Of course, most people don't sandbox their browser so that's the least of their problems if it's compromised (ex. https://access.redhat.com/articles/1563163 let an attacker steal ssh keys).
> It is one of the reasons why people push for Wayland.
Really? You think they'd just push for a _firewall_. Wouldn't that just solve the actual problem? Oh, wait, yea, X11 disabled TCP networking by default more than a decade ago.
> it cannot use the active X11 connection to spy on your keyboard.
You understand what /dev/input/* is, right?
> I understand that this means this blog post lacks substance.
The whole undertaking lacks substance.
Too many projects drank the early 2000s kool-aid and thought they would get a second suck at the salve (a.k.a "start from scratch"). It never worked out and you just fraction an already annoyed userbase into an overtly warring userbase. I can't think of anything more wasteful of talent and energy.
> I personally think attitudes like yours have destroyed this site.
neat. I mean, the site seems fine to me. Seems to be working fine. I got downvoted for my observation but you'll be upvoted for saying I broke something, so maybe it was already broken when you got here.
I think a proxy server might be a better way to handle security, than the way it is done as described in this article. (On a computer, the security will need to consider more than only the X server, but that will be one part of it.)
> What does it protect against?
Unless you're doing SELinux or using some tool like firejail, absolutely nothing?
The average desktop is completely insecure, regardless of the display protocol. If a program is running as your user it's already game over: it can do whatever it likes. For example, I can simply change your shell profile to add an LD_PRELOAD shim, hook some libc syscall wrapper and run arbitrary code in any user process. There's no need to log key presses.
Keep in mind that X11 is a protocol, so the client might not be running as your user on your local machine, it could be a dedicated machine that's only running the client.
In this case, again it's not important because in our timeline X11 is old, you might proxy the clipboard feature, with a trusted and untrusted connection, the untrusted connection needs to be careful because it's exposed to arbitrary nastiness from potentially hostile untrusted clipboard-using software - the trusted one talks to everybody else. So an example is you might decide to sanitize text, strip out invisible control characters, and exclude "rich" text formats that might conceal attacks. Or you might allow some images but only after previewing them and constraining their properties, no 18GB GIFs please, yes it's technically possible to encode a huge truecolor image as a single GIF no I don't want that in my clipboard.
Is this something we should try to implement? Probably not, but in a world where people try to kite surf across the English channel it's nowhere close to the craziest hobby.
> Keep in mind that X11 is a protocol, so the client might not be running as your user on your local machine, it could be a dedicated machine that's only running the client.
For an X server to be network exposed, you first have to either SSH forward it or remove the nowadays-default "-nolisten TCP", and then either get the xauth secret or have the user do 'xhost +'.
At that point I'm gonna say the attacker earned their keylogger access.
And you or your distro might consider patching out the TCP variant.
Saying 'xhost +menger' and being able to run graphical apps from my university's Sun server -- OPEN LOOK apps at that -- on my local Linux machine was peak 1990s computing.
> the client might not be running as your user on your local machine
True, this is probably the only real use case. X11 forwarding in OpenSSH (ssh -X) does in fact use this extension by default.
Indeed https://github.com/Aishou/wayland-keylogger
Wayland's security isolation is a necessary, but not sufficient, measure to prevent this kind of attack.
It is not an attack if there is no privilege boundary in the first place. One could argue that should be, but then X's security would have also worked which is the point of the article. The problem was that Wayland propaganda pretended actual users would benefit from improved security immediately because there was a gaping security hole. The point of the linked repo is that this is nonsense and typical Linux users do not benefit at all.
Hi Uecker!
I really don't know this is the best place to ask, but I don't know anywhere to ask you, so... Is C2Y getting any generic programming features? I'd really love the one with _Type as a new type that stores a type.
I hope so. WG14 seems to like it (but not everybody), but it is not existing practice. So it will mostly depend on me creating a prototype and doing a lot convincing.
you're right, but sec is about threat profiles. there's a point where selinux, firejail, etc. aren't enough either. even a virtual machine may as well be wet rice paper to an alphabet soup agency. you should very much assume that even airgapping isn't enough, unless it's inside of a faraday cage.
xorg security measures are a different matter from stopping any random program from writing to your filesystem. broaden the conversation to be about all security across all attack surfaces under all conditions and nothing is safe. i'm still not gonna run everything as root.
There is no threat profile where the attacker can run an XNextEvent() loop and log your password, but somehow cannot alter the .desktop file for your browser, or your login profile and LD_PRELOAD something.
Edit: other than sandboxing, but I'm targeting this at the Great Wayland Security Theater.
This is why need need app sandboxing as the mobile platforms already do. Snaps and Flatpak both suuport this, but their critics resist without providing an alternative.
I'd rather hold software creators accountable for releasing malware. 100% protection against bad software is not free.
Are the mobile platforms using Snap and Flatpak?
..... guix shell --container
it's great for this.
X11's SECURITY extension was its long-forgotten stab at sandboxing: flip a bit and every client is either trusted or untrusted. It does kill trivial key-logging, but it also breaks the clipboard, disables GLX and makes various apps fall over, leaving the desktop unusable while Firefox somehow works just fine. A cool reminder that X11 could've had proper sandboxing 25 years ago, but the UX cost sank it and Wayland is the lifeboat now.
It's worth mentioning that the X11Libre fork of X.org has recently added the Xnamespace extension [1], which is inspired by this. Instead of a single bit trusted/untrusted it allows to isolate clients into containers where interactions are restricted to be within the same container only.
[1]: https://github.com/X11Libre/xserver/blob/master/doc/Xnamespa...
Thanks for sharing. That's really cool.
Plan 9 had this all sorted out, didn't it? It didn't use X11, it used something called 8½ which became the Plan 9 display server, and used 9p as the communication protocol.
What was clever about it was that each window got its own view of the keyboard and mouse. Literally their own virtual devices in /dev. Each window only saw what went on when that window was in focus, and for the mouse, it only saw what the mouse was doing when the mouse was within the boundaries of the window and that window was directly under the cursor (no windows between the cursor and the window in question.)
9P isn't encrypted, so these remote sessions weren't encrypted, but the Bell Labs folks knew that X11 security wasn't good and seem to have evolved it well. I wonder what things would be like if we didn't latch onto 40 year old operating systems like our lives depended on them.
If we can't get a useful Plan9 going (one that has a web browser and to which applications can easily be ported) maybe we can bring X11 forward a bit with inspiration from Plan 9. Wayland has been "2 years away" for about 15 years, and that shows no signs of changing.
I'm told that the entire source code for Plan 9 can be held in the mind of a single person, and that any skilled C developer can read what's going on with ease. I don't know if that's true, but if such a display server has semi-obvious improvements over X11, maybe we can come up with an X12 which adopts these improvements. We do not need to maintain backwards compatibility, we only need to support X11 and X12 at the same time, I imagine.
I remember back then xauth didn't even exist. You could simply dump a window on anyone else's screen. It was heaven for practical jokers like me.
I would've gone nuts with this in school
Yeah me too, though in college. There was even a program called "xbl" (or "blast" on some platforms) that would turn your mouse pointer into a crosshair and when you clicked somewhere it would make a round hole in the window. Which wouldn't go away until you killed the app. In fact they could even stay after it quit! It was so funny. https://man.freebsd.org/cgi/man.cgi?query=blast&sektion=1&ma...
Also running xfishtank on someone's root window. So many things you could do.
To me it seems the security extension is more useful for protecting elevated prompts (such as running an application as admin) than actually sandboxing between applications.
If that extension never caught on, then what mechanisms are being used now to protect elevated prompts/apps?
on Wayland? Flatpak and the fact that Wayland doesn't expose all windows to other windows.
> It's widely known that X11 has a problem with, for example, keyloggers. The issue is not that keyloggers are possible through security holes -- but keyloggers are trivial on X11, as they are part of normal operation and don't require exploits. It is one of the reasons why people push for Wayland.
Sorry, but did I miss news about a keylogger epidemic? On Linux?
In all seriousness, is this solving an actual problem or an imagined one?
And even assuming a 'Yes': A problem that isn't better solved elsewhere? How did the keylogger get access to the system and its desktop session? What else does it have access to?
Firejail discusses this briefly in their X11 guide:
The sandbox replaces the regular X11 server with Xpra or Xephyr server. This prevents X11 keyboard loggers and screenshot utilities from accessing the main X11 server.
https://firejail.wordpress.com/documentation-2/x11-guide
It's not a common issue, but obviously a security concern to make it so easy for keyloggers to record your keypresses or screen. I currently prefer X11 to Wayland, and I'd love if this problem was possible to address without Firejail. I use Firejail for other sandboxing tasks, but sandboxing X11 is too impractical.
'xev'
That's not an answer. Yes, I can run xev on my machine against my X session and see my keystrokes. It is not obvious that this is a problem. A more plausible angle would be that if an attacker compromises one application - say, a web browser - then they could keylog passwords. Of course, most people don't sandbox their browser so that's the least of their problems if it's compromised (ex. https://access.redhat.com/articles/1563163 let an attacker steal ssh keys).
The secure flag from xterm binds/locks kb and mouse and forbids snooping.
You're saying things, but not making an argument or even engaging the discussion really. What's the point you're trying to make, if any?
> It is one of the reasons why people push for Wayland.
Really? You think they'd just push for a _firewall_. Wouldn't that just solve the actual problem? Oh, wait, yea, X11 disabled TCP networking by default more than a decade ago.
> it cannot use the active X11 connection to spy on your keyboard.
You understand what /dev/input/* is, right?
> I understand that this means this blog post lacks substance.
The whole undertaking lacks substance.
Too many projects drank the early 2000s kool-aid and thought they would get a second suck at the salve (a.k.a "start from scratch"). It never worked out and you just fraction an already annoyed userbase into an overtly warring userbase. I can't think of anything more wasteful of talent and energy.
you sound fun. and by "fun" I mean "challenging"
Oh, I didn't realize the ethos of "hacker news" was to "have fun" and "avoid challenge."
I personally think attitudes like yours have destroyed this site.
You shouldn't process this forum as a social club or a social opportunity.
> I personally think attitudes like yours have destroyed this site.
neat. I mean, the site seems fine to me. Seems to be working fine. I got downvoted for my observation but you'll be upvoted for saying I broke something, so maybe it was already broken when you got here.
I think a proxy server might be a better way to handle security, than the way it is done as described in this article. (On a computer, the security will need to consider more than only the X server, but that will be one part of it.)