5 ms·

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

by 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

by maggit 10y ago

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