4 ms·

I see tearing often and it bothers me a lot. Also, if you run a program with gui in X you will need to trust that program to act in your best interest since X d

by madez 10y ago

I see tearing often and it bothers me a lot. Also, if you run a program with gui in X you will need to trust that program to act in your best interest since X doesn't protect against malicious clients. When I start a game on my computer, I do not want to have to trust it to behave nicely.

bandrami 10y ago
I mean, that's a great example of what I'm saying: worrying about an application screen-scraping my display (which is the only protection Wayland provides) is a kind-of-interesting thought experiment that I just don't care about.
- maggit 10y ago
  For completeness; Wayland also protects against keyloggers. In Wayland, input events are sent only to the application that hosts the window into which the input goes. So, keyboard events go to the app that has the keyboard focus. I'm not sure exactly how X works here. I think as long as you have a visible window (1x1 pixel or more), you can get all keyboard input. This may or may not be central to your point, but I wanted to have it out there to better inform about how Wayland improves upon X :)
  - bandrami 10y ago
    Yes and no. Wayland protects from userspace keyloggers after libevent gets its hands on a keystroke. (For that matter, it also doesn't protect against screenscrapers that simply look at video memory.)
    - zokier 10y ago
      Doesn't exploiting both of those require root privileges? Protecting against malicious code running as root seems like a lost cause anyways..
      - bandrami 10y ago
        In a system that doesn't use capabilities, generally yes (though, again, even simply with group ownership of devices you can do a lot of stuff that in traditional configurations requires root). But capabilities have managed to sneak into everything nowadays.
      - nixos 10y ago
        Once you have regular user access, root is easy: http://security.stackexchange.com/questions/119410/why-should-one-use-sudo/119420#119420 http://security.stackexchange.com/questions/119410/why-shoul...
        zokier 10y ago
        Funny you should bring that up, I was thinking the other day that Wayland should be usable building block for "secure desktop" style thing, that would help to prevent many (if not all) of the vectors presented at your link. Admittedly I haven't studied this in detail, so maybe there are some fatal aspects in Wayland that would make my ideas infeasible, but I hope that one day we could have more secure desktop privilege authorization.
  - rtpg 10y ago
    kinda curious: how would you build something like Text Expander in this world? As a keyboard driver?
    - maggit 10y ago
      Wayland is built up of multiple orthogonal protocols that each app negotiates access to with the server. Any given app will probably use multiple of these, for output, input, etc. Not knowing exactly what Text Expander is, I'm guessing it would probably need access to a specific protocol for controlling accessibility features. The Wayland server would need to be configured to allow this app access to that protocol somehow, for example by way of a server-initiated popup window that asks you to allow or deny this access. Does that explain it?
      - michaelmrose 10y ago
        What you mean is that because each compositor would have to add each feature that wayland breaks on each environment some will be implemented badly, others not at all.
      - digi_owl 10y ago
        Why do that sound very damn close to the various X extensions that has come and gone over the years?
    - bandrami 10y ago
      I'm also curious about keyboard layouts. I type stuff in both English and Bengali, and it looks like wayland.ini uses similar semantics to xorg.conf (layout=us,in variant=,ben or something like that). I'm curious how they'll do per-window layouts like windowmaker does. I find those very useful, and I'd assume they depend on some level of message promiscuity that they find distasteful -- I could imagine libevent being "smart" enough to multiplex that like my window manager does, but that in itself gets worrisome for largely the same reasons that people are talking about with X, particularly if it's meant to be extensible (it is, right?)
      - 10y ago
pdkl95 10y ago
> X doesn't protect against malicious clients Nor should it. That kind of sandboxing should be done as a wrapper around a particular program, not in the display server. A nested X server that sanitizes the protocol wouldn't be particularly difficult. Also, if your aren't fully sandboxing your potentially hostile application, a keylogger is the least of your problems. The display server isn't going to protect you from actual local attacks and privilege escalations; instead, it will only provide a false sense of security. Furthermore, doing this in the display server itself is shortsighted and unfortunately typical of the freedesktop.org development style that refuses to consider use cases outside their limited personal experience. I use the ability to send synthetic keyboard and mouse events to arbitrary X clients regularly. Occasionally I use the ability to keylog to work around poorly written software. If Wayland refuses to support these features, it isn't compatible with my software. Security is important, but simply removing features isn't the solution. Gnome/KDE may be popular, but many of us have software that uses X directly. Some of it written before those "desktop environments" even existed.
- beagle3 10y ago
  > Nor should it. That kind of sandboxing should be done as a wrapper around a particular program, not in the display server. A nested X server that sanitizes the protocol wouldn't be particularly difficult. Also, if your aren't fully sandboxing your potentially hostile application, a keylogger is the least of your problems. The display server isn't going to protect you from actual local attacks and privilege escalations; instead, it will only provide a false sense of security. Nested X servers are a pain, if you've used one - the things you're used to, like functional copy/paste, performant operation, tend to disappear and make this a non-workable solution. Furthermore, if you look at the release not of (e.g.) firejail, a wrapper around a local program, you'll notice that indeed a lot of the revisions are trying to avoid X bugs that let applications act as key-loggers etc. People have tried, and it turns out to be difficult.
michaelmrose 10y ago
I remain entirely unconvinced that anything short of virtualization protects you from malicious clients and that the primary effective security measure we can take is installing from trusted sources. It seem that the same people that believe we need to secure our display server against malicious clients almost inevitably want some sort google play store like experience where people release software for linux in some sort of universal way wherein distros would have no input rather than repo concept that is traditional now. I feel like they haven't thought this through and will leave us on net substantially less secure.

by madez 10y ago

bandrami 10y ago

I mean, that's a great example of what I'm saying: worrying about an application screen-scraping my display (which is the only protection Wayland provides) is a kind-of-interesting thought experiment that I just don't care about.

maggit 10y ago
For completeness; Wayland also protects against keyloggers. In Wayland, input events are sent only to the application that hosts the window into which the input goes. So, keyboard events go to the app that has the keyboard focus. I'm not sure exactly how X works here. I think as long as you have a visible window (1x1 pixel or more), you can get all keyboard input. This may or may not be central to your point, but I wanted to have it out there to better inform about how Wayland improves upon X :)
- bandrami 10y ago
  Yes and no. Wayland protects from userspace keyloggers after libevent gets its hands on a keystroke. (For that matter, it also doesn't protect against screenscrapers that simply look at video memory.)
  - zokier 10y ago
    Doesn't exploiting both of those require root privileges? Protecting against malicious code running as root seems like a lost cause anyways..
    - bandrami 10y ago
      In a system that doesn't use capabilities, generally yes (though, again, even simply with group ownership of devices you can do a lot of stuff that in traditional configurations requires root). But capabilities have managed to sneak into everything nowadays.
    - nixos 10y ago
      Once you have regular user access, root is easy: http://security.stackexchange.com/questions/119410/why-should-one-use-sudo/119420#119420 http://security.stackexchange.com/questions/119410/why-shoul...
      - zokier 10y ago
        Funny you should bring that up, I was thinking the other day that Wayland should be usable building block for "secure desktop" style thing, that would help to prevent many (if not all) of the vectors presented at your link. Admittedly I haven't studied this in detail, so maybe there are some fatal aspects in Wayland that would make my ideas infeasible, but I hope that one day we could have more secure desktop privilege authorization.
- rtpg 10y ago
  kinda curious: how would you build something like Text Expander in this world? As a keyboard driver?
  - maggit 10y ago
    Wayland is built up of multiple orthogonal protocols that each app negotiates access to with the server. Any given app will probably use multiple of these, for output, input, etc. Not knowing exactly what Text Expander is, I'm guessing it would probably need access to a specific protocol for controlling accessibility features. The Wayland server would need to be configured to allow this app access to that protocol somehow, for example by way of a server-initiated popup window that asks you to allow or deny this access. Does that explain it?
    - michaelmrose 10y ago
      What you mean is that because each compositor would have to add each feature that wayland breaks on each environment some will be implemented badly, others not at all.
    - digi_owl 10y ago
      Why do that sound very damn close to the various X extensions that has come and gone over the years?
  - bandrami 10y ago
    I'm also curious about keyboard layouts. I type stuff in both English and Bengali, and it looks like wayland.ini uses similar semantics to xorg.conf (layout=us,in variant=,ben or something like that). I'm curious how they'll do per-window layouts like windowmaker does. I find those very useful, and I'd assume they depend on some level of message promiscuity that they find distasteful -- I could imagine libevent being "smart" enough to multiplex that like my window manager does, but that in itself gets worrisome for largely the same reasons that people are talking about with X, particularly if it's meant to be extensible (it is, right?)
    - 10y ago

pdkl95 10y ago

> X doesn't protect against malicious clients Nor should it. That kind of sandboxing should be done as a wrapper around a particular program, not in the display server. A nested X server that sanitizes the protocol wouldn't be particularly difficult. Also, if your aren't fully sandboxing your potentially hostile application, a keylogger is the least of your problems. The display server isn't going to protect you from actual local attacks and privilege escalations; instead, it will only provide a false sense of security. Furthermore, doing this in the display server itself is shortsighted and unfortunately typical of the freedesktop.org development style that refuses to consider use cases outside their limited personal experience. I use the ability to send synthetic keyboard and mouse events to arbitrary X clients regularly. Occasionally I use the ability to keylog to work around poorly written software. If Wayland refuses to support these features, it isn't compatible with my software. Security is important, but simply removing features isn't the solution. Gnome/KDE may be popular, but many of us have software that uses X directly. Some of it written before those "desktop environments" even existed.

beagle3 10y ago
> Nor should it. That kind of sandboxing should be done as a wrapper around a particular program, not in the display server. A nested X server that sanitizes the protocol wouldn't be particularly difficult. Also, if your aren't fully sandboxing your potentially hostile application, a keylogger is the least of your problems. The display server isn't going to protect you from actual local attacks and privilege escalations; instead, it will only provide a false sense of security. Nested X servers are a pain, if you've used one - the things you're used to, like functional copy/paste, performant operation, tend to disappear and make this a non-workable solution. Furthermore, if you look at the release not of (e.g.) firejail, a wrapper around a local program, you'll notice that indeed a lot of the revisions are trying to avoid X bugs that let applications act as key-loggers etc. People have tried, and it turns out to be difficult.

michaelmrose 10y ago

I remain entirely unconvinced that anything short of virtualization protects you from malicious clients and that the primary effective security measure we can take is installing from trusted sources. It seem that the same people that believe we need to secure our display server against malicious clients almost inevitably want some sort google play store like experience where people release software for linux in some sort of universal way wherein distros would have no input rather than repo concept that is traditional now. I feel like they haven't thought this through and will leave us on net substantially less secure.