4 ms·

Isn't only the transport layer of X insecure? That could be swapped out with another layer. With Wayland you have to use VNC which is fine for local networks, b

Isn't only the transport layer of X insecure? That could be swapped out with another layer. With Wayland you have to use VNC which is fine for local networks, but not for remote ones.

addicted 3y ago
From what I understand, and I’m no expert on this, X pretty much broke application sandboxing. X’s design was inherently insecure in the context of modern OS security practices.
- asveikau 3y ago
  I think you're phrasing that incorrectly. There was no application sandboxing for X to break. And you can't build sandboxing atop X. You speak as if application sandboxing within the ever existed in the past... Not that people tried to build it and X doesn't play well with it.
  - gpderetta 3y ago
    I don't profess to have any deep knowledge of X11 or Wayland, but I don't understand how sandboxing can't work in X11. XWayland exists and it is either non-sandboxed (hence Wayland doesn't add any security benefit) or it is. And if it is it means that X can be sandboxed and it should be possible to run XonX sandboxes. Something like xnest.
    - asveikau 3y ago
      This is a very good comment. I guess then the claim is more that no common implementation is amenable to sandboxing, and the compatibility break of a brand new protocol means they can implement it from day 1 in the way they like. Which is a lot weaker an argument, but practically speaking, it's true that no one is rushing to bolt on security features to X. To be clear I'm not realy a Wayland fan.
  - hedora 3y ago
    You certainly can build sandboxing atop X11. If you're reading using a web browser on a Linux desktop (or in a VM on a Linux desktop), then you're literally staring at an existence proof.
    - asveikau 3y ago
      I guess the point is it can't be sandboxed by directly exposing X protocol messages to the sandboxed app. Although your sibling comment by gpderetta makes an excellent point. I guess they're saying no one wants to sandbox the X protocol, and breaking compatibility, proponents would claim, lets you design a sandbox friendly protocol from scratch.
- woodruffw 3y ago
  Without claiming that X is secure: I think it’s more accurate to say that X has never cared about application isolation at all, since it wasn’t (like its contemporaries) built with that paradigm in mind. In other words: while not originally UNIX-y, X matured in an ecosystem that idiomatically treats every userspace program as a perfect proxy for the user agent themselves. Sandboxing is a foreign (but good!) idiom that’s being bolted onto that paradigm.
- chasil 3y ago
  OpenBSD does implement some kind of privilege separation for X. $ ps ax -ouser,args | awk 'NR==1;/X.*:/' USER COMMAND _x11 /usr/X11R6/bin/X :0 vt05 -auth /etc/X11/xenodm/authdir/authfiles/A:0-PFzcIG (Xorg) root X: [priv] (Xorg)
deleted 3y ago
[deleted]
simiones 3y ago
My understanding is that any app which has access to X (so any windowed app) had full access to all other apps which have access. So, any app with a window can read the input from any other app on the same system, e.g. your sudo password. Or, take a screenshot of your bank info in Firefox.
- ApolloFortyNine 3y ago
  The thing is a 'day 1' feature everyone hacks back in is clipboard sharing and screen share, each of which remove a decent chunk of these protections. Each essentially grants access to another apps data. Plus the attack angle is someone having permission to execute apps on your machine, there's plenty of other nasty things they could do.
  - simiones 3y ago
    > The thing is a 'day 1' feature everyone hacks back in is clipboard sharing and screen share, each of which remove a decent chunk of these protections. Each essentially grants access to another apps data. Oh, yes, it's very likely that Wayland will end up with the exact same vulnerabilities. It's very hard in fact to design a windowing system that allows rich interaction between apps, but still maintains per user access control (never mind actually implementing it).
  - nolist_policy 3y ago
    > Plus the attack angle is someone having permission to execute apps on your machine, there's plenty of other nasty things they could do. No, the attack angle is either a untrusted app running in a sandbox (fatpak, snap or crosvm or qemu with wayland passtrough[1]) with only a connection to the compositor or a trusted app running in a sandbox getting exploited, any apps handling foreign data is suspect here (Web browser, mail client, pdf, office suite, etc.). [1] https://lore.kernel.org/qemu-devel/20231005024330.836-1-gurchetansingh@chromium.org/ https://lore.kernel.org/qemu-devel/20231005024330.836-1-gurc...
    - aidenn0 3y ago
vlovich123 3y ago
I believe there's work ongoing to upgrade to using H264 using MS's RDP protocol rather than VNC and getting that to work under wayland. That's waaaay better than X forwarding or VNC. if I recall correctly you've also got it backwards - I seem to recall X forwarding is much worse for higher latency networks than VNC.
hedora 3y ago
There's nothing wrong with the transport layer's security, as far as I can tell. (For one thing, it's usually tunneled over SSH). The X11 security model assumes that anything with access to the screen has at least as much privilege as the user account that owns the session. In practice, that's true (things like flatpack claim to support fake sandboxing, but whatever.) Hypothetically, in a universe where Wayland was running on top of something other than the Linux desktop ecosystem, you could run untrusted code from bash with su, and have it talk to wayland directly, and it'd be OK. Today, you have to run it in a web browser, or using a VM with display virtualization drivers, or use any of a dozen other sandbox choices. Those all managed to get the correct security properties under X11 because they're properly modularized. Wayland isn't, so to get this one feature, they're expecting all software to be rewritten.
- DonHopkins 3y ago
  > they're expecting all software to be rewritten. ALL software was ALREADY rewritten for the web, so just use a web browser running directly on the hardware instead of bothering with X11 or Wayland or some hypothetical replacement like X12. That's just an extra useless layer that nobody needs. A web browser is totally extensible and scriptable in JavaScript and WASM. Standards based. Excellent networking support. Streaming video. Secure sandboxing. Remote accelerated 2D and 3D graphics and GPU programming and WASM engine. Not rocket science. Off-the-shelf, well tested, open standards based solution. Problem already solved. Why this is not the most obvious thing in the world since the Effrafax painted a mountain pink, and hasn't already been done, totally baffles me. It's as if the Linux community would much rather bicker and squabble about X11 -vs- Wayland for another 30 years than solve the problem once and for all and permanently and perfectly. https://en.wikipedia.org/wiki/Somebody_else%27s_problem https://en.wikipedia.org/wiki/Somebody_else%27s_problem >An SEP is something we can't see, or don't see, or our brain doesn't let us see, because we think that it's somebody else's problem. That’s what SEP means. Somebody Else’s Problem. The brain just edits it out, it's like a blind spot. >The Somebody Else's Problem field... relies on people's natural predisposition not to see anything they don't want to, weren't expecting, or can't explain. If Effrafax had painted the mountain pink and erected a cheap and simple Somebody Else’s Problem field on it, then people would have walked past the mountain, round it, even over it, and simply never have noticed that the thing was there. https://news.ycombinator.com/item?id=38442601 https://news.ycombinator.com/item?id=38442601 https://news.ycombinator.com/item?id=38442660 https://news.ycombinator.com/item?id=38442660 https://news.ycombinator.com/item?id=38445174 https://news.ycombinator.com/item?id=38445174 https://news.ycombinator.com/item?id=31988890 https://news.ycombinator.com/item?id=31988890 https://news.ycombinator.com/item?id=29094938 https://news.ycombinator.com/item?id=29094938 https://news.ycombinator.com/item?id=29097030 https://news.ycombinator.com/item?id=29097030 https://news.ycombinator.com/item?id=20182294 https://news.ycombinator.com/item?id=20182294 https://news.ycombinator.com/item?id=11484148 https://news.ycombinator.com/item?id=11484148 https://news.ycombinator.com/item?id=5844345 https://news.ycombinator.com/item?id=5844345
yjftsjthsd-h 3y ago
No, the big problem with X isn't the transport but that once a client has access to the X server it can do more or less anything it wants (including logging keyboard input and recording other windows). And I haven't actually used it[0] but I thought waypipe was the better option for remoting? [0] Well, successfully or recently; I'm assuming it's usable now.

Isn't only the transport layer of X insecure? That could be swapped out with another layer. With Wayland you have to use VNC which is fine for local networks, but not for remote ones.

addicted 3y ago

From what I understand, and I’m no expert on this, X pretty much broke application sandboxing. X’s design was inherently insecure in the context of modern OS security practices.

asveikau 3y ago
I think you're phrasing that incorrectly. There was no application sandboxing for X to break. And you can't build sandboxing atop X. You speak as if application sandboxing within the ever existed in the past... Not that people tried to build it and X doesn't play well with it.
- gpderetta 3y ago
  I don't profess to have any deep knowledge of X11 or Wayland, but I don't understand how sandboxing can't work in X11. XWayland exists and it is either non-sandboxed (hence Wayland doesn't add any security benefit) or it is. And if it is it means that X can be sandboxed and it should be possible to run XonX sandboxes. Something like xnest.
  - asveikau 3y ago
    This is a very good comment. I guess then the claim is more that no common implementation is amenable to sandboxing, and the compatibility break of a brand new protocol means they can implement it from day 1 in the way they like. Which is a lot weaker an argument, but practically speaking, it's true that no one is rushing to bolt on security features to X. To be clear I'm not realy a Wayland fan.
- hedora 3y ago
  You certainly can build sandboxing atop X11. If you're reading using a web browser on a Linux desktop (or in a VM on a Linux desktop), then you're literally staring at an existence proof.
  - asveikau 3y ago
    I guess the point is it can't be sandboxed by directly exposing X protocol messages to the sandboxed app. Although your sibling comment by gpderetta makes an excellent point. I guess they're saying no one wants to sandbox the X protocol, and breaking compatibility, proponents would claim, lets you design a sandbox friendly protocol from scratch.
woodruffw 3y ago
Without claiming that X is secure: I think it’s more accurate to say that X has never cared about application isolation at all, since it wasn’t (like its contemporaries) built with that paradigm in mind. In other words: while not originally UNIX-y, X matured in an ecosystem that idiomatically treats every userspace program as a perfect proxy for the user agent themselves. Sandboxing is a foreign (but good!) idiom that’s being bolted onto that paradigm.
chasil 3y ago
OpenBSD does implement some kind of privilege separation for X. $ ps ax -ouser,args | awk 'NR==1;/X.*:/' USER COMMAND _x11 /usr/X11R6/bin/X :0 vt05 -auth /etc/X11/xenodm/authdir/authfiles/A:0-PFzcIG (Xorg) root X: [priv] (Xorg)

deleted 3y ago

[deleted]

simiones 3y ago

My understanding is that any app which has access to X (so any windowed app) had full access to all other apps which have access. So, any app with a window can read the input from any other app on the same system, e.g. your sudo password. Or, take a screenshot of your bank info in Firefox.

ApolloFortyNine 3y ago
The thing is a 'day 1' feature everyone hacks back in is clipboard sharing and screen share, each of which remove a decent chunk of these protections. Each essentially grants access to another apps data. Plus the attack angle is someone having permission to execute apps on your machine, there's plenty of other nasty things they could do.
- simiones 3y ago
  > The thing is a 'day 1' feature everyone hacks back in is clipboard sharing and screen share, each of which remove a decent chunk of these protections. Each essentially grants access to another apps data. Oh, yes, it's very likely that Wayland will end up with the exact same vulnerabilities. It's very hard in fact to design a windowing system that allows rich interaction between apps, but still maintains per user access control (never mind actually implementing it).
- nolist_policy 3y ago
  > Plus the attack angle is someone having permission to execute apps on your machine, there's plenty of other nasty things they could do. No, the attack angle is either a untrusted app running in a sandbox (fatpak, snap or crosvm or qemu with wayland passtrough[1]) with only a connection to the compositor or a trusted app running in a sandbox getting exploited, any apps handling foreign data is suspect here (Web browser, mail client, pdf, office suite, etc.). [1] https://lore.kernel.org/qemu-devel/20231005024330.836-1-gurchetansingh@chromium.org/ https://lore.kernel.org/qemu-devel/20231005024330.836-1-gurc...
  - aidenn0 3y ago

vlovich123 3y ago

I believe there's work ongoing to upgrade to using H264 using MS's RDP protocol rather than VNC and getting that to work under wayland. That's waaaay better than X forwarding or VNC. if I recall correctly you've also got it backwards - I seem to recall X forwarding is much worse for higher latency networks than VNC.

hedora 3y ago

There's nothing wrong with the transport layer's security, as far as I can tell. (For one thing, it's usually tunneled over SSH). The X11 security model assumes that anything with access to the screen has at least as much privilege as the user account that owns the session. In practice, that's true (things like flatpack claim to support fake sandboxing, but whatever.) Hypothetically, in a universe where Wayland was running on top of something other than the Linux desktop ecosystem, you could run untrusted code from bash with su, and have it talk to wayland directly, and it'd be OK. Today, you have to run it in a web browser, or using a VM with display virtualization drivers, or use any of a dozen other sandbox choices. Those all managed to get the correct security properties under X11 because they're properly modularized. Wayland isn't, so to get this one feature, they're expecting all software to be rewritten.

DonHopkins 3y ago
> they're expecting all software to be rewritten. ALL software was ALREADY rewritten for the web, so just use a web browser running directly on the hardware instead of bothering with X11 or Wayland or some hypothetical replacement like X12. That's just an extra useless layer that nobody needs. A web browser is totally extensible and scriptable in JavaScript and WASM. Standards based. Excellent networking support. Streaming video. Secure sandboxing. Remote accelerated 2D and 3D graphics and GPU programming and WASM engine. Not rocket science. Off-the-shelf, well tested, open standards based solution. Problem already solved. Why this is not the most obvious thing in the world since the Effrafax painted a mountain pink, and hasn't already been done, totally baffles me. It's as if the Linux community would much rather bicker and squabble about X11 -vs- Wayland for another 30 years than solve the problem once and for all and permanently and perfectly. https://en.wikipedia.org/wiki/Somebody_else%27s_problem https://en.wikipedia.org/wiki/Somebody_else%27s_problem >An SEP is something we can't see, or don't see, or our brain doesn't let us see, because we think that it's somebody else's problem. That’s what SEP means. Somebody Else’s Problem. The brain just edits it out, it's like a blind spot. >The Somebody Else's Problem field... relies on people's natural predisposition not to see anything they don't want to, weren't expecting, or can't explain. If Effrafax had painted the mountain pink and erected a cheap and simple Somebody Else’s Problem field on it, then people would have walked past the mountain, round it, even over it, and simply never have noticed that the thing was there. https://news.ycombinator.com/item?id=38442601 https://news.ycombinator.com/item?id=38442601 https://news.ycombinator.com/item?id=38442660 https://news.ycombinator.com/item?id=38442660 https://news.ycombinator.com/item?id=38445174 https://news.ycombinator.com/item?id=38445174 https://news.ycombinator.com/item?id=31988890 https://news.ycombinator.com/item?id=31988890 https://news.ycombinator.com/item?id=29094938 https://news.ycombinator.com/item?id=29094938 https://news.ycombinator.com/item?id=29097030 https://news.ycombinator.com/item?id=29097030 https://news.ycombinator.com/item?id=20182294 https://news.ycombinator.com/item?id=20182294 https://news.ycombinator.com/item?id=11484148 https://news.ycombinator.com/item?id=11484148 https://news.ycombinator.com/item?id=5844345 https://news.ycombinator.com/item?id=5844345

yjftsjthsd-h 3y ago

No, the big problem with X isn't the transport but that once a client has access to the X server it can do more or less anything it wants (including logging keyboard input and recording other windows). And I haven't actually used it[0] but I thought waypipe was the better option for remoting? [0] Well, successfully or recently; I'm assuming it's usable now.